gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Clarifications needed for the time-service HOWTO


From: Harlan Stenn
Subject: Re: [gpsd-dev] Clarifications needed for the time-service HOWTO
Date: Fri, 25 Oct 2013 00:44:07 +0000

"Gary E. Miller" writes:
> 
> On Thu, 24 Oct 2013 18:54:09 -0400
> "Eric S. Raymond" <address@hidden> wrote:
> 
> > Er...I don't think so.  For practical purposes that's the single most=20
> > important error bound in the entire document.  If we say nothing
> > about it the readers will feel cheated, and I believe justifiably so.
> 
> We need to say something about it.  But we need to say it is more
> dependent on the users internet connection, and the path to the chimers,
> than the chimers themselves.
> 
> > The proper thing to do here, I think, is give a range of measurements
> > and say "This is what we've observed.  These are other peoples'
> > observations. Take with small Siberian salt mine."
> 
> Yes.  And that will take a range of answers.o
> So far I;ve been seeing under +/- 10 mSec offset and under +/- 1
> mSec of jitter, but that is on a high speed connection on the lightly
> loaded server.

On my laptop in San Jose with cable modem access I'm seeing jitter to
time.apple.com of about 36ms and to the pool of 3.9, 6.8, 43.9, and 173
ms.  As I recall, my DSL connection in southern OR does better.

For machines on one LAN, I see jitter of 1.18 and <3.5ms, while the
machines on another LAN are at <0.16ms, and on another LAN the jitter is
< 0.04ms.

> > Even if we end up with an order-of-magnitude range and a note saying
> > "For such an important number this one is controversial and hard to
> > pin down" that will be better than punting the issue.
> 
> Yes.  I don't mean to punt it, but rather mention it is an attribute
> the user has, not the chimer.

I think so too.

And time and technology change - these are moving targets.

H



reply via email to

[Prev in Thread] Current Thread [Next in Thread]