dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
45
rradina
join:2000-08-08
Chesterfield, MO

rradina to Rekrul

Member

to Rekrul

Re: Not much increase here...

The measurements may or may not refer to the same thing. There are 8-bits to a byte and on the surface, simple math converts between two expressions. (A KB is 1,024 8-bit bytes per second. A MB is 1,048,576 8-bit bytes per second.)

However, you can only convert between the two with confidence if you understand what's being measured. Browsers and P2P programs are likely reporting "user data" transferred, not raw data transferred. Depending on the application protocol, there may be application-level overhead that reduces the quantity of "user data" transferred because a portion of the data is used by the application to control the transfer. I'm calling it "user data" because application protocols may encode source data in such a manner as to inflate its size. For instance, e-mail attachments and XML documents often use Base64 or MIME encoding to represent binary data. This can add up to 30% to the size of the data that needs to be transferred. If you have a 10Mbps connection that sends MIME data at full speed, 30% of the transfer speed could be used by the application's encoding. This reduces the effective transfer rate. That is, 10Mbps of data is being transferred but if 30% of it is used by the application to recreate the source data, the "user data transfer speed" (i.e. KB/sec or MB/sec) is significantly less than the raw transfer speed.

If you want to read why MIME/Base64 encoding is used, see this Wikipedia primer:

»en.wikipedia.org/wiki/MIME

If you've wrapped your head around that, it's gets even muddier but the concepts are the same. Below the top-level application protocol is the network protocol. Commonly, TCP/IP is used which divides the data into packets and each packet contains a header. The header contains source and destination IP addresses, source and destination ports, packet sequence number, checksum and other "control data". This is underneath or below the MIME application encoding above and it also reduces the size of the "user data" that can be transferred.
Rekrul
join:2007-04-21
Milford, CT

Rekrul

Member

said by rradina:

Browsers and P2P programs are likely reporting "user data" transferred, not raw data transferred. Depending on the application protocol, there may be application-level overhead that reduces the quantity of "user data" transferred because a portion of the data is used by the application to control the transfer.

I understand what you're saying, but in most cases, the speed reported by my client software is higher, often significantly, than the speed reported by speed tests. The Speakeasy test is still showing me 15-20mbps, even though I just got done downloading a file that peaked at 4.2MB/s and was around 3MB/s for much of the transfer.

Personally, I'd rather have the ISP tell me that I can expect speeds of 2-4MB/s rather than saying I'll be getting 20-30mbps.
rradina
join:2000-08-08
Chesterfield, MO

rradina

Member

The difference you see could be related to the SpeedTest site vs. the download site. Your ISP could have a better route to the download site vs. the SpeedTest site. Try using a different SpeedTest site -- even if it's a bit further away -- to see if the results are more consistent.

Regarding getting ISPs to rate their service by MB/second...good luck with that. Marketing types love higher numbers when branding products. Remember when the Ghz barrier in processor speeds was hit? Before that, the newness of the processor was always closely associated with it's clock speed. Now it's core count + clock speed. The same thing happened with cordless phones. We went from 900 Mhz to 2.4Ghz to 5Ghz but suddenly we started seeing DECT 6.1 models (Implying 6.1Ghz but it was really using something like 1.7Ghz). 6.1 was used because it's been beat into our head that new stuff has "higher" model numbers.
Rekrul
join:2007-04-21
Milford, CT

Rekrul

Member

said by rradina:

The difference you see could be related to the SpeedTest site vs. the download site. Your ISP could have a better route to the download site vs. the SpeedTest site. Try using a different SpeedTest site -- even if it's a bit further away -- to see if the results are more consistent.

Typically, the further away the test site is, the worse the speed.
rradina
join:2000-08-08
Chesterfield, MO

rradina

Member

True but as always, it depends. Even large markets with multiple premier backbone providers can have interesting routes. If two backbone providers don't share traffic until they get to a major hub (i.e. Chicago, NYC, WDC, etc.), a speedtest site in your hometown may require packets to leave town, go hundreds of miles away, cross over and return hundreds of miles. When this happens, it's far better to choose the speed test site at the major hub than the site next door.

As an example, the speed test site in St. Louis (where I am) stinks. It's better for me to use sites in Chicago, Dallas or Kansas City because Charter has direct routes to those cities. However, the local speed test site has traffic going to Chicago and back. (Download something like Ping Plotter and watch where the packets travel.)

Speed test sites are also not created equal. I've tried to use the speed test site in St. Louis from a lot of provider networks in town and I've never had great results.