Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #520 > unrolled thread

time server ??

Back to article view | Back to comp.os.linux.networking

Contents

  time server ?? Andre <pas@pourmois.be> - 2011-08-26 07:34 +0000
    Re: time server ?? Thad Floryan <thad@thadlabs.com> - 2011-08-26 00:48 -0700
      Re: time server ?? Andre <pas@pourmois.be> - 2011-08-26 08:30 +0000
      Re: time server ?? unruh <unruh@wormhole.physics.ubc.ca> - 2011-08-26 14:13 +0000
    Re: time server ?? unruh <unruh@wormhole.physics.ubc.ca> - 2011-08-26 14:09 +0000
    Re: time server ?? passion.rp@gmail.com - 2013-03-15 00:27 -0700
      Re: time server ?? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-03-15 11:26 +0000
        Re: time server ?? Michael Black <et472@ncf.ca> - 2013-03-15 20:33 -0400
          Re: time server ?? J G Miller <miller@yoyo.ORG> - 2013-03-16 15:31 +0000
          Re: time server ?? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-03-18 21:01 +0000
      Re: time server ?? unruh <unruh@invalid.ca> - 2013-03-15 15:47 +0000
        Re: time server ?? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2013-03-17 11:43 +0100
          Re: time server ?? J G Miller <miller@yoyo.ORG> - 2013-03-17 14:36 +0000
            Re: time server ?? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2013-03-17 18:20 +0000
              Re: time server ?? Chris Davies <chris-usenet@roaima.co.uk> - 2013-03-18 13:16 +0000
                Re: time server ?? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2013-03-18 19:53 +0000
                  Re: time server ?? unruh <unruh@invalid.ca> - 2013-03-18 20:40 +0000
                    Re: time server ?? Chris Davies <chris-usenet@roaima.co.uk> - 2013-03-19 10:58 +0000
                    Re: time server ?? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2013-03-19 19:55 +0000
                      Re: time server ?? unruh <unruh@invalid.ca> - 2013-03-19 20:32 +0000
                        Re: time server ?? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2013-03-20 03:25 +0000
                          Re: time server ?? unruh <unruh@invalid.ca> - 2013-03-20 16:28 +0000
                            Re: time server ?? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2013-03-21 03:37 +0000

Page 1 of 2  [1] 2  Next page →

#520 — time server ??

do you know a time server? 
I use to use time.windows.com, but since a while it seems to have stopped 
services.
Many thanks
Andre

[toc] | [next] | [standalone]

#521

On 8/26/2011 12:34 AM, Andre wrote:
> do you know a time server? 
> I use to use time.windows.com, but since a while it seems to have stopped 
> services.

ntp.ubuntu.com works well
pool.ntp.org is another

A list of all public servers:

    <http://support.ntp.org/bin/view/Servers/WebHome>

This page <http://support.microsoft.com/kb/262680> lists:

    For the list of stratum one time servers, visit the following Web site:
    https://support.ntp.org/bin/view/Servers/StratumOneTimeServers

    For the list of stratum two time servers, visit the following Web site:
    https://support.ntp.org/bin/view/Servers/StratumTwoTimeServers

    For the list of NIST Internet Time Servers, visit the following Web site:
    http://tf.nist.gov/tf-cgi/servers.cgi

    For the list of NTP Pool Servers, visit one of the following Web sites:
    https://support.ntp.org/bin/view/Servers/NTPPoolServers

    http://www.pool.ntp.org

[toc] | [prev] | [next] | [standalone]

#522

Le Fri, 26 Aug 2011 00:48:36 -0700, Thad Floryan a écrit :

