cmsdaq / daqview-react Goto Github PK

Since React components are only able to return one element, we currently construct all FEDBuilders together with their SubFEDBuilders in one React component, building all the rows of the table in one place.

However, since HTML tables are allowed to have multiple table bodies, it might be possible to add one table body per FEDBuilder to the table, containing a row for each of its SubFEDBuilders and resulting in a separate FEDBuilder React component.

This is worth looking into, as it would make the code easier to understand and maintain.

this would allow going back and forth quickly between failures seen in the DAQ view archive and the timeline of the DAQ Expert to better understand the analysis done by the DAQ Expert.

in this example pseudo FED 11120 should also be displayed in the line corresponding to the HFb fedbuilder in addition to the HFa line.

The daqdev setup currently fails to load because there is a SubFEDBuilder without a FRLPc:

{
    "@id" : "SFB_CSC+$CSC-$-",
    "minTrig" : -1,
    "maxTrig" : -1,
    "ref_fedBuilder" : "FEDB_CSC+",
    "ref_ttcPartition" : "TTCP_CSC-",
    "ref_frlPc" : null,
    "ref_frls" : [ ],
    "ref_feds" : [ "FED_827" ]
  }

Is this a case that needs to be handled by the DAQView?

Oliver reported that new DAQView is creating history entry every 2 seconds. The history file is right now ~160 Mb. We need to disable it as it's useless.

DAQView does not display the correct FED IDs for those FEROL40 which are split over 2 FED builders. E.g.:
BPIXP:81 B s2d19-40-01 8:1228,1229,1230,1231, 9:1232,1233, 10:1236,1237 11224 11236 BPIXP:81 B s2d19-40-01 10:1236,1237, 11:1240,1241,1242,1243, 12:1244,1245 11236
The 2nd row should start in stream 2, i.e. FED IDs 1238,1239, instead of repeating the FED IDs from stream 0/1 which are in the row above.

Remi

Hi,

could you please add a setup for daqdev to the list of available snapshot services? The daqdev setup runs from cmsrc-daqdev, port 31000 and uses the same LASes as the cDAQ setup.

Thanks,
Remi

Hi,

I noticed that you keep the greenish color for the table headers and footers regardless of the color scheme, i.e. yellow/red/white table. It would be nice to use the same color scheme the header/footers, too.

Cheers,
Remi

Hi,

I cannot go to past snapshots when using Safari. Neither the arrows work, nor if I specify a timestamp in the field or the URL. I always get 'Monitoring data unavailable: Could not find snapshot'. It works flawlessly on Chrome.

Cheers,
Remi

Example snapshot with missing data:
http://daq-expert.cms904/daq2view-react/index.html?setup=hcal&time=2017-11-22-17:29:29

A warning about missing BU data should be added to the DAQView (like it is already done for FRLPcs and RUs).

similar to what the DAQExpert does using the Transition module which indicates that there was a transition recently.

Bootstrap 3 is no longer maintained and contains various XSS vulnerabilities. While we are unaffected by them, moving to the maintained Bootstrap 4 might still be a good idea.

Since we are only using Bootstrap for the date and time picker, migration should be trivial. Alternatively, it might make sense to look for a replacement for the picker to remove our dependency on Bootstrap altogether.

As a consequence, when following a link pointing to a past point in time and clicking e.g. on the FFF button one suddenly sees the current status instead of the historical one.

They do however include the cdaq parameter.

There are no longer warning flags in the BU table when BUs detect bad data. E.g. in http://daq-expert.cms/daq2view-react/?setup=cdaq&time=2018-03-29-09:17:55, the RUs have detected CRC errors from some of the ECAL FEDs. This is also seen in the BUs, which have 'nbEventsWithCRCerrors' > 0 in the corresponding snapshot. However, the DAQView page does not show it.

I would suggest to add this feature, which was there in the old DAQView, for the following cases:

• nbCorruptedEvents > 0 -> display #bad: with the count
• nbEventsWithCRCerrors > 0 -> display #CRC: with the count
• nbEventsMissingData > 0 -> display #incomplete: with the count

Note that the last case will not be present in production, as the configuration forbids any incomplete events.

Hi,

in the current run 305366 DAQView shows 12.6% back pressure on FED 583:
http://daq-expert.cms/daq2view-react/index.html?setup=cdaq&time=2017-10-21-13:58:55

However, this FED is masked. The snapshot is reflecting this correctly:

