Till Straumann strauman at
Thu Jun 2 17:59:25 UTC 2011

Don't recall the exact implementation and I'm not sure I understand
exactly what you're saying but the clock tick quantum could well
be constant, i.e., the clock ticks could happen at an arbitrary,
constant rate - just the TOD increment could be adjusted so that
TOD can be synchronized with e.g., NTP.


On 06/02/2011 01:14 AM, Joel Sherrill wrote:
> Grrr.. hit send too early when bump
> Adjusting tick length is a different issue and we might want to
> discuss variable clock tick quantums ala the tickless kernel model of
> operation.
> Also the NTP folks are friendly to us. Verm from NTP is setting up a
> buildbot for RTEMS now. They are the experts on this so doing what
> they think best would. Be wise.
> --joel
> Till Straumann<strauman at>  wrote:
>> Currently, adjtime() basically steps the time (albeit not backwards
>> if IRC) and this only if the requested difference is bigger than a
>> full clock tick.
>> IMO it would make sense to improve this implementation by
>> - gradually adjusting the clock, i.e., absorbing the requested
>> delta over multiple clock ticks. - allow small adjustments
>> (especially on architectures with a high-resolution clock)
>> I know that adjtime() is not posix but AFAIK there is nothing
>> else.
>> Ultimate goal would be letting an NTP client use adjtime().
>> Maybe even a better idea would be incorporating the Mills algorithm
>> into the system clock and add adjtimex() for tuning it with an NTP
>> client.
>> RFC - Till _______________________________________________
>> rtems-users mailing list rtems-users at

More information about the users mailing list