Client using Meinberg NTP can't sync with ntp server problem

[vothan...@gmail.com]

Hi all,

Currently, I am working with meinberg ntp and I can't sync with ntp server. I have made rules that allow UDP port 123, turned off w32time and change to some popular ntp server but there is no luck.

I have followed this FAQ:
http://www.meinbergglobal.com/english/info/ntp-w32time.htm

I'm using windows web server 2008 R2, Meinberg NTP version is http://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable (the spider man one)

this is the output from ntpq -pn

C:\Windows\system32>ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*218.189.210.3 137.189.4.10 2 u - 512 17 30.634 -46.455 23.503


this is the output from ntpq -crv
C:\Windows\system32>ntpq -crv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2...@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2)",
processor="x86", system="Windows", leap=00, stratum=3, precision=-21,
rootdelay=31.931, rootdisp=109.468, refid=218.189.210.3,
reftime=d767610b.0bd46116 Wed, Jul 9 2014 13:34:51.046,
clock=d7676117.210e61c3 Wed, Jul 9 2014 13:35:03.129, peer=7365, tc=9,
mintc=3, offset=-46.455, frequency=-65.949, sys_jitter=0.000,
clk_jitter=31.032, clk_wander=0.024

And this is my ntp.conf file:
server 0.hk.pool.ntp.org minpoll 9 maxpoll 11 iburst

I am looking forward for your response.

[David Taylor]

Just a few points:

- the presence of the "*" in the output of ntpq -pn indicates sync, so
I'm unsure that the problem is.

- I recommend installing outside the \Program Files\ directory, and I'm
not sure you've done that.

- Using a single server is bad practice. Use the pool directive instead
and don't try and specify the min/max poll:

pool hk.pool.ntp.org iburst

NTP will adjust the polling as it needs to, and will try and get a
number of servers rather than just one. You should use a driftfile line
in your ntp.conf file as well.

driftfile C:\Tools\NTP\etc\ntp.drift

if you have installed to C:\Tools\NTP as I recommend:

http://www.satsignal.eu/ntp/setup.html

You actually seem to have made things more complex for yourself than a
default install might have done, but perhaps that is the result of
experimenting!

(There are some issues installing on Windows Server, of which I have no
current experience).

--
Cheers,
David
Web: http://www.satsignal.eu

[vothan...@gmail.com]

Hi David,

I have reinstalled ntp again and do the same as the guide above and I want to know if I can configure the sync interval to test if the program is working correctly. So I put the minpool parameter with value 9 and wait but there is nothing happend.

Did I miss something here?

[David Taylor]

As I already said, if you have a "*" against one of the server lines in
"ntpq -pn" NTP is basically working correctly. If you are using the
"pool" directive you should be seeing several servers listed, and NTP
will choose the best. I don't know how many servers there are in the
"hk" pool - someone will doubtless tell us how to find that out - but
you may want to include the "asia" (I think it is) pool as well.

Leave the minpoll and maxpoll out of the configuration unless you have
good reason to play with them. At least to start with.

[E-Mail Sent to this address will be added to the BlackLists]

vothan...@gmail.com wrote:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *218.189.210.3 137.189.4.10 2 u - 512 17 30.634 -46.455 23.503

--^ It is synced !

> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,

-----------------------------------^^^^^^^^-----------^^^^^^^^^^
It is synced !



What makes you think it can't sync?
When clearly it is.


--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.

[David Woolley]

On 09/07/14 18:30, E-Mail Sent to this address will be added to the

BlackLists wrote:
> vothan...@gmail.com wrote:
>> remote refid st t when poll reach delay offset jitter
>> ==============================================================================
>> *218.189.210.3 137.189.4.10 2 u - 512 17 30.634 -46.455 23.503
> --^ It is synced !
>
>> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> -----------------------------------^^^^^^^^-----------^^^^^^^^^^
> It is synced !
>
>
>
> What makes you think it can't sync?
> When clearly it is.

+1 (I make that 3 in total).

Also this isn't Meinberg's ntpd, it is the reference ntpd. Only the
installer is from Meinberg.

[vothan...@gmail.com]

Hi all,

