> However, if you buy these numbers, then a reasonable amount of the time
> we're being delayed by servers and not queuing. On the other hand, look
> at the median packet loss rate of 16%! Ouch.
Wow. That is pretty high. Of course, it's possible that this could just be
congestion on bellcore's link to the net.
> Its also nice to see that
> DNS delay is substantial (I've always suspected that DNS is a problem
> child).
Though keep in mind that you'll pay this DNS penalty rarely - you'll only
pay the DNS price for the very first connection to a server (when you'll
probably be making dozens) and then only if nobody from your site has
cached that name's IP address in the last few days. Still, DNS is painful
over a modem, in my experience.
>Finally, it is totally unbelievable to see the difference
> between the median page delay and the sum of DNS, connection, server and
> transmission delay (more than double). I can't believe this is all
> rendering and layout time... if the page has multiple inlines then it
> could be that this reflects exponential backoff on one of the several
> connections for the page (the variance on the connection and
> transmission delay is quite high and the sum of the averages works out).
I bet that they're just using a script to download a single index.html
(not measuring any browser compute/render time), and that the "Page delay
(ms)" math is either an error, or some weird way in which the medians of
sums of heavy-tailed things come out. My guess is the second effect.
neal