adjtime()

[Till Straumann]

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.

T.

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 slac.stanford.edu>  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 rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users