After 2 hours it can sync now but I would expect it sync every 15 minutes because my program need precision time.

[William Unruh]

On 2014-07-09, vothan...@gmail.com <vothan...@gmail.com> wrote:
> Hi David,
>
> I have reinstalled ntp again and do the same as the guide above and I want to know if I can configure the sync interval to test if the program is working correctly. So I put the minpool parameter with value 9 and wait but there is nothing happend.

minpoll 9 means that it waits for about 10 min for each poll. Ie,
nothing should happen before about an hour from when you started.

[William Unruh]

You have no idea how ntpd works do you? ntpd gets the time from its
servers. It then adjusts the rate of your clock in order to bring its
time in line with those remote clocks. eventually ( 1-10 hrs) its rate
will be the same as the remote rate, and its time will be the same as
the remote time. Thereafter it will slowly adjust things to stay in
sync.
Your time will be within somewhere between 10 usec and 10ms of UTC once
everything settles down. What does "my program needs precision time"
mean? Within 1 pico second of UTC? wihin 10 sec of UTC?

[David Woolley]

On 10/07/14 03:07, vothan...@gmail.com wrote:
> After 2 hours it can sync now but I would expect it sync every 15
> minutes because my program need precision time.

To speed up initial sync use iburst.

Your non-standard minpoll is contributing to the slow synchronisation.
However note that, in a stable environment, ntpd only requires to update
the clock parameters once every about two hours to maintain close to the
best achievable lock. The poll rate is 8 times this, so that it can
choose the "best" (lowest round trip delay) sample. On the other hand
locking in a high minpoll stops it from recovering quickly if things
become unstable.

As others have noted, precision time means widely differing things to
different people, ranging from the unachievable to cases where ntpd is
overkill. Many people would have a definition of precision time which
is unachievable on Windows, as Windows is not a good system for time
keeping.

[David Taylor]

On 10/07/2014 08:39, David Woolley wrote:
[]

> As others have noted, precision time means widely differing things to
> different people, ranging from the unachievable to cases where ntpd is
> overkill. Many people would have a definition of precision time which
> is unachievable on Windows, as Windows is not a good system for time
> keeping.

.. although Windows can be kept within a millisecond, if that's good
enough for the OP's needs:

http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

[vothan...@gmail.com]

Thanks for your explaination. The reason I use NTP because I want my computer clock have the same time as the server. It is always 1 or 2 minutes behind compare to the ntp server. That's why I need it to sync the display time every 10 minutes.

But as you said "nothing should happen before about an hour from when you started. " means there is nothing I can do to "force" it sync every 10 minutes?

[Jochen Bern]

On 07/10/2014 10:24 AM, vothan...@gmail.com wrote:
> Thanks for your explaination. The reason I use NTP because I want my
> computer clock have the same time as the server. It is always 1 or 2
> minutes behind compare to the ntp server.

I admit that it *is* odd that ntpd doesn't change that *eventually* ...

> But as you said "nothing should happen before about an hour from when
> you started. " means there is nothing I can do to "force" it sync
> every 10 minutes?

Except for some (hopefully rare) extreme circumstances, ntpd *does not*
"sync" (= just copy the server's current time to the client, usually
called "stepping") the local clock. If that's truly what you want to do
(and while still using an NTP server), you need to look at SNTP / ntpdate.

Imagine having a wrist watch that, when set to the correct time in the
morning, has drifted so much in the evening to make you miss your train
home. One solution is to adjust the time a couple times during the day
as well, and another is to take it to the horologist to have it repaired
so that it doesn't drift (so much) anymore in the first place.

What ntpd primarily tries to do is the *latter*, and since wildly
*setting* the clock interferes with proper measurements of its drift,
fixing "the time" of the clock (by "slews" instead of "steps") has a
somewhat lower priority.

Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

[Martin Burnicki]

As already mentioned by others the time seems basically synchronized.

However, please see an earlier post from me
http://lists.ntp.org/pipermail/questions/2013-November/036676.html

which describes why (and how) you should upgrade the NTP version, and
why (and how) you should use different minpoll/maxpoll values.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

[Brian Inglis]