> On 8/26/2011 12:34 AM, Andre wrote:
>> do you know a time server?
>> I use to use time.windows.com, but since a while it seems to have
>> stopped services.
> 
> ntp.ubuntu.com works well
> pool.ntp.org is another
> 
> A list of all public servers:
> 
>     <http://support.ntp.org/bin/view/Servers/WebHome>
> 
> This page <http://support.microsoft.com/kb/262680> lists:
> 
>     For the list of stratum one time servers, visit the following Web
>     site: https://support.ntp.org/bin/view/Servers/StratumOneTimeServers
> 
>     For the list of stratum two time servers, visit the following Web
>     site: https://support.ntp.org/bin/view/Servers/StratumTwoTimeServers
> 
>     For the list of NIST Internet Time Servers, visit the following Web
>     site: http://tf.nist.gov/tf-cgi/servers.cgi
> 
>     For the list of NTP Pool Servers, visit one of the following Web
>     sites: https://support.ntp.org/bin/view/Servers/NTPPoolServers
> 
>     http://www.pool.ntp.org

Many thanks for your answer.
Andre

[toc] | [prev] | [next] | [standalone]

#524

On 2011-08-26, Thad Floryan <thad@thadlabs.com> wrote:
> On 8/26/2011 12:34 AM, Andre wrote:
>> do you know a time server? 
>> I use to use time.windows.com, but since a while it seems to have stopped 
>> services.
>
> ntp.ubuntu.com works well
> pool.ntp.org is another
>
> A list of all public servers:
>
>     <http://support.ntp.org/bin/view/Servers/WebHome>
>
> This page <http://support.microsoft.com/kb/262680> lists:
>
>     For the list of stratum one time servers, visit the following Web site:
>     https://support.ntp.org/bin/view/Servers/StratumOneTimeServers

So not use a stratum one server unless you have permission from the
owner of that server. 

Stratum one are totally unnecessary unless you really really need
microsecond accuracy in your timing.


pool.ntp.org is the best  address to use. It is a grouping of many thousands of
servers all of whom have given permission to have their meachines used
as public servers. When you do a dns request on pool.ntp.org you will
get one of those thousands of servers randomly. 


>
>     For the list of stratum two time servers, visit the following Web site:
>     https://support.ntp.org/bin/view/Servers/StratumTwoTimeServers
>
>     For the list of NIST Internet Time Servers, visit the following Web site:
>     http://tf.nist.gov/tf-cgi/servers.cgi
>
>     For the list of NTP Pool Servers, visit one of the following Web sites:
>     https://support.ntp.org/bin/view/Servers/NTPPoolServers
>
>     http://www.pool.ntp.org

[toc] | [prev] | [next] | [standalone]

#523

On 2011-08-26, Andre <pas@pourmois.be> wrote:
> do you know a time server? 
> I use to use time.windows.com, but since a while it seems to have stopped 
> services.
> Many thanks
> Andre

pool.ntp.org

[toc] | [prev] | [next] | [standalone]

#2026

On Friday, 26 August 2011 03:34:16 UTC-4, Andre  wrote:
> do you know a time server? 
> I use to use time.windows.com, but since a while it seems to have stopped 
> services.
> Many thanks
> Andre

[toc] | [prev] | [next] | [standalone]

#2027

On Fri, 2013-03-15, passion.rp@gmail.com wrote:
> On Friday, 26 August 2011 03:34:16 UTC-4, Andre  wrote:
>> do you know a time server? 
>> I use to use time.windows.com, but since a while it seems to have stopped 
>> services.

Doesn't your Linux distribution suggest NTP servers?  Debian has
<n>.debian.pool.ntp.org.

Or google "public ntp time server".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2033

On Fri, 15 Mar 2013, Jorgen Grahn wrote:

> On Fri, 2013-03-15, passion.rp@gmail.com wrote:
>> On Friday, 26 August 2011 03:34:16 UTC-4, Andre  wrote:
>>> do you know a time server?
>>> I use to use time.windows.com, but since a while it seems to have stopped
>>> services.
>
> Doesn't your Linux distribution suggest NTP servers?  Debian has
> <n>.debian.pool.ntp.org.
>
> Or google "public ntp time server".
>
> /Jorgen
>
Don't you think a year and a half after he posted that he's either no 
longer interested, or has long ago figured out a solution?

