[e2e] Question about propagation and queuing delays

Christian Huitema huitema at windows.microsoft.com
Mon Aug 22 09:04:23 PDT 2005


> The remaining 15 msec. can be accounted for by the fiber path not
being
> straight line, or by various "buffering delays" (which include
queueing
> delays, and scheduling delays in the case where frames are scheduled
> periodically and you have to wait for the next frame time to launch
your
> frame).
> 
> Craig Partridge and I have debated (offline) what the breakdown might
> actually turn out to be (he thinks the total buffering delay is only
2-3
> msec., I think it's more like 10-12), and it would be quite
interesting
> to get more details, but that would involve delving into the actual
> equipment deployed and its operating modes.

One way to find out is to collect a large set of samples, and then look
at the minimum value. As long as the route does not change, the
propagation delay is the sum of the transmission times, which are
supposed constant, and a set of positive random values. The minimum of a
large sample is the sum of the transmission times and the minimum of the
random values, which tends towards zero.

Obviously, you have to verify the "stable route" hypothesis...

-- Christian Huitema 


More information about the end2end-interest mailing list