You can start ntpd with -g option which allows it to step your system time once,
when it first starts; using iburst "pool hk.ntp.pool.org iburst" will allow the
correct offset to be set within about 16s after startup. Thereafter it will stay
within +/-128ms of UTC; after it has settled, that should be about +/-10ms off UTC.
As another poster said, adding "pool asia.ntp.pool.org iburst" may improve your
offset.
Once it gets to long poll intervals, it actually improves the drift compensation
more, and reduces the offset further.
--
Take care. Thanks, Brian Inglis

[Martin Burnicki]

Brian Inglis wrote:
> You can start ntpd with -g option which allows it to step your system
> time once,
> when it first starts; using iburst "pool hk.ntp.pool.org iburst" will
> allow the
> correct offset to be set within about 16s after startup. Thereafter it
> will stay
> within +/-128ms of UTC; after it has settled, that should be about
> +/-10ms off UTC.
> As another poster said, adding "pool asia.ntp.pool.org iburst" may
> improve your
> offset.
> Once it gets to long poll intervals, it actually improves the drift
> compensation
> more, and reduces the offset further.

That's the theory how it should work, and how it does work on
non-Windows systems.

In practice ntpd v4.2.6p5 may settle or not at all under Windows Vista
and newer due to Windows bug where Windows doesn't accept small tick
adjustments. See my the link in my other post.

Also, *under Windows* the offset usually *increases* if you let the
polling interval ramp up. See
http://people.ntp.org/burnicki/windows/ntpd-4.2.7-Win7-poll4-max.pdf

where the polling interval is allowed to be ramped up, versus
http://people.ntp.org/burnicki/windows/ntpd-4.2.7-Win7-poll4-6.pdf

where the polling interval is limited to 6.

[William Unruh]

STOP USING GOOGLE GROUPS. It totally messes up the responses sticking in
millions of blank lines. It makes your message unreadable. Get a decent
news host.


Again you forgot to read my explanation of how ntp works. Until you do
so, you will remain confused ( you might remain confused even after you
read it of course). ntpd does not "sync the clocks" as you think it
should. It does not work like that. It will eventually sync the clocks
and they will stay synced to second accuracy even if the connection
breaks for days. But it takes a while to do so.

No you cannot "force it to sync every 10 min" that is not how it works.
Learn how it works, and you will be happy. Think you know how it works
and you will be disappointed.

[David Woolley]

On 10/07/14 09:24, vothan...@gmail.com wrote:
> It is always 1 or 2 minutes behind compare to the ntp server.

Please explain. You appear to be describing a seriously broken machine.
ntpd is not a cure for broken machines.

[David Woolley]

On 10/07/14 09:23, David Taylor wrote:
> although Windows can be kept within a millisecond,

But the uncertainty in the delay between real world events and
application programs reading the corresponding time is likely to be
rather larger.

(Also, at least the past, ntpd only compensated well for Windows on
lightly loaded systems.)

[Brian Inglis]

Never had a problem keeping within a few ms offset from UTC with
only good network sources, Windows 7 x64, and NTP 4.2.6p5 stable.
With the same platform plus a Garmin 18x LVC, stays within
+/-60us offset, average +/-0.5us, s.d. < 15us;
jitter < 50us, average < 20us, s.d. < 5us.

I just noticed my network sources have been unreachable
for more than 36h - may have to restart - and hope my
ISP or their links have not started blocking NTP port 123!

[vothan...@gmail.com]

Hi all,

I read and followed as the link Martin suggest and I tried to find the latest version. Can you check for me if this link is the latest because I tried this link but it is not working. I tried set minpool to 9 but it doesn't work.
Here is the link: http://www.satsignal.eu/ntp/x86/ntp-4.2.7p447-win-x86-bin-djt.zip

In my case (as William explained) it is not a normal clock rate sync but just a copy time from ntp server to machine clock. So what I am wondering now is if it is right in my situation to use ntp to "sync" from ntp server.

The machine I am trying to "sync" is a VPS machine.
I still don't get the point William explained that "you cannot "force it to sync every 10 min" that is not how it works". Can you explain me more?

[Rob]

You should not touch those config options until you understand how
they work.

First get it working using a default configuration file.

