Low-long-term-drift clock for board level integration?
The path is variable. Internet routing is constantly in flux as routes are injected and retracted.
On Feb 20, 2012, at 19:56, Brooke Clarke brooke@pacific.net wrote:
Hi Bob:
It was my understanding that the receiving station knows the path taken, is that the case? Or are you saying even when it's the same path the time delay has large variations?
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html
Bob Camp wrote:
Hi
Since the network is being measured, I suspect that using it as the time reference would present a basic problem.
Bob
On Feb 20, 2012, at 2:07 PM, Jim Luxjimlux@earthlink.net wrote:
On 2/20/12 10:31 AM, Bob Camp wrote:
Hi
Simple answer:
A rack mount cesium standard is as good as you can get. Figure on 15 ns per day of drift. That gets you to 15 us in 1000 days. You may or may not get one that drifts that little, a lot depends on little details. For> 3 years, consider an ensemble of cesiums. At $50K each cost can go up pretty fast.
There is nothing out there that will do better stand alone for less money. Either you get a sky view or you change the budget....
Bob
But he does have the ability to have an external network connection.. So the real question is whether one could come up with a better-than-NTP scheme to get the 100 (or 10) microseconds.
I suspect that with sufficiently controlled network paths (which might be doable in a widescale deployment) and a tweaking of the NTP stuff, you might be able to get it to work.
100 microseconds out of a day is 1E-10, which is actually a fairly liberal drift spec for an OCXO or even a TCXO. (which are things like ppb/day)
Maybe there's a particular time of day (or day of week) when network uncertainties are minimal, or can be bounded. So what you really need is a onboard oscillator that is good at "carry over" between periodic calibration checks.
One question about the 100 microsecond spec.. is that a worst case at any instant, or is it an average spec over a day (so a consistent diurnal variation would cancel out)
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.
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Feb 20, 2012, at 4:56 PM, Brooke Clarke wrote:
It was my understanding that the receiving station knows the path taken, is that the case? Or are you saying even when it's the same path the time delay has large variations?
The sending station can map the path, using traceroute or its equivalent, and send that information to the receiving station. The path changes unpredictably, as circuits and routers go up and down, and the routing topology shifts. Path changes generally look like a shift in both baseline and jitter, which tips you off to re-map the path from the sending side.
And yes, even when the path is consistent, its delay generally varies a lot, depending upon the depth of the intervening routers' and switches' transmit queues and forwarding-engine loads, temperature, etc. What makes it possible at all is that the cost of a measurement is low, so you can keep measuring and measuring, and establish a minimum floor, which is what you'll get when, coincidentally, you happen to hit all empty transmit queues.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPQvT+AAoJEG+kcEsoi3+HwZIP/A8388xBYXLtyvlhCBO5rSBw
qYhfvGbkOO/w8nn/57SXi1ZohYsqmc1nBFK8vrfWm7EwOlPTG4a9nBzd3+569RmK
xWPQoa9mzHP8kAfZ69MVwYUUXjyBl/wkinC9I7Qx2+YXj4mmId+nSk6y9dfyYcgP
IDkmidwzdALbpxp3MZFy1q5sIMIfOmkgLhE0q99cRRwr/8nQiAaMv/q34iwazNwm
nNYAg0kJrwpFDO5y2wyNrqUS8wqD1z1xJeWp0WVJS/IlvUZiuO4t9J42Amp+en95
JXs3wqE3ULKBsYYBkmRZDCDXJRKVNLUrQImsv7coN6c7iT/tyzOsMOPRWicD8xVx
NTKRboanlhFh9Rzx0p4spW/BDEqQqJcju9qLk8fh79dLzUVAKIOUnbg3rf2kROVV
wIokBv9CFJPm7uH7EaSQ+NJvn+pT04Ia6Ko8wOtPrKwamFaxXWI9Nkx3Spuesjje
MoO7mFi3hqGDfua5QseK1+5tXqhET8uijR/6N+55+eQbTvEkQLYHTy20Ea/EWXyS
amQxMmj2UNcBKERPswVAr3cgwLjUhoZM7LvlrgOsawpG8cjILaSAhZ74nthcFaJF
YphpoliDPw4IDxa8rc4Hwow7bfaMf5Q3LFqbuMDFtIxHgi+hHZbKg70nvE1B+ivN
j9TLFrpIwCQtg9zclrmG
=AChX
-----END PGP SIGNATURE-----
On Mon, Feb 20, 2012 at 12:13 PM, Brooke Clarke brooke@pacific.net wrote:
You may be able to do a similar thing in your receivers. For example if the
master node were to send a timing message at known times (say once at the
top of every hour) the receivers could use that to determine their local
clock offset and rate for those cases where the path was the same (or maybe
even for a list of paths). The offset and rate numbers can be used to
correct the measured time to actual time without changing the clock's rate
using simple math. You can trade the receiver clock stability for the time
between the timing messages.
So you are suggesting a very simplified version of NTP. I doubt you'd
do better than using real-NTP.
It turns out the method works at the millisecond level but not at the
uSec level unless "everyone" is on the same local Ethernet
There is one way to improve timing but it only works if you have
control of all the network equipment. This means it can't work on
the Internet but it can work on some large networks. Use "PTP".
This is a little like NTP in that it uses a network for time
distribution but has a slightly different method. Unlike NTP, for
PTP you need special routers and switches built to support PTP but
then PTP can support uSecond level timing over a wide area and NTP
mostly can't
http://en.wikipedia.org/wiki/Precision_Time_Protocol
Chris Albertson
Redondo Beach, California
Even if the path is mapped the ques in the switches can change. Say your
packet is first and the next trip its the 50th. Just depends on the overall
network loading.
This has been tried many times and there is the ability to get a feel on
the timing. But not like GPS.
Regards
Paul.
WB8TSL
On Mon, Feb 20, 2012 at 8:40 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Mon, Feb 20, 2012 at 12:13 PM, Brooke Clarke brooke@pacific.net
wrote:
You may be able to do a similar thing in your receivers. For example if
the
master node were to send a timing message at known times (say once at the
top of every hour) the receivers could use that to determine their local
clock offset and rate for those cases where the path was the same (or
maybe
even for a list of paths). The offset and rate numbers can be used to
correct the measured time to actual time without changing the clock's
rate
using simple math. You can trade the receiver clock stability for the
time
between the timing messages.
So you are suggesting a very simplified version of NTP. I doubt you'd
do better than using real-NTP.
It turns out the method works at the millisecond level but not at the
uSec level unless "everyone" is on the same local Ethernet
There is one way to improve timing but it only works if you have
control of all the network equipment. This means it can't work on
the Internet but it can work on some large networks. Use "PTP".
This is a little like NTP in that it uses a network for time
distribution but has a slightly different method. Unlike NTP, for
PTP you need special routers and switches built to support PTP but
then PTP can support uSecond level timing over a wide area and NTP
mostly can't
http://en.wikipedia.org/wiki/Precision_Time_Protocol
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.
Hi
My understanding is that the path delay is what is being monitored.
Bob
On Feb 20, 2012, at 7:56 PM, Brooke Clarke brooke@pacific.net wrote:
Hi Bob:
It was my understanding that the receiving station knows the path taken, is that the case? Or are you saying even when it's the same path the time delay has large variations?
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html
Bob Camp wrote:
Hi
Since the network is being measured, I suspect that using it as the time reference would present a basic problem.
Bob
On Feb 20, 2012, at 2:07 PM, Jim Luxjimlux@earthlink.net wrote:
On 2/20/12 10:31 AM, Bob Camp wrote:
Hi
Simple answer:
A rack mount cesium standard is as good as you can get. Figure on 15 ns per day of drift. That gets you to 15 us in 1000 days. You may or may not get one that drifts that little, a lot depends on little details. For> 3 years, consider an ensemble of cesiums. At $50K each cost can go up pretty fast.
There is nothing out there that will do better stand alone for less money. Either you get a sky view or you change the budget....
Bob
But he does have the ability to have an external network connection.. So the real question is whether one could come up with a better-than-NTP scheme to get the 100 (or 10) microseconds.
I suspect that with sufficiently controlled network paths (which might be doable in a widescale deployment) and a tweaking of the NTP stuff, you might be able to get it to work.
100 microseconds out of a day is 1E-10, which is actually a fairly liberal drift spec for an OCXO or even a TCXO. (which are things like ppb/day)
Maybe there's a particular time of day (or day of week) when network uncertainties are minimal, or can be bounded. So what you really need is a onboard oscillator that is good at "carry over" between periodic calibration checks.
One question about the 100 microsecond spec.. is that a worst case at any instant, or is it an average spec over a day (so a consistent diurnal variation would cancel out)
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.
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Feb 20, 2012, at 11:07 AM, Jim Lux wrote:
One question about the 100 microsecond spec.. is that a worst case at any instant, or is it an average spec over a day (so a consistent diurnal variation would cancel out)
Well, it's not a hard limit, it's a target at which our system would be performing at a level we'd be happy with. Obviously some measurements will be less accurate, others more so, and we get what we get.
One of the primary reasons for doing link-by-link unidirectional delay measurement is to estimate the length or routing of cables. Each microsecond of inaccuracy is 650 feet of inaccuracy in the estimate. 650 feet isn't of any interest. But twelve miles (100 microseconds of inaccuracy) is starting to get up into the range where you might not be able to distinguish one city from another, for instance. One millisecond is 123 miles, and we might well be into another country or something at that point.
Measuring queue depths and estimating degrees of resource contention or processing inside routers is a more complex topic, but similar in that it tends to still be interesting in the 100 microsecond range, but less so at another order of magnitude less precision.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPQvtsAAoJEG+kcEsoi3+HafsQAJQJAkux30PcrGkzcw2oZQNx
7xKXvGYA/V4Lnr11NpB/7x8JewiXvKC83iSLlJGRpmNC3Sy1egbbP13YMkfew83l
YcOn5O5g+d336//EA/hj4lrQAslr3HGG7nayt7sIZPbLnkBuiWf4mv8YMUSi+f/B
RMSeSCtGPbEwa7aqs6MmTZ4QKZIzE587v5nsoZFnN056NbE+kS2MrlF2Y5ll0apC
cfE/RBAoYp3X8ev+Gh+C0jxHX4nfutDaS/vAcJub5o/WDW3rmn5yj7wztiDst2T/
36ACCxAfll0EqbcmYQF97/rOiteLJOyJOjzOEXBrV/at2v66bYwENKRSwZYMRgVT
tG/7+fgZ/DOFCPCjE/y/Ywgmfn5vAn+iNHaW3hUxi0xVgCidQwEZtVyqwrj8LC4Z
XFKWG+eUwNLWAnCI2KZAJJFYHtaZooXlSQXuh4IwfCZPeD1by49u4aH6LRLbP1at
eXghWWjhOL4WzGzGQFn/WnPLB+cYADzarNuQf3uk2e2DvgJh4/JJH3H/+IX2m7UF
4Vc6Cm3ojlhnMMbmdA5IUrpqawfGgd61y+7LEK3vjwK6x8XMWjNV/RL6JfSrrs/i
JoxF1svN+HVYIykn2fSPjnaODbzw+BgtAweCZ22YtkECWQA7m0kFGqSDYe/s2xwG
ddesTvAo4pZ+O7j6Lpl2
=149M
-----END PGP SIGNATURE-----
Hi
Even on good networks, getting below 1 ms with NTP is problematic. Yes indeed I have a heard of servers that will go below one us on a local LAN. That all breaks down pretty fast ( like under a dozen hops ) once you are on the Internet. 10 to 100 us is only going to work on NTP with local nets and symmetric routing.
Bob
On Feb 20, 2012, at 8:44 PM, paul swed paulswedb@gmail.com wrote:
Even if the path is mapped the ques in the switches can change. Say your
packet is first and the next trip its the 50th. Just depends on the overall
network loading.
This has been tried many times and there is the ability to get a feel on
the timing. But not like GPS.
Regards
Paul.
WB8TSL
On Mon, Feb 20, 2012 at 8:40 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Mon, Feb 20, 2012 at 12:13 PM, Brooke Clarke brooke@pacific.net
wrote:
You may be able to do a similar thing in your receivers. For example if
the
master node were to send a timing message at known times (say once at the
top of every hour) the receivers could use that to determine their local
clock offset and rate for those cases where the path was the same (or
maybe
even for a list of paths). The offset and rate numbers can be used to
correct the measured time to actual time without changing the clock's
rate
using simple math. You can trade the receiver clock stability for the
time
between the timing messages.
So you are suggesting a very simplified version of NTP. I doubt you'd
do better than using real-NTP.
It turns out the method works at the millisecond level but not at the
uSec level unless "everyone" is on the same local Ethernet
There is one way to improve timing but it only works if you have
control of all the network equipment. This means it can't work on
the Internet but it can work on some large networks. Use "PTP".
This is a little like NTP in that it uses a network for time
distribution but has a slightly different method. Unlike NTP, for
PTP you need special routers and switches built to support PTP but
then PTP can support uSecond level timing over a wide area and NTP
mostly can't
http://en.wikipedia.org/wiki/Precision_Time_Protocol
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.
Even with a very minimal local Ethernet where the path is the same for
every packet you still have variable timing. There are queues and
buffers. Also it is not so easy to measure the time a network packet
arrives at a computer.
The serial port is the best hardware for timing. The DCD pin is
directly tied to a hardware interrupt that has as low a latency as you
will find on the PC. These is nothing like this hardware interrupt
in the Ethernet controller.
There is a way around this, some Ethernet controllers can time stamp
the data packets in hardware. This can be used by PTP for timing that
is almost as good as the serial port.
So you add the uncertain timing because of queues to the un-abilty to
accurately determine when the data pack arrives and you are stuck in
the millisecond level
On Mon, Feb 20, 2012 at 6:02 PM, Bob Camp lists@rtty.us wrote:
Hi
My understanding is that the path delay is what is being monitored.
Bob
On Feb 20, 2012, at 7:56 PM, Brooke Clarke brooke@pacific.net wrote:
Hi Bob:
It was my understanding that the receiving station knows the path taken, is that the case? Or are you saying even when it's the same path the time delay has large variations?
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html
Bob Camp wrote:
Hi
Since the network is being measured, I suspect that using it as the time reference would present a basic problem.
Bob
On Feb 20, 2012, at 2:07 PM, Jim Luxjimlux@earthlink.net wrote:
On 2/20/12 10:31 AM, Bob Camp wrote:
Hi
Simple answer:
A rack mount cesium standard is as good as you can get. Figure on 15 ns per day of drift. That gets you to 15 us in 1000 days. You may or may not get one that drifts that little, a lot depends on little details. For> 3 years, consider an ensemble of cesiums. At $50K each cost can go up pretty fast.
There is nothing out there that will do better stand alone for less money. Either you get a sky view or you change the budget....
Bob
But he does have the ability to have an external network connection.. So the real question is whether one could come up with a better-than-NTP scheme to get the 100 (or 10) microseconds.
I suspect that with sufficiently controlled network paths (which might be doable in a widescale deployment) and a tweaking of the NTP stuff, you might be able to get it to work.
100 microseconds out of a day is 1E-10, which is actually a fairly liberal drift spec for an OCXO or even a TCXO. (which are things like ppb/day)
Maybe there's a particular time of day (or day of week) when network uncertainties are minimal, or can be bounded. So what you really need is a onboard oscillator that is good at "carry over" between periodic calibration checks.
One question about the 100 microsecond spec.. is that a worst case at any instant, or is it an average spec over a day (so a consistent diurnal variation would cancel out)
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.
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
The only saving feature on a local LAN is that you get to run a lot of
data if you wish to. That helps you average things out. You can indeed get
well below 1 ms in that case.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Chris Albertson
Sent: Monday, February 20, 2012 9:57 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Low-long-term-drift clock for board
levelintegration?
Even with a very minimal local Ethernet where the path is the same for
every packet you still have variable timing. There are queues and
buffers. Also it is not so easy to measure the time a network packet
arrives at a computer.
The serial port is the best hardware for timing. The DCD pin is
directly tied to a hardware interrupt that has as low a latency as you
will find on the PC. These is nothing like this hardware interrupt
in the Ethernet controller.
There is a way around this, some Ethernet controllers can time stamp
the data packets in hardware. This can be used by PTP for timing that
is almost as good as the serial port.
So you add the uncertain timing because of queues to the un-abilty to
accurately determine when the data pack arrives and you are stuck in
the millisecond level
On Mon, Feb 20, 2012 at 6:02 PM, Bob Camp lists@rtty.us wrote:
Hi
My understanding is that the path delay is what is being monitored.
Bob
On Feb 20, 2012, at 7:56 PM, Brooke Clarke brooke@pacific.net wrote:
Hi Bob:
It was my understanding that the receiving station knows the path taken,
is that the case? Or are you saying even when it's the same path the time
delay has large variations?
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html
Bob Camp wrote:
Hi
Since the network is being measured, I suspect that using it as the time
reference would present a basic problem.
Bob
On Feb 20, 2012, at 2:07 PM, Jim Luxjimlux@earthlink.net wrote:
On 2/20/12 10:31 AM, Bob Camp wrote:
Hi
Simple answer:
A rack mount cesium standard is as good as you can get. Figure on 15
ns per day of drift. That gets you to 15 us in 1000 days. You may or may not
get one that drifts that little, a lot depends on little details. For> 3
years, consider an ensemble of cesiums. At $50K each cost can go up pretty
fast.
There is nothing out there that will do better stand alone for less
money. Either you get a sky view or you change the budget....
Bob
But he does have the ability to have an external network connection..
So the real question is whether one could come up with a better-than-NTP
scheme to get the 100 (or 10) microseconds.
I suspect that with sufficiently controlled network paths (which might
be doable in a widescale deployment) and a tweaking of the NTP stuff, you
might be able to get it to work.
100 microseconds out of a day is 1E-10, which is actually a fairly
liberal drift spec for an OCXO or even a TCXO. (which are things like
ppb/day)
Maybe there's a particular time of day (or day of week) when network
uncertainties are minimal, or can be bounded. So what you really need is a
onboard oscillator that is good at "carry over" between periodic calibration
checks.
One question about the 100 microsecond spec.. is that a worst case at
any instant, or is it an average spec over a day (so a consistent diurnal
variation would cancel out)
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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, Feb 21, 2012 at 9:16 AM, Bob Camp lists@rtty.us wrote:
Hi
The only saving feature on a local LAN is that you get to run a lot of
data if you wish to.
Also, by definition a "local LAN" does not have a router.
BTW, Is the O.P. still here? I wonder if he is re-thinking his
requirements. I think his plan was to do timing by comparing the
real-time time stamps at each end of a network connection. That
would require very, very good time keeping that is not even possible
without GPS. Perhaps he has now given up on that approach and has
gone to using relative time and round trip timing which would work
even using a $2 TTL "can oscillator".
If the OP is still here, try this analogy: You want to know how long
a swimmer takes to swim the length of the pool. There are two
methods
(1) Your method: Have two coaches, one on each end of the pool each
with a wrist watch. The first coach says "go" and notes the time.
The second coach waits for the swimmer then writes down the time when
the swimmer touches the end of the pool. Later you subtract time 1
from time 2. This can work but requires some very good watches that
are in perfect sync
(2) Easy method: First coach says go and starts a stop watch. Second
coach yells "done" when the swimmer reaches the end and the first
coach stops the watch. No precision time sync is required but we do
need a backward communication path and we need to know the delay in
that path. The first coach can measure the round trip delay by
occasionally yelling "test" and listening for a reply from the second
coach. Then he assumes the one-way delay is 1/2 the round trip.
I suggest using method #2 for your network timing. Method #1 is
simply to expensive and technically hard especially on a $300 budget
with "no clue" installers.
Now we can move the discussion to measuring the speed of the backwards
channel with some method better than just taking 1/2 the round trip.
Chris Albertson
Redondo Beach, California