Low-long-term-drift clock for board level integration?
On Tue, 21 Feb 2012 10:05:04 -0800
Chris Albertson albertson.chris@gmail.com wrote:
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 you read carefully what the OP wrote, you'll see that he
wants to measure one way trips.
RTT is easy and well understood. You can use a standard PC and
get to ~100us resolution with no special components. If you take
a NIC with time stamping, you get well below that.
But the problem is, in order to understand how networks behave
exactly and how this behaviour is changing over time, you need
to know the one way delays (mostly due to asymetric routing
which leads to asymetric load etc pp). And to do this, you need
a global time scale for time stamping. There is no way around it.
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
Perhaps another way to approach this problem would be to see if there are entities and or individuals who already have precision time keeping equipment (or at least access to GPS antennas) who might be able to participate in collecting this data.
--- On Tue, 2/21/12, Attila Kinali attila@kinali.ch wrote:
From: Attila Kinali attila@kinali.ch
Subject: Re: [time-nuts] Low-long-term-drift clock for board levelintegration?
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Received: Tuesday, February 21, 2012, 1:47 PM
On Tue, 21 Feb 2012 10:05:04 -0800
Chris Albertson albertson.chris@gmail.com
wrote:
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 you read carefully what the OP wrote, you'll see that he
wants to measure one way trips.
RTT is easy and well understood. You can use a standard PC
and
get to ~100us resolution with no special components. If you
take
a NIC with time stamping, you get well below that.
But the problem is, in order to understand how networks
behave
exactly and how this behaviour is changing over time, you
need
to know the one way delays (mostly due to asymetric routing
which leads to asymetric load etc pp). And to do this, you
need
a global time scale for time stamping. There is no way
around it.
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
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 2/21/12 10:47 AM, Attila Kinali wrote:
On Tue, 21 Feb 2012 10:05:04 -0800
Chris Albertsonalbertson.chris@gmail.com wrote:
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 you read carefully what the OP wrote, you'll see that he
wants to measure one way trips.
RTT is easy and well understood. You can use a standard PC and
get to ~100us resolution with no special components. If you take
a NIC with time stamping, you get well below that.
But the problem is, in order to understand how networks behave
exactly and how this behaviour is changing over time, you need
to know the one way delays (mostly due to asymetric routing
which leads to asymetric load etc pp). And to do this, you need
a global time scale for time stamping. There is no way around it.
What if one sends a message one way that triggers say, 10 response
messages 1 second apart. Then you get distribution statistics on the
return path. You still don't know what the absolute forward or reverse
path time was, of course.
On Tue, Feb 21, 2012 at 10:47 AM, Attila Kinali attila@kinali.ch wrote:
If you read carefully what the OP wrote, you'll see that he
wants to measure one way trips.
Yes, just like the swim coach who wants to measure the swimmer doing
one length of the pool. He uses a stop watch, Not two wrist
watches.
So in this case you computers yells "test" to the other computer which
responds with "I got it". You measure the round trip with a stop
watch. Then the other computer says test and you reply. You can
detect asymmetry by using long test messages and short replies and
sending them from both ends
Next you send a real data packet and wait for a reply then subtract
the time it takes for replies.
Chris Albertson
Redondo Beach, California
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
What if one sends a message one way that triggers say, 10 response messages 1 second apart. Then you get distribution statistics on the return path. You still don't know what the absolute forward or reverse path time was, of course.
Yes, that's one of the things that we do. You don't need a trigger, you can just transmit the beacon. That's how we measure jitter and out-of-order delivery, and how we detect parallel paths.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPRD1RAAoJEG+kcEsoi3+HUZ8P/RWJMhsT0AfAQa7a/AOb69Jm
n6AAz3YT62iyHkzzW7qVRT/2sL7+Vp0CWCMgDKnTlZJuQ4bvrnblFKVBV3eCfxWq
SJN6kMjLP+O/zd9hvghxZISMvdptEdJiMILoxGdeYJDLwblsewT8ZxC77VzNi24x
KNtAiJScJ6+3R5r1oAYg/+Uro1WNJCVFfTkixmB4GC/S7Ph9cxzHlxTb7jHo6D+I
sZm3a06JeudgKReE8PdJkrbv4vJNQFSHNSUI4M/BGevMp+nWppZcVCtIVwfYUY+0
jipE/oSaGllKhSZKs7t0Dn1/qcnMDGuSi238HiPWBvHPn7mNvsKXnupXcUW4E1jD
AIf1Sjh8KLVdvRPUgcqa4nhPoOOkasBGqOCYY67GyGyc7MpyOn5BndkV3DvvuVXY
D84VQOmgv2hvKt1Llbf6/Zqb2x1t+EkHO+1Ms6DifoUZwCGMnJDKiuuBMWKOrCJC
hp8LGJg2mfVwDkznULZ9zRHNqAWU378gYa4SmdqsPZ3QXD7Pz6f3pDy47PQQfXgy
A7hSrGPlEQaoyS/pFRjJzX4Z4M2+FJ7ci+FeajjlxAxCwGAg1nB1Hv0kTkY+F2H7
4s5L7AiOG4SGzFWjmucMKPDp2fLObxmZx7fFKCiW/Sft6cRaUNZYsk/OVNuQ4S5Y
WSOhqeWT9a0oThcFUSQg
=864K
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Feb 21, 2012, at 11:12 AM, Mark Spencer wrote:
Perhaps another way to approach this problem would be to see if there are entities and or individuals who already have precision time keeping equipment (or at least access to GPS antennas) who might be able to participate in collecting this data.
That approach has been tried by RIPE, and it yielded a couple of dozen usefullly-reliable measurement points after five years, twenty thousand man-hours, and about USD 1M in investment. That's not the approach we're taking, though certainly it has produced some useful results. The rate at which the number of links increases as a function of the number of nodes in a full mesh is a powerful incentive to pursue larger numbers of nodes.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPRD9hAAoJEG+kcEsoi3+Hwz4P/ibMR1SHnnsVmxdfWYKffRgF
xsZ/x4MAxb2feGIAQ0kNJXCrywZbPY4Ip0xpZpv/q5TsmpYUq4NXD3V1Li6qJhoY
jixRiCDwXwpkSBsLc7nqRelUELSU4xoAejNzIEEDZsXVfJcMydPrUv0ge+Hwz2Tg
S0GDaQYofZkNKUn1m3dFhLckM+gmKZpO6Q8BxD2s+AYlH83igAaTGl4qHpcvqEo6
FTP9lNTMbvzoCH7XT3VnQnQs2x93dKpBdZ15nMveONSahsFIFugePi0oEU6XMxe7
P/qweVmGNzUH0yLnGOT7FkwOuDyvPoeR052damXX/vsYuJFPqOJQsLl8RGIY5zZC
iGgNwCXFjnoxuNdHnUD3hvVZTVXGdLIU8G1XYua5eu/PktWVE1b8ZIwlI1wsM7K1
k/4aJGspVIOSlhiD775hMUGxd42fLiahmyCx4J6Y0y09XH4kusDIjhkKpaqFKdPL
foNj0w0lLEZI8VmFQ6oDaluKtWuIeiYk+SMRvAfazD7MDDMugbN/R1rxKMspCNyF
oD+B/dYJb0x8kgVP7eqerheaxBWwNXps0/XwsJggDczkPQw74uwEvK6I1DGLF9US
gHQDonmu1tyXfRGin4Zrexg10KpQj3hbLqGH8/gkgfk2AUyXDyt5uHCmOntUaT1o
OG84FIP5veDAzm7hukgY
=FYYB
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Feb 21, 2012, at 10:05 AM, Chris Albertson wrote:
BTW, Is the O.P. still here? I wonder if he is re-thinking his
requirements.
The requirement is to do one-way delay measurements. The requirement isn't changing. I'm just here to educate myself as to how to do the best job we can.
(1) Your method: [one-way delay]
(2) Easy method: [traceroute[
I suggest using method #2 for your network timing. Method #1 is
simply to expensive and technically hard
That's why there are some of us who spend money and work on hard problems. Traceroute already exists. In fact, plenty of one-way delay measurements already exist. We're just doing a larger, better one. Yes, that takes time and money. "Math is hard, let's go shopping" isn't a particularly interesting argument.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPRECuAAoJEG+kcEsoi3+H0QEP/jT7VAz6h7a+C/uFWnU8S7P5
4KwElPQBjkl6O9gbDGkPZ9JxI7wolrV/W5aQyAafc9tpXtcPlqwtINbxfdpz0tcc
NDo24ths2TOL7e8Z51Z/dCTrrnUNCLPVhw/uOkYFu/SOrDOXjj6CNwfvh8Lvz3zx
sTvxWj/yaccPydO0vnuAXQWP+e8NIQlADwT2ZJJ2lriZulDXoLalH/OKTgSzIkcM
0W08yzPjKi4SvYsMZSkg6lkacNugfBBinZdizw3g2RowOfCjkXKtKVcIMSAhGaxG
3eb3Gqvv3iDn04MzIJuuQx8a1Cui0HhN/98cDPGOk+3xiEVI016QwYFl0SxeZmp8
v3lOz3FYia7mwRJlPRgALGOLelkIIjoZqLRdYXyBS8U5jVdjvaA4IbftBNUXvGHw
4C8z3s2ywmfFFuA4hbUWgDW9uZR48Byw1ViYpdcT2654ZoqcADQ9RkD96yL1ddd9
Z7nwbf154SFTouDei4nCL9W6HmE3CZrPKoKc3H1vWD+ys3jDjul0343nWCXbbjUL
3F7gnB9viOM0wGXrhaJ1dpUGdHNpWYVxaY3tKMClUbRxsfh7eTBCEIWLA20cH79C
/l2+ZM16GO8AYiELGNum+OWeYak8iAFG+5KaTIeKXI51ksXf8jiODCBhGwnXlHKi
9Hlji30Hjo7mGSAexcXR
=v+Vt
-----END PGP SIGNATURE-----
Seems the problem is possible asymmetry in the speed of network
connections. You really can not detect this with simple "pings".
But what if you send 100MB messages? Even using NTP at the tens of
millisecond level you can measure the one way speed accurately if the
message is long enough. Send one large message in each direction and
you'll have the forward to reverse speed ratio. Now rather than
divide the round trip time by two. We know the speed ratios for the
forward and reverse link
Chris Albertson
Redondo Beach, California
On Tue, 21 Feb 2012 23:23:23 -0800
Chris Albertson albertson.chris@gmail.com wrote:
Seems the problem is possible asymmetry in the speed of network
connections. You really can not detect this with simple "pings".
But what if you send 100MB messages? Even using NTP at the tens of
millisecond level you can measure the one way speed accurately if the
message is long enough. Send one large message in each direction and
you'll have the forward to reverse speed ratio. Now rather than
divide the round trip time by two. We know the speed ratios for the
forward and reverse link
The speed (or bandwidth) of a link is independent of its delay.
Eg a 10Gbit/s fiber will have 10Gbit/s no matter whether it's 1m
or 100km long. But its delay will vary from ~3ns to ~300us.
Usually, for internet links, their speed is known (especially if you
own the link yourself). What you want to know is whether the delay
induced by the time in flight, routers, repeaters, etc changes over
time.
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
I would not fully trust NTP, and as already explained taking your GPS
outside as a reference for just a while is not really going to help.
But..why not using GPS inside the building? Some receivers are quite
sensitive, so probably you will not need an external antenna to pick up a
signal. Probably you may have to throw a cable from floor to floor, or
place your antenna close to a window, but this is much simpler than
installing an antenna on a roof. You will not get ns accuracy, but to make
worse than 100us you will need a hell of a lot of reflections inside your
building.
Cheers,
pablo