[David Taylor]

On 10/07/2014 23:51, David Woolley wrote:
> On 10/07/14 09:23, David Taylor wrote:
>> although Windows can be kept within a millisecond,
>
> But the uncertainty in the delay between real world events and
> application programs reading the corresponding time is likely to be
> rather larger.

Unless the interrupt path has a low latency, yes, but this is true of
any operating system. Choose OS according the the application needs, as
always. As the OP was talking minutes offset, there are other problems
to be solved first! I wonder whether a time-zone setting is incorrect?

> (Also, at least the past, ntpd only compensated well for Windows on
> lightly loaded systems.)

You can see how well or otherwise NTP works on my Windows systems here:

http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

I keep systems lightly loaded as far as possible. Perhaps PC Feenix is
the most heavily loaded of the systems there. Caveat, these are synced
to several local stratum-1 servers with a poll interval of 32 seconds,
as I wanted good timekeeping performance.

[David Taylor]

On 11/07/2014 07:51, vothan...@gmail.com wrote:
[]

> The machine I am trying to "sync" is a VPS machine.

VPS is what? A virtual PC?

[David Woolley]

On 11/07/14 07:51, vothan...@gmail.com wrote:
> I tried set minpool to 9

That's part of your problem, not the soluction. Leave it at 6.

[David Woolley]

On 11/07/14 07:51, vothan...@gmail.com wrote:

> In my case (as William explained) it is not a normal clock rate sync
> but just a copy time from ntp server to machine clock. So what I am
> wondering now is if it is right in my situation to use ntp to "sync"
> from ntp server.

w32time is good enough for such crude use of NTP.

> The machine I am trying to "sync" is a VPS machine.

However neither of them are likely to be appropriate for whatever your
underlying problem is; you need to fix that problem before you start
trying to synchronise the time.

As someone else said, is this a virtual machine? If so you may be fighitng:

1) virtualisation of the timing hardware;

2) automatic synchronisation of the time to the host machine time.

Usually the correct method for a VM is to get good synchronisation on
the host and then use the VM environment's time keeping support to lock
the guest to the host.

[Martin Burnicki]

vothan...@gmail.com wrote:
> Hi all,
>
> I read and followed as the link Martin suggest and I tried to find the latest version. Can you check for me if this link is the latest because I tried this link but it is not working. I tried set minpool to 9 but it doesn't work.

In the message to which I've provided a link I tried to explain that
(and why) polling intervals below 6 and above 7 may not yield proper
results. So why don't you try this?

Instead

server 0.hk.pool.ntp.org minpoll 9 maxpoll 11 iburst

Please try

server 0.hk.pool.ntp.org iburst minpoll 6 maxpoll 7

> Here is the link: http://www.satsignal.eu/ntp/x86/ntp-4.2.7p447-win-x86-bin-djt.zip

Strange. This download link works fine for me. Can you access
http://www.satsignal.eu/ntp/x86/

That's the web page which provides that link.

> In my case (as William explained) it is not a normal clock rate sync but just a copy time from ntp server to machine clock.

What do you mean by: "not a normal clock rate sync but just a copy time"

> So what I am wondering now is if it is right in my situation to use ntp to "sync" from ntp server.
>
> The machine I am trying to "sync" is a VPS machine.

Do you mean your Windows system runs inside a Virtual Machine (VM)?

Even in physical machines is usually pretty tricky to synchronize the
Windows system time accurately. In VMs it's even harder since the
virtualization usually also causes more or less additional jitter,
depending on how much effort the vendor of the virtualization software
has spent for timekeeping inside the VMs.

So the resulting accuracy you can yield with NTP in a VM may be better
or worse, depending on which virtualization software you are using
(VMWare? MS Hyper V?), but is usually always worse than with the same OS
running directly on a physical machine.

If this is sufficient, or not, depends on the accuracy you need or expect.

> I still don't get the point William explained that "you cannot "force it to sync every 10 min" that is not how it works". Can you explain me more?

Real NTP (ntpd) gets the time from a server in periodic polling
intervals. The results from several pollings are filtered, and the
filter output is used to slew the system time slowly and continuously so
that there are no time steps in the system time and the system time
doesn't drift away from "real" time.

