<p dir="ltr"><br>
On Nov 29, 2013 6:30 AM, "Eggert, Lars" <<a href="mailto:lars@netapp.com">lars@netapp.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On 2013-11-29, at 14:04, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br>
> > Now, some possible issues with this:<br>
> ><br>
> > - Are we measuring the right thing? This will measure the time it takes<br>
> >  a message to get from the application level on one side to the<br>
> >  application level on another. There are a lot of things that could<br>
> >  impact this apart from queueing latency; the most obvious one is<br>
> >  packet loss and retransmissions which will give some spurious results<br>
> >  I suppose (?). Doing the measurement with UDP packets would alleviate<br>
> >  this, but then we're back to not being in-stream...<br>
><br>
> 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).<br>

><br>
> You could also combine the two approaches. That way, you might be able to account for sender, network and receiver latencies.<br>
><br>
> > - As for point 3, not normalising the result and just outputting the<br>
> >  computed delay as-is means that the numbers will be meaningless<br>
> >  without very accurately synchronised clocks. On the other hand, not<br>
> >  processing the numbers before outputting them will allow people who<br>
> >  *do* have synchronised clocks to do something useful with them.<br>
> >  Perhaps a --assume-sync-clocks parameter?<br>
><br>
> Yep. Or you could check for the accuracy of the NTP synchronization, as suggested by Hal.<br>
><br>
> > - Echoing back the delay measurements causes traffic which may or may<br>
> >  not be significant; I'm thinking mostly in terms of running<br>
> >  bidirectional measurements. Is that significant? A solution could be<br>
> >  for the receiver to hold on to all the measurements until the end of<br>
> >  the test and then send them back on the control connection.<br>
><br>
> Depends on the measurement interval. I'm guessing it won't matter much if you e.g. only timestamp once a millisecond or something.<br>
><br>
> > - Is clock drift something to worry about over the timescales of these<br>
> >  tests?<br>
> >  <a href="https://www.usenix.org/legacy/events/iptps10/tech/slides/cohen.pdf">https://www.usenix.org/legacy/events/iptps10/tech/slides/cohen.pdf</a><br>
> >  seems to suggest it shouldn't be, as long as the tests only run for at<br>
> >  most a few minutes.<br>
><br>
> Wouldn't think so.<br>
><br>
> > So anyway, thoughts? Is the above something worth pursuing?<br>
><br>
> I certainly would like this test. It may also be a good proposal for the IPPM metric.<br>
><br>
> Lars<br>
><br>
> _______________________________________________<br>
> Bloat-devel mailing list<br>
> <a href="mailto:Bloat-devel@lists.bufferbloat.net">Bloat-devel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat-devel">https://lists.bufferbloat.net/listinfo/bloat-devel</a><br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr"><a href="http://www.ietf.org/proceedings/88/slides/slides-88-ippm-0.pdf">http://www.ietf.org/proceedings/88/slides/slides-88-ippm-0.pdf</a></p>
<p dir="ltr">I liked the chart and I seem to recall there was an implementation.<br>
</p>