Re: One-way delay measurement for netperf-wrapper

["Eggert, Lars" <lars@netapp.com>]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

Hi,

On 2013-11-28, at 19:51, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 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.

that would be a great addition. But I think it will require some fundamental change to the wrapper (actually , probably to netperf.) Or at least a solution a complete solution would.

If I remember correctly, the wrapper runs various netperf flows to generate load, and in parallel runs a ping session in order to measure latency.

That works fine if all these flows go through all the same bottlenecks, but when they don't (because the switch does something funky for ICMP, etc.) it fails. It also doesn't account for stack-induced latencies.

I'd really like to see some measurement tool (netperf, flowgrind, etc.) grow support for measuring latencies based on the actual load-generating data flow. Ideally and assuming fully sync'ed clocks, I'd like to timestamp each byte of a TCP stream when an app does write(), and I'd like to timestamp it again when the receiving app read()s it. The difference between the two timestamps is the latency that byte saw end-to-end.

(Yes, you wouldn't want/need to do this for each byte, I'm just speaking conceptually.)

That measurement would include the stack/driver latencies which you don't currently capture with a parallel ping. For datacenter scenarios with very low RTTs, these sources of latency begin to matter.

I think that Stas' thrulay tool did measure latencies in this way, but it has accumulated some serious bitrot.

Lars

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 273 bytes --]