linux-kernel - Re: Kernel unable to adjust timeofday

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Sep 2008 12:49:02 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Valdis.Kletnieks@...edu
CC:	Rafal <newsgroup@...core.com>, linux-kernel@...r.kernel.org
Subject: Re: Kernel unable to adjust timeofday

Valdis.Kletnieks@...edu wrote:
> On Fri, 26 Sep 2008 15:29:53 +0200, Rafal said:
>> Hello, my system (64bit Ubuntu amd64 box) drifts about 10 seconds per hour
>> (i.e. time visible in the system).
> 
> First thing to do is figure out why your box has *such* a dreadfully poor
> clock. You're drifting at around 3,000 parts-per-million.  NTP is only able
> to deal with drifts up to 500 ppm, and most systems clocks are *much* more
> stable than that (for instance, my laptop is drifting at 2 ppm at the moment).
> The fact you're way outside the sane range leads to trouble...
> 

There are two possibilities:

Either, his system uses a ceramic oscillator instead of a crystal.  In 
that case, you're screwed.  Those can be ±10,000 ppm or more.  The other 
is that he is on a system which has a wrong frequency crystal installed 
for what the time base expects (usually 14.31818 MHz on PCs) -- say 15 
MHz.  In that case the clock is still stable, it's just *inaccurate*.

In the latter case, the adjtimex(8) command can be used to tell the 
kernel the approximate rate the clock is ticking, and then let NTP do 
the fine-tuning.

If you have manually determined that you are gaining 244 seconds in 24 
hours of free-running operation, you would use the following formula to 
calculate the tick interval:

            S
tick =  -------- * 10000
          G + S

... where S is the real sample interval (24 hours = 86400 seconds) and G 
is the amount of time gained in that time (244 seconds in this case); if 
you are *losing* time then G would be negative.

In this case:
            86400
tick = ------------- * 10000 = 9971.8 ~ 9972
         244 + 86400

So you would set:

adjtimex --tick 9972

... in your startup scripts, before ntpd is started.

If NTP still goes off the rails, then adjust the tick value in steps of 
about 5 until you can get it to converge.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/