
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>On 20. Feb 2018, at 05:46, Ashraf E. Suyyagh <<a href="mailto:mrsuyyagh@gmail.com">mrsuyyagh@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div class="gmail_default"><font color="#0b5394" face="verdana, sans-serif">2. As for the wrong period reported when it becomes too large, after investigating, this problem is expected in <b>all</b> versions <b>including the recent ones</b>. This has to do with the <i>struct st_param_data </i>because in there, the period and WCET are defined as <i>u32 </i>type. Since all timing is in nanoseconds, all execution times and periods exceeding the <i>int</i> type capacity will be wrongly represented. However, since internally litmus_rt WCET and periods are of type lt_t (long long), my expectation is that internally Litmus will work correctly. To correct the issue, a complete rework and resizing of the event record struct and size is needed if one wishes to see a correct large period/WCET displayed in st-job-stats. This might not be a priority, but worth noting.</font></div><div class="gmail_default"></div></div></blockquote><br><div>This is a conscious tradeoff. 2^32 nanoseconds correspond to roughly 4294ms, or almost 4.3 seconds. This should be large enough a period for just about any interesting RT workload. It’s not worth increasing the trace record size, which would affect everyone, for the few edge cases with tasks with a period longer than 4 seconds.</div><div><br></div><div>- Björn </div></body></html>