FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 07-04-2012, 09:19 PM
Tom Gundersen
 
Default Leap seconds ntp and chrony?

On Wed, Jul 4, 2012 at 11:06 PM, Mauro Santos
<registo.mailling@gmail.com> wrote:
> On 04-07-2012 21:00, Tom Gundersen wrote:
>> On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>>>> If you have a
>>>> mercurial/git installation even in a small group, I am sure you'll prefer
>>>> accurate timestamps in your commit history. And the list goes on...
>>>
>>> I believe an RTC is perfectly capable of that.
>>
>> I tried to find some data on what to expect from RTC's. I was not very
>> successful, except finding people citing 80-100PPM as typical drift
>> rates (~8 secs/day).
>
> From data I have access to, taken from machines running ntpd, I can say
> the following about the drift in PPM stored in ntpd's drift file:
>
> my laptop: -9.699
> machine 1: -8.762
> machine 2: -443.266
> machine 3: -35.417
>
> Machine 1 is the newest and machine 3 is the oldest.

One more data point: my wrist watch is off by about 20ppm (unless I
forget to wind it, then it is more ;-) ).

-t
 
Old 07-04-2012, 09:57 PM
Kevin Chadwick
 
Default Leap seconds ntp and chrony?

> I lose about 14 PPM, which amounts to
> roughly seven minutes in a year.
>

Try disabling ntp for a week. Set your clock to atomic manually. By
your reckoning you should be out by over eight seconds in a week. Let's
see?

> Having that kind of discrepancies on a network doing distributed
> development would wreck absolute havoc.

Why?

--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______
 
Old 07-04-2012, 11:11 PM
Leonid Isaev
 
Default Leap seconds ntp and chrony?

On Wed, 04 Jul 2012 22:06:27 +0100
Mauro Santos <registo.mailling@gmail.com> wrote:

> On 04-07-2012 21:00, Tom Gundersen wrote:
> > On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk>
> > wrote:
> >>> If you have a
> >>> mercurial/git installation even in a small group, I am sure you'll prefer
> >>> accurate timestamps in your commit history. And the list goes on...
> >>
> >> I believe an RTC is perfectly capable of that.
> >
> > I tried to find some data on what to expect from RTC's. I was not very
> > successful, except finding people citing 80-100PPM as typical drift
> > rates (~8 secs/day).
>
> From data I have access to, taken from machines running ntpd, I can say
> the following about the drift in PPM stored in ntpd's drift file:
>
> my laptop: -9.699
> machine 1: -8.762
> machine 2: -443.266
> machine 3: -35.417
>
> Machine 1 is the newest and machine 3 is the oldest.

AFAIK comparing RTCs on different machines is meaningless because there seem
to be no quality handle for RTC. So, RTC may exist or not, but you can't
choose (and therefore guarantee) to have a good RTC, at least on consumer (not
server) motherboards. NTPD on the other hand implements a protocol $equiv$
standard.

FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours.

Re machine 2 -- I bet your CMOS battery is dying.

>
> > Having a look at my own machine (a reasonably new Dell laptop) I don't
> > see values quite that bad. I lose about 14 PPM, which amounts to
> > roughly seven minutes in a year.
> >
> > Having that kind of discrepancies on a network doing distributed
> > development would wreck absolute havoc.
> >
> > -t
> >
>
>



--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
 
Old 07-05-2012, 09:10 AM
C Anthony Risinger
 
Default Leap seconds ntp and chrony?

On Wed, Jul 4, 2012 at 6:11 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
> On Wed, 04 Jul 2012 22:06:27 +0100
> Mauro Santos <registo.mailling@gmail.com> wrote:
>>
>> From data I have access to, taken from machines running ntpd, I can say
>> the following about the drift in PPM stored in ntpd's drift file:
>>
>> my laptop: -9.699
>> machine 1: -8.762
>> machine 2: -443.266
>> machine 3: -35.417
>>
>> Machine 1 is the newest and machine 3 is the oldest.
>
> AFAIK comparing RTCs on different machines is meaningless because there seem
> to be no quality handle for RTC. So, RTC may exist or not, but you can't
> choose (and therefore guarantee) to have a good RTC, at least on consumer (not
> server) motherboards. NTPD on the other hand implements a protocol $equiv$
> standard.
>
> FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours.
>
> Re machine 2 -- I bet your CMOS battery is dying.

