[ntp:hackers] More on asymmetric links

[Kurt Roeckx]

On Thu, Jul 12, 2007 at 05:17:05PM +0000, David L. Mills wrote:
> Guys,
> 
> A suggestion was made some time ago that the asymmetric link problem 
> could be solved by measuring the outbound and inbound data rates. This 
> could be done by determining the four timestamps for messages of varying 
> lengths. In particular, the various messages of the Autokey protocol. 
> The reason I climbed on this train was prompted by NASA's requirement 
> for deep space missions where the outbound and inbound link data rates 
> are far different.

Can you give an estimate of the datarates in both directions?

Anyway, this seems like a case where they have full control over the
data path between the 2 hosts, and you can calculate the difference in
time it takes for both directions.  So at first sight it would seem
more logical to just specify that in the config file.

I also have to wonder if they need to take the speed and direction
of the shuttle into account for this.  The distance to earth might
have changed so that it then takes longer or shorter in the other
direction.  But this asymmetric delay has nothing to do with the
bitrates themself.

> The results over a 100-Mb/s link was quite puzzling. The measured data 
> rates were far below the actual wire speed and varied a lot.

I was writing a mail about various problems you could run into with what
you're trying to do, but didn't have the time yet to finish it.

A simple example of why you're never going to see it say it can do 100
mbit/s is you have this setup:
Host A - switch - Host B

If you send a packet from host A to Host B, you have 2 links of 100 mbit
between them.  Both of those links will need an extra time to send those
few bytes more.  So in ideal conditions, you'll measure 50 mbit/s.

An other problem you might have is the calculation of the packet size
that is send.  You need to take all protocols on the wire into account.
For ethernet this might be:
ntp: 48 bytes
udp: 8 bytes
ip: 20 bytes
ethernet II: 14 bytes:

Total: 90 bytes.

And if you really want to be correct, you need to take timings that are
related to the physical layer you into account, like "start bits".

And if the link is more complicated than the example, you'll probably
have a hard time doing calculations that make some sense.

Anyway, there are other reasons for asymmetric delays too, and I'm not
even sure what the best way to handle those is.  But any estimation of
the asymmetric delay is probably better than nothing.


Kurt