Support Request #14170
closed[EBPSSD-1346] Inaccurate display of number of samples in Sample Stream Trace View after replay
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
Updated by hidden almost 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
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 ?
I created an bug report, we have to evaluate this: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.
- [ACORE-11049] - Sample Stream and trigger count is cut in replay
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
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,
Could be reproduced... I opened another issue: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).
- [ACORE-11050] - Sample rate toggles when calculation is between two values
Updated by hidden almost 3 years ago
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
Updated by hidden almost 3 years ago
- Project changed from 7 to Public Support
- Status changed from To Be Closed to Closed
- Private changed from Yes to No