Support Request #14170
closed
[EBPSSD-1346] Inaccurate display of number of samples in Sample Stream Trace View after replay
Added by hidden about 3 years ago.
Updated about 3 years ago.
Requester's Priority:
Normal
Resolution:
Product Issue Opened
Topic:
ADTF::SampleStreamTraceView
Description
Supportanfrage
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.
But appart from that we faced the issue that the sample count and trigger count is wrong after replay. Is this also a known bug?
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.
Lösung
Opened two bug reports:
- [ACORE-11049] - Sample Stream and trigger count is cut in replay
- [ACORE-11050] - Sample rate toggles when calculation is between two values
Files
- 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
- 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
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
- 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:
- [ACORE-11050] - Sample rate toggles when calculation is between two values
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
- Project changed from 7 to Public Support
- Status changed from To Be Closed to Closed
- Private changed from Yes to No
Also available in: Atom
PDF