[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 02 Jun 2011 12:59:25 -0500
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: adjtime()
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
> 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.
> 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
>> 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
>> RFC - Till _______________________________________________
>> rtems-users mailing list rtems-users at rtems.org
- From: joel.sherrill at OARcorp.com (Joel Sherrill)