Just because google lets people reply to messages older than 30 days old 
doesn't mean people should.  That post from August of 2011, your quote 
even shows the date of the original, even had a decent number and quality 
of replies.  There's no reason to resurrect an old thread now.

That said, I have no idea why the previous poster dug up the old thread, 
but he had nothing to say, he just quoted an old post, perhaps at random, 
and you replied to that.

The guy may have been spamming, except he forgot to add his spam.  I ahve 
seen instances of people replyging to old messages in order to spam.

   Michael

[toc] | [prev] | [next] | [standalone]

#2034

On Friday, March 15th, 2013, at 20:33:01h -0400, Michael Black suggested:

> The guy may have been spamming, except he forgot to add his spam.  I ahve 
> seen instances of people replyging to old messages in order to spam.

Or perhaps to test their spamming software.

[toc] | [prev] | [next] | [standalone]

#2043

On Sat, 2013-03-16, Michael Black wrote:
> On Fri, 15 Mar 2013, Jorgen Grahn wrote:
>
>> On Fri, 2013-03-15, passion.rp@gmail.com wrote:
>>> On Friday, 26 August 2011 03:34:16 UTC-4, Andre  wrote:
>>>> do you know a time server?
>>>> I use to use time.windows.com, but since a while it seems to have stopped
>>>> services.
>>
>> Doesn't your Linux distribution suggest NTP servers?  Debian has
>> <n>.debian.pool.ntp.org.
>>
>> Or google "public ntp time server".
>>
>> /Jorgen
>>
> Don't you think a year and a half after he posted that he's either no 
> longer interested, or has long ago figured out a solution?

See below.

> Just because google lets people reply to messages older than 30 days old 
> doesn't mean people should.  That post from August of 2011, your quote 
> even shows the date of the original, even had a decent number and quality 
> of replies.  There's no reason to resurrect an old thread now.

See below.

> That said, I have no idea why the previous poster dug up the old thread, 
> but he had nothing to say, he just quoted an old post, perhaps at random, 
> and you replied to that.

Guilty as charged -- I never use Google Groups and I never reply to
ancient postings, but I didn't spot the old date on the actual question.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2028

On 2013-03-15, passion.rp@gmail.com <passion.rp@gmail.com> wrote:
> On Friday, 26 August 2011 03:34:16 UTC-4, Andre  wrote:
>> do you know a time server? 
>> I use to use time.windows.com, but since a while it seems to have stopped 
>> services.
>> Many thanks
>> Andre
>

pool.ntp.org

EVery time it is called it gives a new ntp source. 

[toc] | [prev] | [next] | [standalone]

#2037

Hello,

unruh a écrit :
> 
> pool.ntp.org
> 
> EVery time it is called it gives a new ntp source. 

Actually it appears to give 4 sources every 150 seconds.

[toc] | [prev] | [next] | [standalone]

#2038

le dimanche, 17 mars, 2013, á 11:43:33h +0100, Pascal Hambourg a écrit:

> unruh a écrit :
>> 
>> pool.ntp.org
>> 
>> EVery time it is called it gives a new ntp source. 
> 
> Actually it appears to give 4 sources every 150 seconds.

And rather than use pool.ntp.org, it is advisable and preferable
to see if there is a "national" pool to use instead,
eg for those living in Canuckistan, ca.pool.ntp.org
or for those in the hexagon, fr.pool.ntp.org, or those
in Deutschland, de.pool.ntp.org, etc etc.

Even Andorra has its own pool designation, ad.ntp.pool.org,
actually provided by somebody else at hover.com which 
also serves for the Faroe Islands and probably
quite a few others.

After all it makes sense to use the time servers
closest to your location in order to minimize delays.

[toc] | [prev] | [next] | [standalone]

#2039

On Sun, 17 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
article <ki4kcp$dru$2@dont-email.me>, J G Miller wrote:

