Hello Trick Developers,
During a project that required running trick realtime in the range of 100-200 Hz, I was assessing the realtime performance with the log frame data feature. I am very impressed with the overall performance and utility of Trick for realtime purposes! Though, upon inspecting the aggregate job execution time to the recorded total frame duration (called frame_time), I saw an inconsistency between the two.
Inspecting the function where frame_time is calculated, rt_monitor in RealtimeSync.cpp, I deduced that frame_time was being calculated in the wrong spot. It is being calculated at the beginning of the function but in default_trick_sys.sm, the function is scheduled as an end of frame job. After this, the functions spins for whatever remaining frame time is left. By calculating frame_time in this way, it is including the previous frame's spin time with the current frame's job execution times. This leads to an inconsistency because the previous frame's spin time is based on the previous frame's job execution time. The calculation should happen at the end of this function so that frame_time includes both the current frame's job execution AND spin time.
A recommended modification is shown below. Trick has been run with this fix has on over 100 lab tests with a high performance PC and the frame_time was successfully used to verify proper realtime performance.
Current frame_time calculation:
|
frame_time = frame_sched_time * (1.0/tics_per_sec); |
Recommended implementation
Remove lines
|
curr_clock_time = rt_clock->clock_time() ; |
to
|
last_clock_time = curr_clock_time ; |
Add following code block here:
// Get actual frame-to-frame time (measure after spinning)
curr_clock_time = rt_clock->clock_time() ;
frame_sched_time = curr_clock_time - last_clock_time ;
frame_time = frame_sched_time * (1.0/tics_per_sec);
/* Set the next frame overrun/underrun reference time to the current time */
last_clock_time = curr_clock_time ;
Thanks,
John
Hello Trick Developers,
During a project that required running trick realtime in the range of 100-200 Hz, I was assessing the realtime performance with the log frame data feature. I am very impressed with the overall performance and utility of Trick for realtime purposes! Though, upon inspecting the aggregate job execution time to the recorded total frame duration (called
frame_time), I saw an inconsistency between the two.Inspecting the function where
frame_timeis calculated,rt_monitorinRealtimeSync.cpp, I deduced thatframe_timewas being calculated in the wrong spot. It is being calculated at the beginning of the function but indefault_trick_sys.sm, the function is scheduled as an end of frame job. After this, the functions spins for whatever remaining frame time is left. By calculatingframe_timein this way, it is including the previous frame's spin time with the current frame's job execution times. This leads to an inconsistency because the previous frame's spin time is based on the previous frame's job execution time. The calculation should happen at the end of this function so thatframe_timeincludes both the current frame's job execution AND spin time.A recommended modification is shown below. Trick has been run with this fix has on over 100 lab tests with a high performance PC and the
frame_timewas successfully used to verify proper realtime performance.Current
frame_timecalculation:trick/trick_source/sim_services/RealtimeSync/RealtimeSync.cpp
Line 320 in 4a4de97
Recommended implementation
Remove lines
trick/trick_source/sim_services/RealtimeSync/RealtimeSync.cpp
Line 318 in 4a4de97
to
trick/trick_source/sim_services/RealtimeSync/RealtimeSync.cpp
Line 323 in 4a4de97
Add following code block here:
trick/trick_source/sim_services/RealtimeSync/RealtimeSync.cpp
Line 406 in 4a4de97
Thanks,
John