Usually the polling interval is adjusted automatically by ntpd in the
range 2^6 (=64) to 2^10 (=1024) seconds. However, under Windows polling
intervals above 2^7 don't yield good results, so you should limit
maxpoll to 6 or 7.

Forcing it to synchronize every 10 minutes might mean you run a tool
every 10 minutes to get the current time and then set the Windows system
time, which yields much worse results than you can achieve with NTP.

[Martin Burnicki]

Brian Inglis wrote:
> Never had a problem keeping within a few ms offset from UTC with
> only good network sources, Windows 7 x64, and NTP 4.2.6p5 stable.

As far as I have seen this may depend. On some systems it works, on
others it doesn't which means the time synchronization doesn't settle.

I've seen systems where the residual offset and jitter reported by "ntpq
-p" was continuously more than 1000 ms, and except for very rare cases
where a problem with the mainboard or some other driver could be
identified to cause these problems the resulting time accuracy could be
increased to a few milliseconds or so after a developer version with the
16 tick workaround had been installed, and the polling interval has been
limited.

I'm not sure if the reason whether it works or not is whether the
undisciplined system time runs fast or slow, in which case the time
adjustment relative to the standard adjustment has to be decreased or
increase.

This could cause different computations in ntpd's algorithms which
compute the adjustment as well as in the Windows kernel which evaluates
the adjustments.

> With the same platform plus a Garmin 18x LVC, stays within
> +/-60us offset, average +/-0.5us, s.d. < 15us;
> jitter < 50us, average < 20us, s.d. < 5us.

Haven't tried similar hardware refclock and eventually PPS under Windows
myself, but I'd expect this works much better since AFAIK refclocks are
in general polled in shorter intervals, at least in newer versions of ntpd.

[David Woolley]

On 11/07/14 09:46, Martin Burnicki wrote:
> not a normal clock rate sync but just a copy time

He means ntpdate in step mode. He clearly has something badly broken
and is trying to use ntpd as sticking plaster, rather than fixing the
problem.

[Jochen Bern]

On -10.01.-28163 20:59, vothan...@gmail.com wrote:
> In my case (as William explained) it is

(translation: what I *want* to do is)

> not a normal clock rate sync

(translation: not rate adjustments and (then) slewing to get rid of the
offset, as ntpd tries to do)

> but just a copy time from ntp server to machine clock.

(translation: stepping the offset away, NOW, like SNTP/ntpdate do)

> So what I am wondering now is if it is right in my situation to use
> ntp to "sync" from ntp server.
> The machine I am trying to "sync" is a VPS machine.

I shall assume that you're referring to this:
https://en.wikipedia.org/wiki/Virtual_private_server
which would mean that not only it is a VM, but also that the host's
timing is completely out of your control (which might well mean
"continuously interfering with your attempts").

> I still don't get the point William explained that "you cannot "force
> it to sync every 10 min" that is not how it works". Can you explain
> me more?

You: "My watch is five minutes late every time I look. I shall set it to
the proper time every ten minutes."

ntpd: "This watch has been free-running for an hour, and is suddenly ten
minutes late. I will adjust it to run 20% faster, measure again, and
once the watch is 'repaired' and doesn't keep *losing* proper time
immediately after being set, I'll care about the cumulated offset."

What might very well be the case: "The time I see on the VM is actually
the *host's* time, which I cannot influence with any tools within my VM.
The host is five minutes late because the ISP doesn't care, so I'm ***ed."

[Brian Inglis]

On 2014-07-11 00:51, vothan...@gmail.com wrote:
> Hi all,
>
> I read and followed as the link Martin suggest and I tried to
> find the latest version. Can you check for me if this link is
> the latest because I tried this link but it is not working.
> I tried set minpool to 9 but it doesn't work.

minpoll
pool hk.pool.ntp.org iburst minpoll 6 maxpoll 6
pool tw.pool.ntp.org iburst minpoll 6 maxpoll 6

