Bug 1293 - Inconsistencies in capture counts for various task durations
Summary: Inconsistencies in capture counts for various task durations
Status: RESOLVED FIXED
Alias: None
Product: DIRSIG4
Classification: Unclassified
Component: Platform (show other bugs)
Version: 4.7.5-release
Hardware: All All
: P5 normal
Assignee: Scott D. Brown
URL:
Depends on:
Blocks:
 
Reported: 2020-08-06 12:42 EDT by Scott D. Brown
Modified: 2020-08-06 12:45 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott D. Brown 2020-08-06 12:42:13 EDT
Some of the demos when run with DIRSIG4 do not produce the correct number of total captures (frames). The intended behavior is for the clock trigger to be generated for the entire task window inclusive of the start and end times. 

A duration of 0 is a special case. Regardless of the clock rate, you always get 1 capture for an “instantaneous” or zero length task:
Duration = 0.0 seconds -> 1 capture

For non-zero length task durations, we expect captures at every clock interval within the window including the end time (if that corresponds to a clock trigger):
Duration = 1 second, clock = 1 Hz -> 2 captures (one at t = 0 and one at t = 1)
Duration = 10 seconds, clock = 10 Hz -> 11 captures
Duration = 0.6 seconds, clock = 60 Hz -> 37 captures

Specifically, NormalMap1 "video.sim" scenario has a platform with a clock rate of 60 Hz and a task duration of 0.6 seconds and was only producing 36 frames rather than 37.
Comment 1 Scott D. Brown 2020-08-06 12:45:50 EDT
The problem was tracked down to poor precision management when computing the task duration. The fix was checked in with r19096.