time server ??

[Andre]

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

[Thad Floryan]

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

[Andre]

Many thanks for your answer.
Andre

[unruh]

pool.ntp.org

[unruh]

On 2011-08-26, Thad Floryan <th...@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.

[passi...@gmail.com]

[Jorgen Grahn]

On Fri, 2013-03-15, passi...@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 .

[unruh]

pool.ntp.org

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

[Michael Black]

On Fri, 15 Mar 2013, Jorgen Grahn wrote:

> On Fri, 2013-03-15, passi...@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

[J G Miller]

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.

[Pascal Hambourg]

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.

[J G Miller]

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.

[Moe Trin]

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

[Chris Davies]

Moe Trin <ibup...@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

[Moe Trin]

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

>Moe Trin <ibup...@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

[unruh]

On 2013-03-18, Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:
> On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
> article <plgj1ax...@news.roaima.co.uk>, Chris Davies wrote:
>
>>Moe Trin <ibup...@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

[Jorgen Grahn]

On Sat, 2013-03-16, Michael Black wrote:
> On Fri, 15 Mar 2013, Jorgen Grahn wrote:
>
>> On Fri, 2013-03-15, passi...@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.

[Chris Davies]

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

Absolutely.
Chris

[Moe Trin]

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

>Moe Trin <ibup...@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

[unruh]

On 2013-03-19, Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:
> On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
> article <bZK1t.298415$kp4.1...@newsfe09.iad>, unruh wrote:
>
>>Moe Trin <ibup...@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

[Moe Trin]

On Tue, 19 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in

article <pX32t.209607$SE5.1...@newsfe28.iad>, unruh wrote:

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

>> 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.

Ah, but those clocks are separate from the clock the computer uses
to act as a time reference. Go back to the original IBM PC (4.77 MHz
8088) and the CPU was clocked at 4.77 MHz. Time of day was sourced
from a 1.8432 MHz crystal that was divided down to 18.0 Hz (IRQ 0). In
the modern PC, the CPU clock rate may actually be variable - Pentium
style CPUs throttle back the clock speed when they detect they're
overheating. That would play hell if the same clock were used as a
time of day function. Heck, my cell-phone has a clock in it as well,
but that doesn't make it a precision timing source either.

>> 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.

Actually when we started this racket, the boys a DIX had just
invented Ethernet - this goes back to about 1970 and several PDP-11s.
Network? Sure, you took the 10 inch reels of tape from one system
to another (the 360/something back at the center, 55 miles away).

>serial and parallel port output is incredibly slow, if you are
>actually using the data from them.

The parallel data was 36 bits wide (9 bits "day of year" and 27 bits
"milliseconds of day"). The serial data was slow - IRIG-B was one
frame (100 bits) per second, giving BCD time of year to a second.
IRIG-A was ten times that (and 1/10 second resolution) while IRIG-G
was another ten times better. The serial stuff could easily be
transmitted over a voice grade radio channel to the aircraft and
facilities around the airfield. We didn't use it, but there were
several other parallel standards that provided microsecond and
nanosecond resolution (56 bits as I recall). If you're not familiar
with "IRIG", that's the "Inter-Range Instrumentation Group" out of
White Sands Missile Range, and their standards are used both by other
government agencies and industry. When we started using PCs, there
was a special interface card (with a humongous 78 pin "D" submin
connector on the back) to mux the parallel data onto the ISA bus.

>If you use them for their interrupts, then you can get microsecond
>accuracy. FOr nanosecond accuracy, you need special hardware.

Used differently - as the computer was inhaling data from various
sources, it also took snapshots of the 36 bit time word. The data
was also stuffed out onto 1/2" tape (along with those time words) so
that post-flight processing could get more out of it than the PDPs
had CPU cycles for in real-time. We used essentially the same
setup/methods into the early 1990s. I'm told the separate parallel
clock mechanism is also mandated by the US government for certain
data archiving processes in the financial world.

Old guy

[unruh]

On 2013-03-20, Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:
> On Tue, 19 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
> article <pX32t.209607$SE5.1...@newsfe28.iad>, unruh wrote:
>
>>Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:
>
>>> 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.
>
> Ah, but those clocks are separate from the clock the computer uses
> to act as a time reference. Go back to the original IBM PC (4.77 MHz
> 8088) and the CPU was clocked at 4.77 MHz. Time of day was sourced
> from a 1.8432 MHz crystal that was divided down to 18.0 Hz (IRQ 0). In
> the modern PC, the CPU clock rate may actually be variable - Pentium
> style CPUs throttle back the clock speed when they detect they're
> overheating. That would play hell if the same clock were used as a
> time of day function. Heck, my cell-phone has a clock in it as well,
> but that doesn't make it a precision timing source either.

