One-way delay measurement for netperf-wrapper

[Hal Murray]

toke at toke.dk said:
> So I've been thinking about adding one-way delay measurement to
> netperf-wrapper, but thought I'd solicit some input on how best to do that. 

I haven't worked with netperf in ages, but I have done a lot of one-way 
measurements using ntp.

I think you have two choices.  One is to assume that both clocks are 
accurate.  The other is to assume that the network delays are symmetric.

What sort of delays are you measuring and/or what sort of accuracy do you 
want/expect?

If you assume the clocks are accurate, it's easy to make graphs and such.  
You can get how-accurate info from ntpd's log files if you turn on enough 
logging.  It's not unreasonable to setup your own GPS receiver so you can be 
sure your clock is accurate.  (I'll say more if anybody wants.)

Suppose you don't trust the times.  Here is the handwave recipe for measuring 
the time offset assuming the network delays are symmetric:

Take a bunch of NTP like calibration measurements.  Each measurement gives 
you 3 time stamps: left here, got there, got back here.  That's enough to 
compute the round trip time.  Graph the round trip time vs time-of-test.  
There should be a band of points clustered around some minimum round trip 
time.  Those are the good ones.  Everything else hit some queuing delays.  If 
you assume the network delays are symmetric you can compute the offset.  If 
you assume the offset is 0 (aka clocks are good) you can compute the one-way 
delays.

If you are interested in that approach, I suggest writing some calibration 
code, collecting some data and graphing it to get a feel for things.

If you know in advance the pairs of machines you are likely to use for 
testing, you can set their ntpds to point to eachother and turn on rawstats 
logging and ntpd will collect calibration data for you.  That will give you 
an eye-ball level sanity check.


-- 
These are my opinions.  I hate spam.