Support Request #14170: [EBPSSD-1346] Inaccurate display of number of samples in Sample Stream Trace View after replay - Public Support - digitalwerk community

Actions

Copy link

#1

Updated by hidden about 3 years ago

Status changed from New to In Progress
Private changed from No to Yes
Customer set to ELEKTROBIT
Department set to SUPPORT
Topic set to ADTF::SampleStreamTraceView
Support Level changed from 2nd Level to 3rd Level

Actions

Copy link

#7

Updated by hidden almost 3 years ago

Status changed from In Progress to Customer Feedback Required
Resolution set to Product Issue Opened
Product Issue Numbers set to https://www.cip.audi.de/jira/browse/ACORE-11049

Hi Anja,

There is already an open problem reported for Sample Stream Trace View concerning the rates which are inappropriate ACORE-9650. Since this is an essential service for verifying correct functionality in my projects I would be interested in knowing when and whether a fix is planned.

ACORE-9650 ist eigentlich durch ACORE-10917 in ADTF 3.11.1 gefixt, ich hatte es nur vergessen, aus den known problems zu nehmen, sorry.
Habt ihr damit immer noch Probleme ?

As an example I used a .dat file to compare it with ADTF 2 File Trace View. Please take this as a reference. "C:\ADTF\2.14.3\bin\templates\example_test_file.dat". The file contains 297 samples on the NESTED_STRUCT stream. In a replay project with ADTF 3.11.2 the Sample Stream Trace View UI service reports the samples in multiples of 20 and counts a total of 280. (see pic). Toggling with the "RepaintTimeInterval" seems to have no effect. Actual samples send in ADTF 3 are also 297, so it seems the ADTF File Player works correct.

I created an bug report, we have to evaluate this:

[ACORE-11049] - Sample Stream and trigger count is cut in replay

Actions

Copy link

#8

Updated by hidden almost 3 years ago

Hallo Florian,

hier die Antwort:

"Concerning whether the bug is fixed with the ACORE-9650. Thanks for the information. I actually noticed that we now get more precission (multiple of 1/s). But was not sure if it is acccurate since the problem was still announced.

When I trigger a sample every second with the Demo Time Triggered Filter it shows me a 1.00 Triger/s. When I change the trigger period to 2 seconds, the display alternatively shows me 1.00/s and 0.00/s. I would expect 0.5/s. So this is still not accurate. We have two digits after the comma in the display so the least unit should be 0.01 /sec. But it is obviously measured every second. (One could probably achive this using the differences between the sample times/or avarages, or just remove the two zeros after the comma to lower the expectation).

Thanks for inspecting the wrong count in replay."

Grüße,
Anja

Actions

Copy link

#9

Updated by hidden almost 3 years ago

Product Issue Numbers changed from https://www.cip.audi.de/jira/browse/ACORE-11049 to https://www.cip.audi.de/jira/browse/ACORE-11049; https://www.cip.audi.de/jira/browse/ACORE-11050

Hallo Anja,

When I trigger a sample every second with the Demo Time Triggered Filter it shows me a 1.00 Triger/s. When I change the trigger period to 2 seconds, the display alternatively shows me 1.00/s and 0.00/s. I would expect 0.5/s. So this is still not accurate. We have two digits after the comma in the display so the least unit should be 0.01 /sec. But it is obviously measured every second. (One could probably achive this using the differences between the sample times/or avarages, or just remove the two zeros after the comma to lower the expectation).

Could be reproduced... I opened another issue: