I'm not sure that is a good test either. DSL speeds should be consistent between the CO and your house, because you have a dedicated circuit. Broadband speeds can vary depending on traffic on your loop. Good broadband carriers limit the number of subscribers on a single area. (Mediaone used to limit to 300). So testing between the ISP and your home will potentially measure those variations. But, measuring inside the ISP does nothing to measure their connection to the Internet. So, I maintain that testing bandwidth between your system and one of the various bandwidth sites is a reasonable test, but will not point out problems inside of your ISP's local domain. Mediaone used to have a series of files that installers would download to test. These were inside their system. I forget the URL, but they are still used to test newly installed and problem systems.
On 18 Feb 2002 at 12:34, Benjamin Scott wrote: > On Sun, 17 Feb 2002, Jack Hodgson wrote: > > But that doesn't mean there isn't a good reason to try and measure that > > service. > > True. > > > So the (implied) original question: How DO we measure the "speed" of our > > connectivity? > > The only consistent measurement you can make is from your house to the > point before concentration -- that is, before your traffic is aggregated > with everyone else's. That requires the cooperation of your ISP, and will > likely show that the data rate of your local line is exactly what they say > it is. The problems usually lie beyond that. > > Okay, so what about inconsistent measurements? You can make periodic > measurements of your connectivity to various points on the Internet, > yielding averages which can at least indicate the general quality of service > (QoS). These measurements are likely to change over time, as the ISP adds > subscribers and/or reconfigures their network. There is also nothing to say > that the guy in the next town over will see the same QoS that you do. > However, given enough data, you can build a good overall picture. > > The hard part is collecting enough data. This is not as simple as a > utility you can run once. Nor will the data be meaningful as individual > measurements. Only after analysis of many measurements taken for many > subscribers over a long period of time will you get valid results. > > To make matters even *more* interesting, the quality of an Internet > connection involves more than simple bandwidth. Latency (delay) and > availability (packet loss; downtime) are also important. Latency is often > overlooked when looking at network performance, but it has a huge impact on > interactive applications -- and other than sucking large files for download, > most things can be classified as "interactive". > > Okay, so, if you want to actually run tests, the general methodology will > go something like this: It will involve sending various sized ICMP Echo > Request (ping) packets to various points on the Internet. By using multiple > points on the Internet, you can see the effect of routing quirks and down or > overloaded systems. By using multiple subscribers, you can see the effect > of exceptionally bad lines or host problems. By doing it over time, you can > see the effect of variations in subscriber demand. > > Looking at RTT (round trip time) for small packets will give you a good > idea of latency. Looking at route traces will give you a good idea of > routing efficiency to points on the Internet. Looking at RTT differences > for different packet sizes will allow you to extrapolate effective > bandwidth. By looking at how many packets are lost, and when, you can get > an idea of the availability of service. > > I know it would be nice if you could just look a speedometer and find out > how "fast" your Internet connection is, but such a number would be > misleading at best, if not outright wrong. > > Keep in mind this is how you would get generally useful numbers, which is > what the OP was asking for. If you have a specific application you are > interested in -- say, downloading ISO images from linuxiso.org -- that is > much easier to test. Simply go and download them, and look at your > throughput. The more specific you are willing to make your requirements, > the easier benchmarks become. Of course, that also means your benchmarks > are proportionally less useful to others. > > -- > Ben Scott <[EMAIL PROTECTED]> > | The opinions expressed in this message are those of the author and do not | > | necessarily represent the views or policy of any other person, entity or | > | organization. All information is provided without warranty of any kind. | > > > ***************************************************************** > To unsubscribe from this list, send mail to [EMAIL PROTECTED] > with the text 'unsubscribe gnhlug' in the message body. > ***************************************************************** -- Jerry Feldman Portfolio Partner Engineering 508-467-4315 http://www.testdrive.compaq.com/linux/ Compaq Computer Corp. 200 Forest Street MRO1-3/F1 Marlboro, Ma. 01752 ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
