Need Time Help
Hi Larry,
You are using a bunch of h/w and s/w together and you want each piece to maintain precise time.
Would it be possible for you to inject a very short GPS 1PPS pulse or GHz tone into your antenna feed?
That will cause a slight blip in your raw data which your processing s/w can then use to self-calibrate the absolute time of all samples as often as once a second. This allows your PC and OS to be data processors (which they are good at) and not precision timekeepers (which they are not good at). It also solves the latency issues with your SDR h/w and s/w.
I've done something similar with PC sound cards. Instead of having the OS pretend it's a timekeeper you just put a 1PPS into the R channel and your data stream into the L channel. It's trivial to then correlate the two and nail down the absolute time of the samples at the microsecond level. The beauty is that it completely avoids the problems of PC timekeeping. It works with any laptop and any operating system at any temperature and it also solves the accuracy and latency problems that even NTP on Linux doesn't solve.
/tvb
----- Original Message -----
From: "Larry Hower" hower@hower.net
To: time-nuts@febo.com
Sent: Monday, October 03, 2016 9:41 PM
Subject: [time-nuts] Need Time Help
Hello to the List:
After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.
We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.
Specifically, we want to use a universal reference that will enable amateur
radio operators in different parts of the world to start and stop their
transmissions within a few milliseconds of a specific time. For example, I
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
We are using WSJT-X software. We use standard receivers plus we have tried
a few SDRs.
Sorry for the oversimplified example but I want to make sure we are all on
the same page.
As background:
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
We have set up some Serial GPS units with PPS and some USB GPS receivers
(no PPS) and can get to about 0.2 sec but it is not trusted or close enough. -
We have set up a network time server with similar results.
-
Deviation is measured using WSJT-X
Standard Receivers
ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
SDRs
We believe that SDR processing can insert a delay of varying length,
depending on the software, bandwidth, etc. Our SDR tests seem to have a
delay of as much as 0.5 sec. And with sometimes variable results. We will
see how SDRs can be used after we resolve the current issues.
Some time related hardware details
1. Global Star 4 USB and Serial Connections
http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
We have 4 of these. Two are older models with serial connections. We have
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer
models with USB connections which are not able to use the PPS option.
We have tried NEMATime and NEMATime 2 software on this hardware without
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
sec. Drifts. Deviation is measured using WSJT-X.
2. TimeNet NTP Device
http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx
We have one of these TimNet units and it has been set up at 2 different
locations on differing computers according to user instructions. We are
using the TimNet software as DL'd recently from their web site. We get GPS
“lock” and Time “lock” shown in the user panel but we do not have faith
that this is carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is
strted again (the updated is operation is show at the correct time. We
think the app needs some work. Deviation is measured using WSJT-X. See
later details.
Setup
The G Star units have been installed at 2 separate locations, tested using
WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
Similar tests with a TimeNet unit at one end and G Stars at the other end.
G Star units were installed on the XP laptops with the PPS option enabled
and running WSJT-X. These XP units seem to have their time “in sync”. See
following.
WSJT-X
We are not sure what, if any, internal delays there are attributable to
this software. We have been using the same version/build at both ends for
the tests. The software displays in 0.1 sec increments but will show 0.0sec
when things appear to be working well. We do not know the actual level of
precision of the WSJT-X software time measurements. I undersand that WSJT-X
“reads” the system clock at the start of a period (TX or RX) and displays
what it finds as the time deviation from the local system clock.
WIN XP
There are 2 laptops running XP. They seem to match each other re time using
WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
sure that they are working properly but they need to be more accurate
(<15ms).
WIN 10
Installed on a number of desktop and laptop computers. Many efforts were
made to make these system clocks reference the GPS devices.
We became aware that the WIN Time/Date GUI was not always driving the
setting down into the system clock. We became aware also that the Registry
entries needed to be confirmed as far as NTP or local reference and the
sync cycle needed definition because of the same unreliable GUI actions.
We found that we needed to start the Time Services and deal with some other
factors. We have found that in WIN 10 the time/date clock does not show
the update when it happens automatically according to the setting in the
directly. It does how the correct time of sync when we do it manually or
restart the GUI.
The end result is that we don't trust WIN 10 and and we are not sure how to
fix the problem. Linux not allowed for now.
Status
Our conclusion is that the external gear should be able to provide a more
accurate reference than we are able to obtain presently. We think "it is
in there somewhere" but we can't get it out.
We have a feeling that the WIN system clocks are not being updated
correctly or at least in a repeatable manner. We don't know if the problem
is hardwaare or software or our setup / configurations.
I ask for advice on how we can use the above gear or other gear or other
software to have our setup deliver better than 15ms accuracy.
Ultimately we want sub-millisecond accuracy.
Any help will be very much appreciated. Thanks in advance for anything you
can advise.
73,
Larry Hower
VK7WLH
W0LH
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I think to sum up what has been written
- USB connection will not work well for timing
- Notebook computers dont work well for timing
- A good NTP server on your LAN can get you "close" to what you need even
on PC notebooks - With effort and a real serial port and after downloading a copy of NTP
and configuring it even Windows desktop system can do better than 1 milli
second. But if your typical user is not really knowable about PCs he will
have trouble with this - Any Linux system, even the tiny Pi. can perform very well (orders of
magnitude better than your requirement) and serve a large number of
computers on a LAN.
I think if you are stuck with running Windows on a notebook that lacks
serial ports the best way to get timing information into that machine is
via the Ethernet port (not WiFi, wired Ethernet) But;d a local NTP server.
(cost under $100 including GPS and antenna)
If you have a desktop Windows PC with a real serial port (not USB) and a
user who can install software and edit text baed configuration files and
make cables then you can connect a GPS directly to the computer and it will
work as well as you need
On Tue, Oct 4, 2016 at 1:51 AM, Pete Stephenson pete@heypete.com wrote:
On 10/4/2016 6:41 AM, Larry Hower wrote:
Hello to the List:
Hi and welcome!
After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.
You have a much higher budget for amateur radio gear than I do if you're
doing EME. I'm envious. :)
We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.
This should be quite feasible, even with Windows.
That said, is such precision really necessary? I know that JT65 and JT9
both require "good" time sync, but is millisecond-level precision
needed? I've had good results for terrestrial contacts with time
differences ranging from 0.0 to 1.0 seconds. EME might require tighter
sync, of course.
Specifically, we want to use a universal reference that will enable
amateur
radio operators in different parts of the world to start and stop their
transmissions within a few milliseconds of a specific time. For example,
I
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
GPS should be that "universal" (really, planetary) reference.
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal.
No surprise. The built in Microsoft timekeeping software is "good
enough" for typical computing purposes (within a second or two) but
isn't really sufficient for your purposes.
Desktops will be easy, assuming they have a serial port or a serial
header on the computer itself. If the desktop only has a serial header,
a cheap adapter like
<https://www.amazon.com/StarTech-com-Serial-Motherboard-Header-PLATE9M16/
dp/B001Y1F0HW/>
will connect the header to a standard serial connector.
Laptops might be harder. Using NTP software to a good NTP server on the
internet should get you within a few milliseconds. Synced to a good NTP
server on the LAN with the server using GPS+PPS should get you within a
millisecond.
- We have set up some Serial GPS units with PPS and some USB GPS
receivers
(no PPS) and can get to about 0.2 sec but it is not trusted or close
enough.
-
We have set up a network time server with similar results.
-
Deviation is measured using WSJT-X
We believe that SDR processing can insert a delay of varying length,
depending on the software, bandwidth, etc. Our SDR tests seem to have a
delay of as much as 0.5 sec. And with sometimes variable results. We will
see how SDRs can be used after we resolve the current issues.
This isn't really surprising. If the SDRs are connected via USB, there's
additional delays and jitter inherent in that connection.
Some time related hardware details
1. Global Star 4 USB and Serial Connections
http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
We have 4 of these. Two are older models with serial connections. We have
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer
models with USB connections which are not able to use the PPS option.
We have tried NEMATime and NEMATime 2 software on this hardware without
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
sec. Drifts. Deviation is measured using WSJT-X.
The BU-353-S4 lacks a PPS line to precisely signal the start of each
second. (At least the specific one I have for mapping doesn't have that
option.) Although you may get somewhat better precision using the SiRF
binary stream, your deviation is about what I'd expect for a USB
receiver with NMEA output.
Simply put, without PPS you probably won't get closer than 250ms unless
you're quite lucky. Doubly so if you're using PPS-over-USB.
2. TimeNet NTP Device
http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx
We have one of these TimNet units and it has been set up at 2 different
locations on differing computers according to user instructions. We are
using the TimNet software as DL'd recently from their web site. We get
GPS
“lock” and Time “lock” shown in the user panel but we do not have faith
that this is carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is
strted again (the updated is operation is show at the correct time. We
think the app needs some work. Deviation is measured using WSJT-X. See
later details.
I wonder if you'll get better results using Meinberg's Windows port of
NTPd: https://www.meinbergglobal.com/english/sw/ntp.htm -- you should
be able to configure it to query your TimNet device and get reasonably
good precision.
Meinberg's NTP software is explicitly recommended in the WSJT-X
documentation.
WSJT-X
We are not sure what, if any, internal delays there are attributable to
this software. We have been using the same version/build at both ends for
the tests. The software displays in 0.1 sec increments but will show
0.0sec
when things appear to be working well. We do not know the actual level of
precision of the WSJT-X software time measurements. I undersand that
WSJT-X
“reads” the system clock at the start of a period (TX or RX) and displays
what it finds as the time deviation from the local system clock.
According to the manual at
<http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/
wsjtx-main-1.6.0.html#TUT_EX2>,
the DT column shows the offset between the time of the remote station
and your local system clock, not between your local system clock and UTC.
I'm not sure if the time difference displayed compensates for speed of
light delays.
I suspect the software is able to compensate for internal delays, else
it wouldn't be much use.
WIN XP
There are 2 laptops running XP. They seem to match each other re time
using
WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
sure that they are working properly but they need to be more accurate
(<15ms).
I assume your "out" time is in seconds, not milliseconds.
WIN 10
Installed on a number of desktop and laptop computers. Many efforts were
made to make these system clocks reference the GPS devices.
We became aware that the WIN Time/Date GUI was not always driving the
setting down into the system clock. We became aware also that the
Registry
entries needed to be confirmed as far as NTP or local reference and the
sync cycle needed definition because of the same unreliable GUI actions.
We found that we needed to start the Time Services and deal with some
other
factors. We have found that in WIN 10 the time/date clock does not show
the update when it happens automatically according to the setting in the
directly. It does how the correct time of sync when we do it manually or
restart the GUI.
The end result is that we don't trust WIN 10 and and we are not sure how
to
fix the problem. Linux not allowed for now.
Status
Our conclusion is that the external gear should be able to provide a more
accurate reference than we are able to obtain presently. We think "it is
in there somewhere" but we can't get it out.
We have a feeling that the WIN system clocks are not being updated
correctly or at least in a repeatable manner. We don't know if the
problem
is hardwaare or software or our setup / configurations.
Try Meinberg's NTP software and GPS receivers with PPS outputs.
I've had good luck with the Garmin GPS 18x LVC
<https://buy.garmin.com/en-US/US/oem/sensors-and-boards/gps-
18x-oem/prod27594.html>.
It's available for ~$70 USD from Amazon at
https://www.amazon.com/Garmin-18x-LVC-Navigator-Unit/dp/B0016O3T7A/ --
it comes with a bare wire connector and you'd need to solder the
appropriate connector for 5V power and serial connections.
Note: you need the LVC model, as this has PPS output. The USB and "PC"
(standard serial) do not do PPS output.
I added some extra bits to blink an LED with each PPS, and an LED for
power. The USB pigtail provides power while the serial connection goes
directly into a hardware serial port. Here's a pictures of my connector:
http://imgur.com/a/PEiBU
There's lots of other great GPS receivers with PPS output, including old
timing receivers like the Motorola Oncore, Trimble Resolution T, etc.
Those PPS outputs are typically within 20-100 nanoseconds. Oncore UT+'s
are about $20 on eBay --
<http://www.ebay.com/itm/Motorola-UT-Plus-Oncore-Timing-GPS-1PPS-50-ns-/
270467197172>,
while the Resolution T is about $50
<http://www.ebay.com/itm/Trimble-Resolution-T-Timing-
GPS-module-12ns-1pps-/252474351979>.
The only downside of the Resolution T is the pinout does not use the
common 2.54mm/0.1" spacing, but instead uses 2mm spacing.
I've had excellent luck with my GPS 18x LVC feeding my Windows 7 PC
running ToyNTP via a hardware serial port:
http://www.dxatlas.com/ToyNtp/. It steers the system clock using a
Kalman filter and is remarkably good. I typically see offsets <10
microseconds. The only caveat is that ToyNTP requires NMEA output at
4800bps. Other speeds and other formats won't work; keep this in mind if
you use older GPS receivers that might not output NMEA.
Cheers!
-Pete
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
The problem, I think with your Internet sync's NTP servers is you are only
using one server S. The most common practice is to use 3 to 5 with 5 being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
NTP solved the problem that stumped a few people back in the 1970's of how
to sync two clocks when there is a long delay and not constant in there
communications path. (Of course the problem is simple if the delay is
known and well measured) But the solution required the the average path
delay is the same going in each direction. worse no software can't know
there is an asymmetric delay. Well not unless it is using a few servers.
NTP basically finds then ignores the "problem servers".
PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP. This
hardware is rare unless the user provides it. So PTP can't really work on
the public Internet.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali attila@kinali.ch wrote:
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi
If:
- You are a typical Ham in a home environment
- All the servers are “out there” on the internet
- You have any of the normal modems feeding your home
You have a very basic issue in terms of path delay. All the servers you can access
have the same asymmetric delay. In that case, no matter how many servers you
add to the ensemble, the situation never gets better. You are always stuck with the
(likely unknown) uplink / downlink delay difference of your modem. Exactly what
that number is depends a lot on the modern and the system feeding the modem.
It is very possible to see static delay asymmetry well beyond the 5 ms that the OP is after.
On most systems there is also a dynamic asymmetry that is related to loading. That
just makes things harder to work out …..
Bob
On Oct 4, 2016, at 9:05 PM, Chris Albertson albertson.chris@gmail.com wrote:
The problem, I think with your Internet sync's NTP servers is you are only
using one server S. The most common practice is to use 3 to 5 with 5 being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
NTP solved the problem that stumped a few people back in the 1970's of how
to sync two clocks when there is a long delay and not constant in there
communications path. (Of course the problem is simple if the delay is
known and well measured) But the solution required the the average path
delay is the same going in each direction. worse no software can't know
there is an asymmetric delay. Well not unless it is using a few servers.
NTP basically finds then ignores the "problem servers".
PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP. This
hardware is rare unless the user provides it. So PTP can't really work on
the public Internet.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali attila@kinali.ch wrote:
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Tue, Oct 4, 2016 at 9:05 PM, Chris Albertson albertson.chris@gmail.com
wrote:
The problem, I think with your Internet sync's NTP servers is you are only
using one server S. The most common practice is to use 3 to 5 with 5 being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
NTPD cannot find asymmetric delays. The NTP protocol assumption continues
to be symmetric delays with random delay spikes that can discarded.
However despite that the resultant jitter and offset from asymmetry should
be on the order of milliseconds (O(1ms)). As the OP has seen not using PPS
swamps all other errors -- NMEA (et.al.) errors are O(100ms) unless you
have a well designed unit e.g. a JL Fury.
On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
If:
- You are a typical Ham in a home environment
- All the servers are “out there” on the internet
- You have any of the normal modems feeding your home
You have a very basic issue in terms of path delay. All the servers you
can access
have the same asymmetric delay. In that case, no matter how many servers
you
add to the ensemble, the situation never gets better. You are always stuck
with the
(likely unknown) uplink / downlink delay difference of your modem. Exactly
what
that number is depends a lot on the modern and the system feeding the
modem.
It is very possible to see static delay asymmetry well beyond the 5 ms
that the OP is after.
On most systems there is also a dynamic asymmetry that is related to
loading. That
just makes things harder to work out …..
But this is easy to measure, you buy a GPS receiver and use that as an 8th
or 6th reference clock along with the 5 or 7 Internet servers then you look
at the difference between GPS and the Internet servers. The Internet
servers do much better than you'd think. Not as good as GPS but really
good. Why?
Because NTP normally never actually sets you clock to match a server's
clock. It adjusts the RATE of your clock so the it cruises on the middle
of the pack of vetted servers. It adjusts your clock over a long period to
it has the benefit of averaging out lots of random behavior. The result
is that you can keep within a few milliseconds of the GPS even with tens of
millisecond of delay in the communication path.
For people new to NTP, the algorithm has it's hands the system clocks
"fast/Slow? lever and never normally moves the clocks hands directly
And all those Internet servers do NOT have the same asymmetric delay. Well
they might but that would be a pathological case. Typically delays really
are more symmetric than not (one way trip really is 1/2 the round trip)
The clocks that don't meet this assumption are found and removed from the
pool. It works because the dells are NOT the same but random Ans like I
said, it is easy enough to measure. You can see that peer offsets are all
over the map
Also your modem is likely not causing an asymmetric delay. That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router. The modern likely has the same time of flight in both
directions. The delay is cause by a queue some place of packets that are
aggregated from many users. These are random but sort of predictable. A
packet going across a continent or will see more of this then going to a
nearby server
Bob
On Oct 4, 2016, at 9:05 PM, Chris Albertson albertson.chris@gmail.com
wrote:
The problem, I think with your Internet sync's NTP servers is you are
only
using one server S. The most common practice is to use 3 to 5 with 5
being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
NTP solved the problem that stumped a few people back in the 1970's of
how
to sync two clocks when there is a long delay and not constant in there
communications path. (Of course the problem is simple if the delay is
known and well measured) But the solution required the the average path
delay is the same going in each direction. worse no software can't know
there is an asymmetric delay. Well not unless it is using a few servers.
NTP basically finds then ignores the "problem servers".
PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP. This
hardware is rare unless the user provides it. So PTP can't really work
on
the public Internet.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali attila@kinali.ch wrote:
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi
If you buy a GPS receiver and get it set up for timing …. just use it. Then there is no
need for NTP at all….
Bob
On Oct 5, 2016, at 12:33 AM, Chris Albertson albertson.chris@gmail.com wrote:
On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
If:
- You are a typical Ham in a home environment
- All the servers are “out there” on the internet
- You have any of the normal modems feeding your home
You have a very basic issue in terms of path delay. All the servers you
can access
have the same asymmetric delay. In that case, no matter how many servers
you
add to the ensemble, the situation never gets better. You are always stuck
with the
(likely unknown) uplink / downlink delay difference of your modem. Exactly
what
that number is depends a lot on the modern and the system feeding the
modem.
It is very possible to see static delay asymmetry well beyond the 5 ms
that the OP is after.
On most systems there is also a dynamic asymmetry that is related to
loading. That
just makes things harder to work out …..
But this is easy to measure, you buy a GPS receiver and use that as an 8th
or 6th reference clock along with the 5 or 7 Internet servers then you look
at the difference between GPS and the Internet servers. The Internet
servers do much better than you'd think. Not as good as GPS but really
good. Why?
Because NTP normally never actually sets you clock to match a server's
clock. It adjusts the RATE of your clock so the it cruises on the middle
of the pack of vetted servers. It adjusts your clock over a long period to
it has the benefit of averaging out lots of random behavior. The result
is that you can keep within a few milliseconds of the GPS even with tens of
millisecond of delay in the communication path.
For people new to NTP, the algorithm has it's hands the system clocks
"fast/Slow? lever and never normally moves the clocks hands directly
And all those Internet servers do NOT have the same asymmetric delay. Well
they might but that would be a pathological case. Typically delays really
are more symmetric than not (one way trip really is 1/2 the round trip)
The clocks that don't meet this assumption are found and removed from the
pool. It works because the dells are NOT the same but random Ans like I
said, it is easy enough to measure. You can see that peer offsets are all
over the map
Also your modem is likely not causing an asymmetric delay. That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router. The modern likely has the same time of flight in both
directions. The delay is cause by a queue some place of packets that are
aggregated from many users. These are random but sort of predictable. A
packet going across a continent or will see more of this then going to a
nearby server
Bob
On Oct 4, 2016, at 9:05 PM, Chris Albertson albertson.chris@gmail.com
wrote:
The problem, I think with your Internet sync's NTP servers is you are
only
using one server S. The most common practice is to use 3 to 5 with 5
being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
NTP solved the problem that stumped a few people back in the 1970's of
how
to sync two clocks when there is a long delay and not constant in there
communications path. (Of course the problem is simple if the delay is
known and well measured) But the solution required the the average path
delay is the same going in each direction. worse no software can't know
there is an asymmetric delay. Well not unless it is using a few servers.
NTP basically finds then ignores the "problem servers".
PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP. This
hardware is rare unless the user provides it. So PTP can't really work
on
the public Internet.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali attila@kinali.ch wrote:
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Tue, 4 Oct 2016 18:05:16 -0700
Chris Albertson albertson.chris@gmail.com wrote:
The problem, I think with your Internet sync's NTP servers is you are only
using one server S. The most common practice is to use 3 to 5 with 5 being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
No they are correctly configured with 3 and 5 servers respectively.
I singled out server S out, because i didn't want to clutter the argument
with too many numbers and because S is common to both machines A and B
and because it's very close in internet terms (with 4.5ms and 2ms respectively).
The full view of A is (the last line is B):
remote refid st t when poll reach delay offset jitter
---============
+162.23.41.55 .MRS. 1 u 357 1024 377 4.555 0.198 0.293
*162.23.41.10 .MRS. 1 u 318 1024 377 4.403 -0.040 0.123
-131.188.3.223 .PZF. 1 u 548 1024 377 9.524 -0.654 0.039
+2001:67c:8:abcd .GPS1. 1 u 74 1024 373 12.163 0.143 0.168
-81.94.123.17 85.158.25.74 2 u 297 1024 377 0.985 -0.798 0.158
-2a02:418:f022:: 162.23.41.10 2 u 792 1024 377 0.649 -0.727 2.120
And the full view of B is:
remote refid st t when poll reach delay offset jitter
---============
*162.23.41.10 .MRS. 1 u 175 1024 377 2.067 -0.033 0.069
+195.186.1.101 195.186.150.242 2 u 504 1024 377 1.317 -0.360 0.086
+130.60.204.10 130.60.159.7 4 u 901 1024 377 1.539 0.932 2.065
Note: 162.23.41.10 (the server S) is one of the three NTP servers run by METAS
and fed by the official PPS of Switzerland.
And no, NTP cannot detect asymmetric network delays. They are completely
indisdinguishable from clock offsets. One can easily show that the
uncertainty in the network delay symmetry is the fundamental accuracy
limit of NTP. As the asymmetry is in general unbounded, the only guarantee
you have is that you are at most off by the RTT (aka delay) of the reference.
(given the reference itself is accurate)
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
You want to have them (time wise) as close as possible. Having many servers
does not help as much as having one accurate close by. Actually, once you
have a very close stratum 1, any additional server will degrade the
accuracy of NTP as NTP cannot know which of it's reference servers is
accurate or not (unless specifically configured).
In this case the correct answer to this "problem" would be to set up a
stratum 1 server in either of the colo centers and synchornize to that.
And if i had the hardware, I would do that. But then, being off by only 1ms
is not that bad for an internet facing ntp server where most of the clients
will be on ADSL/VDSL lines which exhibit some 10ms of delay.
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
On 10/05/2016 01:48 PM, Attila Kinali wrote:
On Tue, 4 Oct 2016 18:05:16 -0700
Chris Albertson albertson.chris@gmail.com wrote:
The problem, I think with your Internet sync's NTP servers is you are only
using one server S. The most common practice is to use 3 to 5 with 5 being
about the right number. If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.
No they are correctly configured with 3 and 5 servers respectively.
I singled out server S out, because i didn't want to clutter the argument
with too many numbers and because S is common to both machines A and B
and because it's very close in internet terms (with 4.5ms and 2ms respectively).
The full view of A is (the last line is B):
remote refid st t when poll reach delay offset jitter
---============
+162.23.41.55 .MRS. 1 u 357 1024 377 4.555 0.198 0.293
*162.23.41.10 .MRS. 1 u 318 1024 377 4.403 -0.040 0.123
-131.188.3.223 .PZF. 1 u 548 1024 377 9.524 -0.654 0.039
+2001:67c:8:abcd .GPS1. 1 u 74 1024 373 12.163 0.143 0.168
-81.94.123.17 85.158.25.74 2 u 297 1024 377 0.985 -0.798 0.158
-2a02:418:f022:: 162.23.41.10 2 u 792 1024 377 0.649 -0.727 2.120
And the full view of B is:
remote refid st t when poll reach delay offset jitter
---============
*162.23.41.10 .MRS. 1 u 175 1024 377 2.067 -0.033 0.069
+195.186.1.101 195.186.150.242 2 u 504 1024 377 1.317 -0.360 0.086
+130.60.204.10 130.60.159.7 4 u 901 1024 377 1.539 0.932 2.065
Note: 162.23.41.10 (the server S) is one of the three NTP servers run by METAS
and fed by the official PPS of Switzerland.
And no, NTP cannot detect asymmetric network delays. They are completely
indisdinguishable from clock offsets. One can easily show that the
uncertainty in the network delay symmetry is the fundamental accuracy
limit of NTP. As the asymmetry is in general unbounded, the only guarantee
you have is that you are at most off by the RTT (aka delay) of the reference.
(given the reference itself is accurate)
It is trivial to show that any two-way time-transfer mechanism, be it
NTP, PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error
between two clocks from that of the asymmetry between them. The Round
Trip Time (RTT) is however guaranteed unbiased under the assumption of
no (major) frequency difference. PTP adds means by which intermediate
nodes can provide delay estimations and thus allow cancellation of delay
in those equipments, but it does not help for asymmetry in path, such as
different fiber-lengths. Such delays needs to be calibrated.
With lots of observations you can however draw some conclusions of
likely cause of offsets, but without aiding through calibration, you
cannot draw a strict conclusion.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
You want to have them (time wise) as close as possible. Having many servers
does not help as much as having one accurate close by. Actually, once you
have a very close stratum 1, any additional server will degrade the
accuracy of NTP as NTP cannot know which of it's reference servers is
accurate or not (unless specifically configured).
In this case the correct answer to this "problem" would be to set up a
stratum 1 server in either of the colo centers and synchornize to that.
And if i had the hardware, I would do that. But then, being off by only 1ms
is not that bad for an internet facing ntp server where most of the clients
will be on ADSL/VDSL lines which exhibit some 10ms of delay.
Indeed. Asymmetry can build up in places where you do not expect it.
Most systems isn't designed for symmetric delay. Many works fairly
decent (at low load), but you never know and it's hard to tell.
Cheers,
Magnus