# adjtimex (syscall) apparently does not work

## lanzz

hello,

i'm trying to set up clockspeed on my box to adjust for the clock drift. after running it for a while, supplying it with a sntpclock input from time to time, and not seeing any results, a strace showed that clockspeed is actually trying to adjust the clock using the adjtimex system call, which always returns 5 (TIME_ERROR) and does not have any effect on the clock. i've tried other timekeeping apps (openrdate, ntp), and ALL of them simply do not work when configured to use adjtimex instead of settimeofday.

i'm already out of ideas what to try so any pointers will be helpful.

----------

## Malvineous

Worked fine for me when I last used it (I just stick with NTP now.)  Are you running the app as root?  You're not running an ancient kernel?

----------

## lanzz

running as root, kernel 2.6.30-gentoo-r4. strace shows the actual adjtimex syscall, but time is not changed.

----------

## Malvineous

You do realise that adjtimex doesn't actually change the system time, rather it speeds up or slows down the system clock to make it more accurate?

IIRC correctly it can also "slew" the clock, which involves adjusting the speed quite dramatically so after a day or so the time will end up correct.  This is done so that programs don't misbehave when there is a sudden jump in the clock time.

In other words, you won't notice an immediate change in the clock time after the adjtimex call.

----------

## lanzz

yes, i do realize this. however i've been monitoring the clock difference against a (s)ntp server for some time (tens of minutes) after the adjtimex call, and the difference seems constant. if it is speeding up the clock at all (my clock is running slow), it would take ages for it to reach the correct time, which doesn't seem right. the idea of adjusting the clock gradually is that time-sensitive apps do not see jumps in time, and i don't think it is necessary to take a whole day to adjust a twenty second difference. i know the adjtimex call can be used to configure the kernel timekeeping to adjust for clock drift in-kernel, but it seems unlikely that a time synchronization app like openrdate or clockspeed would adjust the speed of the kernel clock without setting it to the correct time as well. so it either should adjust the speed and set the correct time, or it should gradually adjust the clock until it is correct. i admit i'm not entirely sure which of these two things should happen with adjtimex, but the behavior that i'm observing is that neither happens.

----------

## Malvineous

It may not be necessary to take a whole day to adjust 20 seconds of difference, but that's the point of adjtimex.  It's meant to make the change so slowly that nothing will notice.

If you want the time adjusted faster than that, you'll need to use some other program to set the time first, then use adjtimex to keep the clock from drifting too far away.  I use the 'ntpdate' command which sets the system clock immediately via NTP during the system boot, then after that adjtimex keeps it fairly accurate.

Adjtimex is after all meant for adjusting the kernel time structures, not actually setting the time - there are different methods in place for that.

----------

