search

cmsdaq / DAQExpert

New expert system processing data model produced by DAQAggregator
1 stars 2 forks source link

Identifying upgraded/legacy feds #225

Closed gladky closed 6 years ago

gladky commented 6 years ago

There are 2 ways to distinguish upgraded fed from legacy one:

Here are the results for this 2 approaches for assigning FEDS (snapshot Wed May 30 15:38:28 CEST 2018)

Updated/Legacy based on FRL type:

Upgraded:

[601-654, 1024, 1100-1123, 1134-1135, 1200-1209, 1212-1221, 1224-1233, 1236-1245, 1248-1257, 1260-1269, 1272-1281, 1284-1293, 1296-1302, 1308-1314, 1320-1326, 1332-1338, 1354, 1356, 1358, 1360, 1369-1371, 1376-1377, 1380-1381, 1384-1386, 1390-1391, 1393-1395, 1402, 1404, 1462-1463] Sum: 212

Legacy:

Sum: 526 [50-58, 60-102, 104-387, 389-433, 435-489, 520, 522-525, 528-532, 534-535, 537, 539-542, 545-549, 551, 553-557, 560-561, 563-566, 568, 570-574, 582-583, 724-731, 735, 790-792, 831-839, 841-849, 851-859, 861-869]

Unable:

661-664 Sum: 4

Updated/Legacy based on FMM type:

Upgraded:

[1100-1123, 1134-1135, 1200-1209, 1212-1221, 1224-1233, 1236-1245, 1248-1257, 1260-1269, 1272-1281, 1284-1293, 1296-1302, 1308-1314, 1320-1326, 1332-1338, 1354, 1356, 1358, 1360, 1369-1371, 1376-1377, 1380-1381, 1384-1386, 1390-1391, 1393-1395, 1402, 1404, 1462-1463] Sum: 157

Legacy:

[50-58, 60-102, 104-387, 389-433, 435-489, 520, 522-525, 528-532, 534-535, 537, 539-542, 545-549, 551, 553-557, 560-561, 563-566, 568, 570-574, 582-583, 601-654, 661-664, 724-731, 735, 790-792, 831-839, 841-849, 851-859, 861-869] Sum: 584

Unable:

1024 Sum: 1

Please confirm that the second method is the one we want to use.

hsakulin commented 6 years ago

for the dead time case, we are interested if the FED has an FMM (or its pseudo-FED has an FMM). If there is no FMM but just a PI we should consider the FED upgraded.

So the 2nd method would apply.