>And rather than use pool.ntp.org, it is advisable and preferable
>to see if there is a "national" pool to use instead,
>eg for those living in Canuckistan, ca.pool.ntp.org
>or for those in the hexagon, fr.pool.ntp.org, or those
>in Deutschland, de.pool.ntp.org, etc etc.

More useful in "spreading the load" than anything else.

>Even Andorra has its own pool designation, ad.ntp.pool.org,
>actually provided by somebody else at hover.com which 
>also serves for the Faroe Islands and probably
>quite a few others.

[fermi ~]$ host ad.ntp.pool.org
ad.ntp.pool.org has address 64.99.80.30
[fermi ~]$ whois 64.99.80.30
   [SNIP]
    96 Mowat Avenue
    Toronto, ON M6K 3M1
    CA
   [SNIP]
[fermi ~]$

>After all it makes sense to use the time servers
>closest to your location in order to minimize delays.

Physical distance does not reliably translate into network distance.
Above, the last I looked neither Andorra or the Faroe Islands are
located on or close to Mowat Avenue in Toronto, Canada.

One need only play with tools like hping2, hping3, mtr, nmap,
tracepath, traceroute and/or tcptraceroute to discover things about
network distances which translate into timing delays.  The man page
for the original LBL traceroute (contained in the tarball at
ftp://ftp.ee.lbl.gov/traceroute.tar.gz) has more details than the
man page from the traceroute.sourceforge.net version found in many
current distributions or the rewrite from Olaf Kirch then at Caldera.

Further, you really do want to read and understand RFC5905

  5905 Network Time Protocol Version 4: Protocol and Algorithms
       Specification. D. Mills, J. Martin, Ed., J. Burbank, W. Kasch.
       June 2010. (Format: TXT=241096 bytes) (Obsoletes RFC1305,
       RFC4330) (Status: PROPOSED STANDARD)

although the explanation in Appendix H of RFC1305

  1305 Network Time Protocol (Version 3) Specification, Implementation
       and Analysis. D. Mills. March 1992. (Format: TXT=307085,
       PDF=442493 bytes) (Obsoletes RFC0958, RFC1059, RFC1119)
       (Obsoleted by RFC5905) (Status: DRAFT STANDARD)

may be more readable.  The TimePrecision-HOWTO from the Linux Doc
Project is also a useful document:

-rw-rw-r-- 1 gferg   ldp        43295 Nov 18  2005 TimePrecision-HOWTO

        Old guy

[toc] | [prev] | [next] | [standalone]

#2040

Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
> [fermi ~]$ host ad.ntp.pool.org
> ad.ntp.pool.org has address 64.99.80.30
> [fermi ~]$ whois 64.99.80.30
>   [SNIP]
>    96 Mowat Avenue
>    Toronto, ON M6K 3M1
>    CA
>   [SNIP]
> [fermi ~]$

> Above, the last I looked neither Andorra or the Faroe Islands are
> located on or close to Mowat Avenue in Toronto, Canada.

I don't see anything in the original whois record that says 64.99.80.30
itself is in Toronto. What you picked out is actually the address provided
by the Tucows.com registrar (see the two lines above your SNIP mark).

Now back to the question about the ntp.pool.org. The
recommendation is to use your country code designation in the Pool,
eg. {0,1,2,3}.uk.ntp.pool.org, but this isn't essential. The advantage
is that if local servers become available they will rotate into the
Pool. If no such servers are available then you're no worse off than if
you'd just used the global ntp.pool.org anyway.

See http://www.pool.ntp.org/en/use.html

It may be important to be aware that the Pool does not guarantee to
deliver time with an accuracy of better than one second (I can't find
a reference to this; I think it was on the mailing list a year or
so back.) That operators such as myself can usually deliver at NTP
accuracies of considerably better than this is a bonus. Many of us
are on ADSL links and the inherent assymetry upsets NTP's algorithms
sufficiently that millisecond accuracy simply isn't possible.

Chris

[toc] | [prev] | [next] | [standalone]

#2041

On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
article <plgj1axf8c.ln2@news.roaima.co.uk>, Chris Davies wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>> [fermi ~]$ host ad.ntp.pool.org
>> ad.ntp.pool.org has address 64.99.80.30
>> [fermi ~]$ whois 64.99.80.30
>>   [SNIP]
>>    96 Mowat Avenue
>>    Toronto, ON M6K 3M1
>>    CA
>>   [SNIP]
>> [fermi ~]$

>> Above, the last I looked neither Andorra or the Faroe Islands are
>> located on or close to Mowat Avenue in Toronto, Canada.

>I don't see anything in the original whois record that says
>64.99.80.30 itself is in Toronto. What you picked out is actually
>the address provided by the Tucows.com registrar (see the two lines
>above your SNIP mark).

True enough - but my reply continued:

]One need only play with tools like hping2, hping3, mtr, nmap,
]tracepath, traceroute and/or tcptraceroute to discover things about
]network distances which translate into timing delays.