> Here is the link: http://www.satsignal.eu/ntp/x86/ntp-4.2.7p447-win-x86-bin-djt.zip
>
> In my case (as William explained) it is not a normal clock rate
> sync but just a copy time from ntp server to machine clock.
> So what I am wondering now is if it is right in my situation to
>use ntp to "sync" from ntp server.
>
> The machine I am trying to "sync" is a VPS machine.

Search for "ntp under Xen OR KVM" or substitute your platform.
You have to find out what your platform is, whether your
provider syncs the domain and host time with NTP, what service
level and timing facilities are provided.

If the domain and host time is not synced with NTP, as is
common in Windows domains, you probably have no chance, as
the platform time may appear to jump and/or drift any old
way, and NTP requires a stable hardware base to work from.

> I still don't get the point William explained that "you cannot
> "force it to sync every 10 min" that is not how it works".
> Can you explain me more?

NTPd when started with -g steps your system within 128ms of UTC
then disciplines the rate at which the system sees time passing
to get the offset closer to UTC.
It decides how often it needs to request information and make
corrections depending on how it sees your platform behaving.

How close you get to UTC depends on the stability of your OS,
hardware, and time sources, so may be ms with network sources
or Windows, us with hardware reference clocks (e.g. GPS with PPS),
or ns with BSD on embedded systems (e.g. Soekris) with time nut
level hardware (e.g. Trimble Thunderbolt) and external antennas
(e.g. survey quality) with a good view of the sky (no trees or
buildings nearby and above the level of the antenna). YMMV

[William Unruh]

ntpd operates, as I said, in a certain way. It sends out a request for
time at the poll intervals. It then looks at the last 8 times and if the
current round trip time is greater than any in the last 8 times, the
current one is not used and the next poll is waited for. Thus, the used
measurements vary between poll interval and 8 times poll interval time
between them.
Then that measurement is compared with the local clock. If it shows that
the local clock is slow, the local clocks tick rate is increased by a
small amount-- proportional to that offset and inversely proportional to
the poll interval, but much less than would be required to fix the
offset within even 8 poll intervals. And the process continues.
Eventually, the local clock's rate is increased enough that the offset
starts to decrease and finally the time offset is also decreased.
Ie, the local clock is NOT reset, is not synced except over a long time.
Its rate is gradually changed. After the local rate equals the distant
rate, and the local offset is small, the local clock tracks slow drifts
either in its own rate or the remote rate.
ntp does terribly if the local, or remote rate change suddenly. It takes
a long time (about 8 poll intervals) to even notice, and then much
longer to bring the rates into line again. Mills designed the system
with stability, not speed of response, in mind.
Whether this kind of feedback system is the best use of the measurements
made has been a long topic of discussion (extending back into the first
design of ntpd). chrony, another program which uses the ntp packet
exchange protocol for time discipline, and interoperates on the packet
level with ntpd, uses a different philosophy, and is much faster at
responding to changes, and has been found to discipline the clock much
more accurately (3-20 better in offset jitter in a variety of tests).
Whether it has drawbacks to compensate is a topic ripe for testing.
However for you its biggest drawback is that it does not run under
Windows or MacOS (although the latter should not be a difficult port
since macOS is based on BSD/Unix. )


>
> NTPd whe started with -g steps your system within 128ms of UTC

> then disciplines the rate at which the system sees time passing
> to get the offset closer to UTC.
> It decides how often it needs to request information and make
> corrections depending on how it sees your platform behaving.
>
> How close you get to UTC depends on the stability of your OS,
> hardware, and time sources, so may be ms with network sources
> or Windows, us with hardware reference clocks (e.g. GPS with PPS),
> or ns with BSD on embedded systems (e.g. Soekris) with time nut
> level hardware (e.g. Trimble Thunderbolt) and external antennas
> (e.g. survey quality) with a good view of the sky (no trees or
> buildings nearby and above the level of the antenna). YMMV

Well, no, with just a bog standard level gps (eg the $35 Sure out a
window with trees in the way) and standard serial port interupt,
I get a few usec level jitter, and using it as a network source for
other machines, I get 10s of usec errors (measured with separate gps pps
attached as the standard) over the local network. Even over an ADSL line
from home, I was getting better than 100 usec on the home machine.
So, yes, YMMV.

>