{
"@id" : "FED_588",
"id" : 588,
"frlIO" : 0,
"fmmIO" : 5,
"srcIdExpected" : 583,
"srcIdReceived" : 583,
"percentBackpressure" : 12.6,
"frl_AccBIFIBackpressureSeconds" : 0.0,
"percentWarning" : 0.0,
"percentBusy" : 0.0,
"ttsState" : "R_8",
"numSCRCerrors" : 0,
"numFCRCerrors" : 0,
"numTriggers" : 0,
"eventCounter" : 0,
"fmmMasked" : true,
"frlMasked" : true,
"hasSLINK" : true,
"hasTTS" : true,
"ruFedInError" : false,
"ruFedBXError" : 0,
"ruFedCRCError" : 0,
"ruFedDataCorruption" : 0,
"ruFedOutOfSync" : 0,
"ruFedWithoutFragments" : false,
"frl_AccSlinkFullSec" : 0.0,
"frl_AccLatchedFerol40ClockSeconds" : 15522.04959564,
"ru" : "RU_ru-c2e14-10-01",
"ref_frl" : "FRL_7$frlpc-s2d10-21-01",
"ref_fmm" : "FMM_45",
"ref_ttcp" : "TTCP_TOTDET",
"ref_dependentFeds" : [ ]
}

Why do we have "back pressure" on this FED while it is masked?

Remi

The RU's warning message in the DAQ View also includes FED errors, such as: InError, BXError, CRCError, DataCorruption, OutOfSync and WithoutFragments. However, in the snapshot format, these values are not stored with the RU itself, but are contained in the ruFed* attributes of the affected FED(s).

In order to display this data, it might make sense to pre-process the snapshot and collect the FED errors, formatting them and adding them to the RU's error message attribute before passing the snapshot to the FB table component.

On the other hand, this is a concern of the view and the FB table class could also collect and style these errors when constructing the RU's error message.

Either way, collecting these errors would require the code to follow the link from the FEDBuilder to its SubFEDBuilders, their FRLs and finally to the FEDs. It will be required to sort the data after collecting it as well, since FED errors are supposed to be displayed ordered by the FED's expected source id.

To serve the request of providing dynamic URLs to displays (that is, given a URL-with-params string, one may directly go to a specific DAQView display, under the constraints set by the parameters), there should be a lightweight DAQView server application, in order to serve requests with parameters.

At DAQView-React.js, there is a single data entry point, which is currently only one file, the index.html. In there, both the data source and the parameters are specified (currently only the time, due to DAQAggregator's limited indexing by time only). In case the static DAQView display is implemented using a second .html file, this would also be a data entry point specifying which snapshot to render for a static display.

It is, in principle, enough to dynamically generate and serve index.html using the URL input parameters. For this, a lightweight servlet is needed, to read and validate parameters and inject their values into the dynamic index.html, which will subsequently be served.

From a DAQView's point of view, the DAQ configuration should also be nothing more than a parameter. This parameter will be translated either to a different location of snapshots, or be passed on the snapshot service API as a parameter, depending on how the API will be extended in the future.

Hi,

the legacy DAQView page turns red whenever the EvB is Enabled but the rate is 0. I think this was carried forward for the react version. However, at the start of the run this is always the case as the EvB is enabled before the triggers start flowing. Now that we have the LVL0 state, I wonder if this logic should be changed to LVL0 state "Running" and rate is 0 to turn the page red.

Cheers,
Remi

Do we have a policy regarding backwards-compatibility of the DAQView? I remember it being brought up during the initial discussions, but don't recall what we agreed on.

Since the instantaneous deadtimes are available in snapshots now, the deadtime table is no longer compatible with snapshots that do not yet contain this data, even if they do contain the deadtime per lumisection. As it is, a message saying that there was no deadtime information found in the snapshot will be displayed for old snapshots. Is this the desired behavior? Or is the DAQView supposed to display per lumisection data if available instead?

I think we can agree that:

1. DAQView should be compatible with the old format if the new format only contains additional data, for example by displaying a message that some data is unavailable. This needs to be done anyway, since test setups usually do not produce full snapshots.

What I am not sure about:
2) What is the desired behavior if snapshot attributes get renamed or the snapshot structure changes?
3) The case described above, where additional data is added to the snapshot and the old format contains compatible data.

Currently, we are wasting too much time on a snapshot update (around 500ms per update on my machine, even for snapshots without any data changes). The wasted time may be reduced by implementing shouldComponentUpdate hooks for most components.

Also, we should be adding unique keys to component instances. I suggest using the unique object ids already present in the JSON and adding the "@ id" attribute to the TypeScript interfaces.