and tracing via two different bandwidth providers here in Phoenix
(about 360 miles/600 KM East of Los Angeles) takes me via two
different backbones to routers at "mag01.yyz02.atlas.cogentco.com"
(where YYZ is the IATA code for Toronto) or "Toronto1.Level3.net",
thence to a router that isn't providing ICMP errors, then to a router
with no PTR record on the 216.40.38.x subnet belonging to Tucows.com,
thence to the above IP (with a PTR of url.hover.com).  Tracing with
UDP packets shows a significant scatter in the overall time delays.

>The advantage is that if local servers become available they will
>rotate into the Pool.

i.e. spreading the load - which is good.  There is an advantage if
the "local" server is actually on the same backbone.  In some
countries, there are effectively only one, and routing tends to be
more efficient (possibly less convoluted).  In other countries, all
bets are off.  Doing a trace from my house to Arizona State
University (about 30 miles/48 km South) shows my packets being
routed through Los Angeles - because my ISP and the university don't
have connections to the same backbones.   People also tend to forget
that routing is not symmetrical.  My packets go out via my default
route, the ISP forwards them onto what appears (to them) to be the
"best" route at the moment.  The packets being sent in reply leave the
server via the route that appears (to the bandwidth provider the
server is connected to) to be the "best" route at the moment, but
where there are multiple routes between "A" and "B", the route "to"
is less likely to match the route "from".

>It may be important to be aware that the Pool does not guarantee to
>deliver time with an accuracy of better than one second (I can't find
>a reference to this; I think it was on the mailing list a year or
>so back.)

That's usually more than adequate for nearly all users.  People tend
to forget that the oscillators used for clock timing in computers are
commodity grade, and are typically good to +/-100 ppm _overall_
accuracy (includes "setting" and "thermal" errors).   Even if the
system clock is disciplined to an external reference, changes in
temperatures INSIDE the computer can cause temporary errors.  A mere
11.6 ppm error is a second a day.  For those few who actually require
millisecond (or better) accuracy, satellite timing receivers are
cheap and actually designed for that goal.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2042

On 2013-03-18, Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
> On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
> article <plgj1axf8c.ln2@news.roaima.co.uk>, Chris Davies wrote:
>
>>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
>
...
>
>>It may be important to be aware that the Pool does not guarantee to
>>deliver time with an accuracy of better than one second (I can't find
>>a reference to this; I think it was on the mailing list a year or
>>so back.)
>
> That's usually more than adequate for nearly all users.  People tend
> to forget that the oscillators used for clock timing in computers are
> commodity grade, and are typically good to +/-100 ppm _overall_

But that is really irrelevant, since the whole purpose of ntp is to
discipline the oscillator, or more accurately the translation from the
oscillator to the time ticks of the computer to far better than that.
Thus under an ntp discipline, those "commercial grade" oscillators can
deliver time to tens of micro (not milli) second accuracy. 
Thermal problems may create slow drifts, but the also get taken care of
(nptd tends to be less accurate than say chrony because of its very slow
response to changes like thermal changes).

