Re: One-way delay measurement for netperf-wrapper

[Dave Taht <dave.taht@gmail.com>]

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

On Nov 29, 2013 6:30 AM, "Eggert, Lars" <lars@netapp.com> wrote:
>
> Hi,
>
> On 2013-11-29, at 14:04, Toke Høiland-Jørgensen <toke@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
>
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel
>

The idea of creating a generic ipv6 header for timestamps was discussed at
ietf. I am under the impression this is an old SNA feature.

http://www.ietf.org/proceedings/88/slides/slides-88-ippm-0.pdf

I liked the chart and I seem to recall there was an implementation.

[-- Attachment #2: Type: text/html, Size: 3969 bytes --]