But what I am saying is that the main problem with those consumer grade
oscillators is that they are not tested to any great accuracy, but that
is primarily a calibration problem, and when properly calibrated
(differently for each crystaL) they are good to a muche beter than 1PPM
except for temperature fluctuation, which gives you maybe 1PPM per C if
bad, and that can also be calibrated out. (That is what ntpd does-- a
running alcibration)

Well, yes, in the past timekeeping was poorer. In 1600 you could get
about 20 second accuracy from a sundial. In the 1700 about 1 sec from
pendulum clocks and then spring wound clocks. By 1900 you were getting
down to ms. Again the pendulum and spring clocks has to be calibrated
against sundials occasionally since they had PPK to 10s of PPM rate
drifts ( and with the navigation watches in the 1800s , down to PPM rate drifts).

But now computers are down to microsecond accuracy for cheap crystals,
and better than PPT (Parts per tera). for the better clocks.


> Old guy

[Moe Trin]

On Wed, 20 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
article <usl2t.17125$n%7.1...@newsfe20.iad>, unruh wrote:

>But what I am saying is that the main problem with those consumer
>grade oscillators is that they are not tested to any great accuracy,
>but that is primarily a calibration problem, and when properly
>calibrated (differently for each crystaL) they are good to a muche
>beter than 1PPM except for temperature fluctuation, which gives you
>maybe 1PPM per C if bad, and that can also be calibrated out. (That
>is what ntpd does-- a running alcibration)

That temperature variation is the fly in the ointment. If you can
keep the crystal temp consistent, something like NTP can compensate
for the rest. But then you start flogging the computer...

Much more than three quarters of the crystals manufactured are "X"
cut, which while "easy" to cut also has about the worst temperature
coefficient. There are several other cuts with substantially better
characteristics, but they're harder to cut and thus more expensive.
Somewhat after the transistor was invented, a rather simple way to
improve the frequency stability was to (essentially) glue to crystal
to a small power transistor along with a thermistor and two fixed
resistors. The circuit was such that the transistor heated the crystal
and thermistor, and the fixed resistors were chosen to bring the
crystal to about 45-50C. If the transistor current gain was high
enough, this stabilized the temperatures pretty well, and a relatively
low cost in hardware.

>Well, yes, in the past timekeeping was poorer. In 1600 you

Bill, I'm old, but not THAT old ;-)

>In the 1700 about 1 sec from pendulum clocks and then spring wound
>clocks. By 1900 you were getting down to ms. Again the pendulum and
>spring clocks has to be calibrated against sundials occasionally

Somewhat interesting that the 1934 (US) federal regulations for AM
broadcast stations (540-1600 KHz) required a frequency tolerance of 10
Hz (6.25 - 18.5 ppm) and we had to jump through moderate hoops to be
able to measure that error (double ovened crystal oscillators). The
"VHF" television transmitters had similar requirements, but later "UHF"
channels had tighter specs (1.1 to 2.1 ppm).

I've always found it interesting exploring older technology. The
Harrison Number 4 Timekeeper is a mechanical marvel. The November 1761
voyage to Jamaica showed an error of 9 seconds in the 60 day voyage,
which is 1.74 ppm. Not bad for hardware, especially given the
conditions at sea (ships motion, temperature problems and what-not).

>But now computers are down to microsecond accuracy for cheap crystals,
>and better than PPT (Parts per tera). for the better clocks.

If they're disciplined, yes. But in the 1960s it wasn't that difficult
to get stability. We used to cheat and use VLF radio transmissions as
a timing reference - the LORAN-C chains (100 KHz) in the 1960s were
controlled to parts per billion (10e12) or better (multiple cesium
clocks averaged at each chain master site), and were receivable over
large parts of country. For the most part, 0.1 ppm was almost trivial
to obtain. The other part of the question is "what is the actual
need?". I was working on terminal area aircraft flight tests, and the
aircraft was at 300 KIAS or less, which translates to 500 ft/sec. max.
Even with our spiffed-up laser tracking systems, knowing where the
aircraft was to an accuracy of +/-4 feet (X, Y and Z) was pushing
things - thus 2 msec timing accuracy was sufficient.

Old guy