adjtime()

[Joel Sherrill]

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