1024 is the FED of the TCDS CPM - its FMM is internal to TCDS, so it has no TTS signal. (If DAQ backpressures 1024, we get a separate dead time category in the CPM 'Deadtime due to DAQ backpressure to the PM’).

661-664 have main FEDs associated. Please check.

On 07 Jun 2018, at 12:40, Maciej Gladki notifications@github.com wrote:

There are 2 ways to distinguish upgraded fed from legacy one:

• type of FRL (SLINK --> legacy; SLINKEXPRESS6G, -10G, FEROL40_6G, -10G --> upgraded ), this method would not work for ECAL feds (see FED 610 that has SLINKEXPRESS even though its legacy) • type of FMM (FMM --> legacy; PI, AMC13--> upgraded) Here are the results for this 2 approaches for assigning FEDS (snapshot Wed May 30 15:38:28 CEST 2018)

Updated/Legacy based on FRL type:

Upgraded:

[601-654, 1024, 1100-1123, 1134-1135, 1200-1209, 1212-1221, 1224-1233, 1236-1245, 1248-1257, 1260-1269, 1272-1281, 1284-1293, 1296-1302, 1308-1314, 1320-1326, 1332-1338, 1354, 1356, 1358, 1360, 1369-1371, 1376-1377, 1380-1381, 1384-1386, 1390-1391, 1393-1395, 1402, 1404, 1462-1463] Sum: 212

Legacy:

Sum: 526 [50-58, 60-102, 104-387, 389-433, 435-489, 520, 522-525, 528-532, 534-535, 537, 539-542, 545-549, 551, 553-557, 560-561, 563-566, 568, 570-574, 582-583, 724-731, 735, 790-792, 831-839, 841-849, 851-859, 861-869]

Unable:

661-664 Sum: 4

Updated/Legacy based on FMM type:

Upgraded:

[1100-1123, 1134-1135, 1200-1209, 1212-1221, 1224-1233, 1236-1245, 1248-1257, 1260-1269, 1272-1281, 1284-1293, 1296-1302, 1308-1314, 1320-1326, 1332-1338, 1354, 1356, 1358, 1360, 1369-1371, 1376-1377, 1380-1381, 1384-1386, 1390-1391, 1393-1395, 1402, 1404, 1462-1463] Sum: 157

Legacy:

[50-58, 60-102, 104-387, 389-433, 435-489, 520, 522-525, 528-532, 534-535, 537, 539-542, 545-549, 551, 553-557, 560-561, 563-566, 568, 570-574, 582-583, 601-654, 661-664, 724-731, 735, 790-792, 831-839, 841-849, 851-859, 861-869] Sum: 584

Unable:

1024 Sum: 1

Please confirm that the second method is the one we want to use.

• Why 1024 has no related FMM, either own or through pseudo-fed relation? • Why 661-664 have no related FRL, either own or through pseudo-fed relation? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

gladky commented 6 years ago

Ok I will use the 2nd method.

Indeed 661-664 are associated with main FEDs:

FED 604 hasTTS=true, hasSLINK=true, deps=[661] FED 641 hasTTS=true, hasSLINK=true, deps=[663] FED 664 hasTTS=true, hasSLINK=false, deps=[] FED 605 hasTTS=true, hasSLINK=true, deps=[661] FED 642 hasTTS=true, hasSLINK=true, deps=[663] FED 652 hasTTS=true, hasSLINK=true, deps=[664] FED 662 hasTTS=true, hasSLINK=false, deps=[] FED 623 hasTTS=true, hasSLINK=true, deps=[662] FED 624 hasTTS=true, hasSLINK=true, deps=[662] FED 663 hasTTS=true, hasSLINK=false, deps=[] FED 653 hasTTS=true, hasSLINK=true, deps=[664] FED 661 hasTTS=true, hasSLINK=false, deps=[]

But note that in our hierarchy retriever we explicitly ignore relations of FEDs that have both TTS and SLINK:

if FED has both SLINK and TTS than don't treat is as a dependent FED - that's the case for all ECAL FEDS

That's why I didn't see this relation it in our hierarchy.

hsakulin commented 6 years ago

Was there a good reason to ignore these relations? In principle, back-pressure on 604 could cause dead time on 661 (although I am not really sure this can actually happen in this particular case).

On 07 Jun 2018, at 15:21, Maciej Gladki notifications@github.com wrote:

Ok I will use the 2nd method.

Indeed 661-664 are associated with main FEDs:

FED 604 hasTTS=true, hasSLINK=true, deps=[661] FED 641 hasTTS=true, hasSLINK=true, deps=[663] FED 664 hasTTS=true, hasSLINK=false, deps=[] FED 605 hasTTS=true, hasSLINK=true, deps=[661] FED 642 hasTTS=true, hasSLINK=true, deps=[663] FED 652 hasTTS=true, hasSLINK=true, deps=[664] FED 662 hasTTS=true, hasSLINK=false, deps=[] FED 623 hasTTS=true, hasSLINK=true, deps=[662] FED 624 hasTTS=true, hasSLINK=true, deps=[662] FED 663 hasTTS=true, hasSLINK=false, deps=[] FED 653 hasTTS=true, hasSLINK=true, deps=[664] FED 661 hasTTS=true, hasSLINK=false, deps=[]

But note that in our hierarchy retriever we explicitly ignore relations of FEDs that have both TTS and SLINK:

if FED has both SLINK and TTS than don't treat is as a dependent FED - that's the case for all ECAL FEDS

That's why I didn't see this relation it in our hierarchy.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

gladky commented 6 years ago

I removed this part in hierarchy resolver and the tests forfed deadtime due to DAQ LM failed. The LM is no longer able to identify the problem:

FED 622 has a deadtime 5.2%, due to DAQ backpressure 5.2%. The threshold for deadtime is 2.0%, backpressure: 2.0%

For the snapshot 1507212900008.

The condition of having the fed (in this case 622) with deadtime and backpressure exceeding the thresholds is no longer true.

Situation A: In case we ignore aforementioned relations (situation currently):

In partition EB- we have following flat hierarchy resolved:

Situation B: In case we DO NOT ignore aforementioned relations:

In partition EB- we have following hierarchy resolved (one root node):

Partition: EB-

The reason why this make a difference is that in situation A LM will check each FED and compare it's coresponding deadtime and backpressure to the thresholds, yielding 622 as problematic. In situation B we would take deadtime of pseudo FED 662 which is 0 and maximum backpressure from coresponding FEDs, which is 21.4% from 622. This is what we do for all other partitions.

Please let me know if you need more information on this issue. Otherwise I'm closing it as the filtering of upgraded feds has been introduced in 2.10.15

https://github.com/cmsdaq/DAQExpert/releases/tag/upgraded-feds