per NTP FAQ, as basis for estimate:

http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm#AEN1220

"[...] I'll simply state that 12 PPM correspond to one second per day roughly."

... actual value is (1/86400)*1000000 = 11.574.

-9.375 = local server (never off/moved)
-22.538 = docked laptop (never off/moved)
-65.089 = remote server (linode.com [xen])

so my local clocks run a wee bit hot (and xen clocksource sucks?).
since kerberos clockskew defaults to 300 seconds, i would begin to
perm fail authentication (local -> remote server) after ...

p = ppm, s = sec, d = day

s / ( p / ( p / ( s / d ) ) )
s / ( p * ( ( s / d ) / p ) )
s / ( s / d )
s * ( d / s )
d

skew-sec-max / ( ABS(skew-ppm-var) / skew-ppm-per-sec-per-day )

300 / (( 65 - 9 ) / 12 )

... 62.32 days, or ~2 months [annoying] ... yay for NTP!

... (and also math! if it's correct!) clearly i went a bit overboard,
but it seems like the only thing you can depend on is RTC failing you
0-12 times-per-year, depending on your gear and sensitivity to time
variance.

although, it would be cool if authenticated NTP were more
widespread/ubiquitous -- a la Windows time service [signed packets] --
but since i've never cared much about it i'm probably just not aware
...

--

C Anthony
 
Old 07-05-2012, 01:22 PM
Mauro Santos
 
Default Leap seconds ntp and chrony?

On 05-07-2012 00:11, Leonid Isaev wrote:

> Re machine 2 -- I bet your CMOS battery is dying.

That may well be the case, but it is an always on machine with ups
backup, and it hasn't been shutdown for a good while now. I thought that
while the system is powered on the rtc would get power from the mains
and not from the battery, at least that is the experience I have with
machines where the battery has died for good.

--
Mauro Santos
 
Old 07-05-2012, 06:16 PM
Kevin Chadwick
 
Default Leap seconds ntp and chrony?

> "[...] I'll simply state that 12 PPM correspond to one second per day roughly.

I'm skeptical and am more inclined to think ntp has measurement
problems or a decimal has been missed or something but it's easy to
check with real world direct simple data which I always prefer, so we
shall see.

The reason I am skeptical is I have lots of machines that don't use ntp
and I'd expect but of course could be very wrong that I would have
noticed if I had to fix the clocks by 8 minutes per year. I'll mark
this mail and let the list know.

What I am less likely to get around to is comparing this data to what
ntp would suggest the skew is for each machine, but no matter for now.


--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______
 
Old 07-06-2012, 03:38 PM
C Anthony Risinger
 
Default Leap seconds ntp and chrony?

On Thu, Jul 5, 2012 at 1:16 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> "[...] I'll simply state that 12 PPM correspond to one second per day roughly.
>
> I'm skeptical and am more inclined to think ntp has measurement
> problems or a decimal has been missed or something but it's easy to
> check with real world direct simple data which I always prefer, so we
> shall see.

that value [12ppm] is correct -- `ppm` is a dimensionless ratio
between 0 and 1; units *must* cancel, leaving only a pure coefficient
which is then scaled to X/1,000,000 by multiplying by some N/N scaling
factor.

since there are 86400 seconds in one day, expressing a 1 second loss
per day is the same as saying a 1 second loss per 86400 seconds, or:

0.0000115 = 1/86400
0.0000115 = 1/86400 * (11.57/11.57)
0.0000115 = 11.57/1000000
0.0000115 = 11.57 ppm

... even Wikipedia says:

"One part per million (ppm) denotes one part per 1,000,000 parts [...]
or about 32 seconds out of a year."

... if 1 ppm is ~32 seconds per year, then 12 ppm is ~384 per year: a
little over 1 per day :-)

--

C Anthony
 

Thread Tools




All times are GMT. The time now is 10:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org