> accuracy (includes "setting" and "thermal" errors).   Even if the
> system clock is disciplined to an external reference, changes in
> temperatures INSIDE the computer can cause temporary errors.  A mere
> 11.6 ppm error is a second a day.  For those few who actually require

Except the thermal drifts tend to be significantly less than that (say
1PPM) and ntpd or chrony will catch it long before a day. 

> millisecond (or better) accuracy, satellite timing receivers are
> cheap and actually designed for that goal.

They still operate by disciplining the local clock on the computer. But
if you have a high accuracy souce on your own network, you can easily
get tens of micro second accuracy, and if you use a $30 GPS receiver,
about 2 microsecond accuracy on that commercial grade computer
equipment.

Ie, the problem with time,keeping is NOT the computer oscillator. It is
the network. 
>
>         Old guy

[toc] | [prev] | [next] | [standalone]

#2044

unruh <unruh@invalid.ca> wrote:
> Ie, the problem with time,keeping is NOT the computer oscillator. It is
> the network. 

Absolutely.
Chris

[toc] | [prev] | [next] | [standalone]

#2045

On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
article <bZK1t.298415$kp4.150932@newsfe09.iad>, unruh wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>> People tend to forget that the oscillators used for clock timing
>> in computers are commodity grade, and are typically good to +/-100
>> ppm _overall_

>But that is really irrelevant, since the whole purpose of ntp is to
>discipline the oscillator, or more accurately the translation from
>the oscillator to the time ticks of the computer to far better than
>that.  Thus under an ntp discipline, those "commercial grade"
>oscillators can deliver time to tens of micro (not milli) second
>accuracy. 

Under good conditions - I won't disagree, but I don't think it can
be guaranteed.  Computers are meant to compute, not act as accurate
time references.

>Thermal problems may create slow drifts, but the also get taken care
>of (nptd tends to be less accurate than say chrony because of its
>very slow response to changes like thermal changes).

While the (local) temperatures inside the computer tend to be fairly
stable (the computer acting somewhat like an oven around the crystal)
it's still going to be moving.   How often are you getting an NTP
update?

>> Even if the system clock is disciplined to an external reference,
>> changes in temperatures INSIDE the computer can cause temporary
>> errors.  A mere 11.6 ppm error is a second a day.

>Except the thermal drifts tend to be significantly less than that
>(say 1PPM) and ntpd or chrony will catch it long before a day. 

My Vectron and Bliley catalogs disagree with your numbers. I'm looking
at some specs to a fairly typical oscillator (US$3.46 in onesies, less
in production quantities) and they quote a setting accuracy of +/-50
ppm, a thermal stability of +/-100ppm over the range 0 to +60C and
similar values for supply voltage (+4.5 to +5.5 VDC). The so-called
typical thermal curve shown is "S" shaped, and is about 3 ppm/degreeC
at +40C, but at those prices I can almost guarantee that neither the
initial setting or drift rates are tested, never mind adjusted if that
were possible.  ("Is it functioning?" "Yes" "Ship it!")

>> For those few who actually require millisecond (or better)
>> accuracy, satellite timing receivers are cheap and actually
>> designed for that goal.

>They still operate by disciplining the local clock on the computer.

Not the ones I've used.

>But if you have a high accuracy souce on your own network, you can
>easily get tens of micro second accuracy, and if you use a $30 GPS
>receiver, about 2 microsecond accuracy on that commercial grade
>computer

Haven't been in the business for over twenty years, but the units I
worked with ("Timation"?  Something like that) had a IRIG-A/B/G serial
outputs as well as a IRIG PB1 parallel output - special interface card
in the computer.   We were looking for +/- 2 msec overall accuracy
and 1 msec resolution - the PB1 does that.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2046

