One-way delay measurement for netperf-wrapper

[Eggert, Lars]

Hi,

On 2013-11-29, at 14:04, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Now, some possible issues with this:
> 
> - Are we measuring the right thing? This will measure the time it takes
>  a message to get from the application level on one side to the
>  application level on another. There are a lot of things that could
>  impact this apart from queueing latency; the most obvious one is
>  packet loss and retransmissions which will give some spurious results
>  I suppose (?). Doing the measurement with UDP packets would alleviate
>  this, but then we're back to not being in-stream...

right. I happen to be interested in that metric, but not everyone may be. Some folks may only care about latencies added in the network, in which case the TCP-timestamp-based approach might be better (if the kernel can be convinced to generate timestamps with sufficient resolution).

You could also combine the two approaches. That way, you might be able to account for sender, network and receiver latencies.

> - As for point 3, not normalising the result and just outputting the
>  computed delay as-is means that the numbers will be meaningless
>  without very accurately synchronised clocks. On the other hand, not
>  processing the numbers before outputting them will allow people who
>  *do* have synchronised clocks to do something useful with them.
>  Perhaps a --assume-sync-clocks parameter?

Yep. Or you could check for the accuracy of the NTP synchronization, as suggested by Hal.

> - Echoing back the delay measurements causes traffic which may or may
>  not be significant; I'm thinking mostly in terms of running
>  bidirectional measurements. Is that significant? A solution could be
>  for the receiver to hold on to all the measurements until the end of
>  the test and then send them back on the control connection.

Depends on the measurement interval. I'm guessing it won't matter much if you e.g. only timestamp once a millisecond or something.

> - Is clock drift something to worry about over the timescales of these
>  tests?
>  https://www.usenix.org/legacy/events/iptps10/tech/slides/cohen.pdf
>  seems to suggest it shouldn't be, as long as the tests only run for at
>  most a few minutes.

Wouldn't think so.

> So anyway, thoughts? Is the above something worth pursuing?

I certainly would like this test. It may also be a good proposal for the IPPM metric.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20131129/39ab5106/attachment.sig>