<div dir="ltr"><p dir="ltr"><br>
On Jan 19, 2016 3:53 AM, "Sebastian Huber" <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> The problem is that you set the time via rtems_clock_set() in Init(). The you wait via rtems_task_wake_after(5s in ticks). With a rtems_task_wake_after(n) you wait to the n-th next tick, thus your wait interval is slightly less than 5s in most cases.<br></p><p>That makes sense but it unfortunately makes the obvious explanation of ticker a bit more complicated. :)</p><p>0: RTEMS starts<br>0+t1: clock_set to TIME<br>0+t[234]: three wake afters<br><br>500th clock tick is now exactly five seconds from time 0 but TIME+5 seconds minus t1 clock time.</p><p>The thing that surprised me was that when I hacked in changes to use rtems_clock_get_tod_timeval(), the times do not indicate that 5 seconds of delay actually occurred.<br><br></p><p>TA1 599562000:1088<br>TA2 599562000:2143<br>TA3 599562000:3199<br>TA1 599562004:997954<br>TA2 599562009:977896<br>TA1 599562009:978937<br>TA3 599562014:957903<br>TA1 599562014:958944<br>TA2 599562019:957907</p><div>The tasks are delaying 500, 1000, and 1500 ticks with nanoseconds_per_tick = 10000000. Delay operations are guaranteed to be a minimum of the requested amount and this is not being honored.<br><br>I know this is a duration specified in clock ticks but it is really (ticks * nanoseconds per tick) long in real time.<br><br>I have not checked delays like sleep() and nanosleep() but tick based ones are 1 tick too short.</div><div><br></div><div>--joel</div><p dir="ltr"><br></p>
<p dir="ltr">> On 18/01/16 00:19, Joel Sherrill wrote:<br>
>><br>
>> Hi<br>
>><br>
>> With the recent clock changes, I am noticing that on some BSPs<br>
>> ticker is reporting times 4, 9, 14, ... instead of 5, 10, 15.<br>
>><br>
>> It looks like the time is 4.9999999 when it should simply be 5 so<br>
>> ticker just reports 4.<br>
>><br>
>> Given this is a visible change in behavior, I would like to know<br>
>> what causes it and how it can be resolved?<br>
>><br>
>> Thanks.<br>
>><br>
>> --joel<br>
>><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
><br>
> -- <br>
> Sebastian Huber, embedded brains GmbH<br>
><br>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> Phone   : +49 89 189 47 41-16<br>
> Fax     : +49 89 189 47 41-09<br>
> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> PGP     : Public key available on request.<br>
><br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
><br>
</p>
</div>