[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 2 Jun 2011 08:11:05 +0200
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: adjtime()
Answering from phone at tram stop in Munich so I apologize for the brevity.
I looked at adjtime() yesterday to answer a question. It reflects when internal time in score was in Classic API TOD format. Now it is in struct timespec. I believe that if adjust were using score TOD, it would be simple to just add/subtract with current TOD and adjust the seconds watchdog chain by the proper number of seconds boundaries crossed in either direction. You probably want to disable TOD updates (exists), maybe wait/poll for next clock tick, and adjust watchdog seconds chain in some order.
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.
>rtems-users mailing list
>rtems-users at rtems.org