On 2013-03-19, Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
> On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
> article <bZK1t.298415$kp4.150932@newsfe09.iad>, unruh wrote:
>
>>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
>
>>> People tend to forget that the oscillators used for clock timing
>>> in computers are commodity grade, and are typically good to +/-100
>>> ppm _overall_
>
>>But that is really irrelevant, since the whole purpose of ntp is to
>>discipline the oscillator, or more accurately the translation from
>>the oscillator to the time ticks of the computer to far better than
>>that.  Thus under an ntp discipline, those "commercial grade"
>>oscillators can deliver time to tens of micro (not milli) second
>>accuracy. 
>
> Under good conditions - I won't disagree, but I don't think it can
> be guaranteed.  Computers are meant to compute, not act as accurate
> time references.

But they are designed to compute by having a crystal clock the
computations through the cpu. Ie, it does act as a clock. 

>
>>Thermal problems may create slow drifts, but the also get taken care
>>of (nptd tends to be less accurate than say chrony because of its
>>very slow response to changes like thermal changes).
>
> While the (local) temperatures inside the computer tend to be fairly
> stable (the computer acting somewhat like an oven around the crystal)
> it's still going to be moving.   How often are you getting an NTP
> update?

Actually it is the internal temperature that is the problem, not the
room. When the computer is busy, the cpu makes more heat and the temp
inside rises. When it is not busy, the temp come much closer to room
temp. That can makea difference of 20-30C /

At poll 10 (2^10 sec) it gets a new report every 1/4 hr. But ntp throws
out about 7 of every 8 measurements, so ntp only looks at something like
once ever 2 hr. If it finds that the rate has deviated it will decrease
that by a factor of about 20. (ie every 10 min insteead of 2 hr). chrony
keeps all of the measurements and that is one of the reasons it responds
more quickly. If you use a gps, the standard is to measure every 16 sec.



>
>>> Even if the system clock is disciplined to an external reference,
>>> changes in temperatures INSIDE the computer can cause temporary
>>> errors.  A mere 11.6 ppm error is a second a day.
>
>>Except the thermal drifts tend to be significantly less than that
>>(say 1PPM) and ntpd or chrony will catch it long before a day. 
>
> My Vectron and Bliley catalogs disagree with your numbers. I'm looking
> at some specs to a fairly typical oscillator (US$3.46 in onesies, less
> in production quantities) and they quote a setting accuracy of +/-50
> ppm, a thermal stability of +/-100ppm over the range 0 to +60C and
> similar values for supply voltage (+4.5 to +5.5 VDC). The so-called
> typical thermal curve shown is "S" shaped, and is about 3 ppm/degreeC
> at +40C, but at those prices I can almost guarantee that neither the
> initial setting or drift rates are tested, never mind adjusted if that
> were possible.  ("Is it functioning?" "Yes" "Ship it!")

I think measurements trump data sheets. I have 8 computers that I
control. 

Anyway, thermal effects are around 1PPM. and the quoted accuracy is
irrelevant since the computer calibrates the oscillator ticking and does
not simply assume that x ticks equals one second. It measures it.


>
>>> For those few who actually require millisecond (or better)
>>> accuracy, satellite timing receivers are cheap and actually
>>> designed for that goal.
>
>>They still operate by disciplining the local clock on the computer.
>
> Not the ones I've used.

OK.

>
>>But if you have a high accuracy souce on your own network, you can
>>easily get tens of micro second accuracy, and if you use a $30 GPS
>>receiver, about 2 microsecond accuracy on that commercial grade
>>computer
>
> Haven't been in the business for over twenty years, but the units I
> worked with ("Timation"?  Something like that) had a IRIG-A/B/G serial
> outputs as well as a IRIG PB1 parallel output - special interface card
> in the computer.   We were looking for +/- 2 msec overall accuracy
> and 1 msec resolution - the PB1 does that.

And my GPS ($30) on my computer (commercial grade)  does about 3 microsecond accuracy. 
and my other machines connected via ethernet do about 10 microseconds.
Ie 1000 times better than you are quoting. 
serial and parallel port output is incredibly slow, if you are actually
using the data from them. If you use them for their interrupts, then you
can get microsecond accuracy. FOr nanosecond accuracy, you need special
hardware. 


>
>         Old guy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.networking

csiph-web