Uploads and downloads to/from my<div>web hosting site, and from many of</div><div>the sites hosting various distributions</div><div>of Linux.</div><div><br></div><div>I'm talking about direct measurements,</div><div>and I guess you're talking about performance</div>
<div>across the web? I don't claim that I will get</div><div>full bandwidth from all sources, no matter</div><div>how congested, etc., but if I download a</div><div>100 Mb file in a time that corresponds to</div><div>
40 Mbps, that real bandwidth, at least </div><div>in an average sense. </div><div><br></div><div>Anyway, each person can wrestle with this,</div><div>or pose more specific questions. I'll continue</div><div>to maintain I know the bandwidth I'm getting</div>
<div>under some circumstances that are important</div><div>to me. Whether I can come up with a </div><div>bandwidth number meaningful over all </div><div>sources, and all times of day and week is</div><div>probably another thing.</div>
<div><br></div><div>But "meaningless" still strikes me as too</div><div>strong a way to describe attempts to see</div><div>one's connection speed.</div><div><br></div><div> -- Bob</div><div><br></div><div>
<br><div class="gmail_quote">On Sat, Jul 9, 2011 at 1:50 PM, Adam Tauno Williams <span dir="ltr"><<a href="mailto:awilliam@whitemice.org">awilliam@whitemice.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, 2011-07-09 at 10:32 -0400, Bob Kline wrote:<br>
> Can you elaborate please?<br>
<br>
</div>I'm pretty sure I've gone over this before [probably in response to one<br>
of your many posts about ISP "performance"], but anyway...<br>
<br>
1 - The ***ONLY*** way to draw conclusive performance benchmarks<br>
regarding a circuit require the testing of the circuit from near to far<br>
end. Testing from near end to some remote point far beyond the<br>
end-point of a circuit does *NOT* provide a conclusive measurement of<br>
the circuit's performance. Please stop claiming that it does.<br>
<br>
2 - Making useful/valid performance measurements about a circuit if you<br>
cannot meet the near-far-end requirement of #1 is non-trivial. You<br>
*certainly* can *NOT* do so using a file-transfer or web-site.<br>
A - You need to measure a traffic *mix*<br>
B - You need to measure over a long period of time<br>
C - You need to measure between many remote points.<br>
* Otherwise what you are measuring is very close to meaningless.<br>
<br>
Also throughput does not correlate 1:1 with latency, or vice-versa. And<br>
depending on the application one may be more important than the other<br>
(hence 2A). Application performance is what really matters.<br>
<br>
The Internet is vast and complex and subject to all the issues that<br>
effect vast and complex systems:<br>
- You do not know the connectivity condition or throughput of the<br>
remote.<br>
- Your route between near-end and remote may change, even moment by<br>
moment, as routes leave and enter the routing table or as traffic<br>
pattern shifts. [And your actual traffic, not being tiny ICMP packets,<br>
may not follow the route that an ICMP traceroute demonstrates]<br>
- The near-network or remote-network may shape your traffic. And they<br>
may do this in sophisticated ways - such as slowing reducing the<br>
priority of long-lived streams.<br>
- If the remote is multi-homed you may be communicating with a<br>
physically different location of <a href="http://example.com" target="_blank">example.com</a> at different times. [or<br>
maybe even simultaneously].<br>
- Session setup and overheard with TCP, as well as packet windowing<br>
factors, may impact performance. And various remotes may calibrate<br>
these differently. Different Operating System and versions can<br>
occasionally demonstrate surprisingly different implementations of<br>
window management and nagle.<br>
<br>
If you want to know the throughput of your connection then setup<br>
something that can monitor the interface and produce a graph - over a<br>
long period of time; this typically involves something like MRTG/RRD<br>
(which can be OpenNMS, Nagios, ZenOSS, there are many these days). If<br>
you are interested in latency then add ICMP monitoring to the solution<br>
for a few single-homed remote hosts. Then over the course of a week or<br>
so you can see how latency rises and falls [or possibly doesn't].<br>
<br>
If your near-end circuit is actually hitting a throughput ceiling you<br>
will be able to see this in the charts - provided your communication is<br>
not concentrated toward a single remote end [in which case that ceiling<br>
may be a result of something beyond your near-end throughput].<br>
<div class="im"><br>
> When I upload or download a<br>
> file of known size in a known time,<br>
> there is an average speed involved<br>
> that clearly has meaning.<br>
<br>
</div>Upload/Downloads what? from where? when? It certainly means something.<br>
Just as the trajectory of a single ejection plume in the chromosphere<br>
means "something". It is not valid grounds to criticize [or compliment]<br>
a network.<br>
<font color="#888888"><br>
<br>
<br>
--<br>
</font><div><div></div><div class="h5">This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</div></div></blockquote></div><br></div>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.