Broadband speeds.

D

demoivre

Guest
I have UTV clicksilver broadband which is advertised as having a contention ratio of 48:1 and a speed of 512 kbps.

Using the following test

us.mcafee.com/root/speedo...efault.asp

the speed of download has never been above 420 kbps and this is based on numerous tests at different times of the day.
I'd be interested to know about actual download speeds from other providers such as Eircom or Esat BT or indeed the speeds achieved by other UTV clicksilver users.
 
512Kbps is the nominal, raw and often theoretical throughput. You will often never get near it due to things like bandwidth sharing (contenion ratio), frame collisions/retries, protocol overhead, latencies etc. Conversely depending on how the stats are reported and whether or not your modem gear supports compression you may in fact achieve above the nominal throughput rating for any connection if you are transferring highly compressible data (e.g. text, HTML pages etc.). 420Kbps on a nominal 512Kbps connection is not unreasonable in general in my experience.
 
speed

I have the 1.5 megabit line from NTL (brag brag) and get a speed test result of 1300kb regularly. When I was on the 512 line I was actually receiving readings of over 550. I believe Cable Internet is more reliable than telephone line internet? If youre in an NTL broadband enabled area it cannot be beaten. (EUR50 for the 1.5 line)
 
Re: speed

Yay NTL. Getting it installed on Monday. Getting first 3 months free during which I've opted for the 1.5Mbps service. I can then move back down to the 750kbps service thereafter.
 
Re: speed

I remember seeing somewhere (long, long ago) that taking the various transmission protocol overheads into account you should expect (on average) on a WAN link to need 9.5 bits for every 8 bits of data.

In other words, in order to get 8 bits data you need 1.5 bits overhead. I know there's no such thing as half a bit - I am talking about an average amount when spread over a larger data flow.

I have invariably found this figure to be accurate from observation - take the theoretical speed, divide by 9.5, multiply by 8 and you should get something near what you observe on the line. In this case it works out as 431K which is not a million miles off what you see.

z
 
Re: speed

I remember seeing somewhere (long, long ago) that taking the various transmission protocol overheads into account you should expect (on average) on a WAN link to need 9.5 bits for every 8 bits of data.

That sort of rule of thumb would have applied to serial communications, for example, directly between two PCs or from a PC to a modem etc. In this case you "lose" some bandwidth for framing overhead etc. (e.g. start bits, stop bits, parity bits etc.). However this does not simple mean that a 56Kbps dial-up connection will generally max out at 47.6Kbps because there are other technologies that come into play (e.g. modem compression etc.).

The same general principle applies to most protocols in that not all of the bandwidth is actually used to transmit data all of the time due to the need for header fields, retries, collision detection/avoidance etc. As I mentioned earlier, where intermediate devices (e.g. modems, switches etc.) do compression you may actually get higher speeds than the nominal rated throughput because the data is compressed before transmission.

Basically there is no generally applicable rule of thumb for all protocols and environments. I'm not sure what the average empirical protocol overhead might be but the "9.5 bits for every 8 bits of data" idea doesn't really make much sense in the context of ethernet, 802.11 etc. even if the bandwidth "loss" due to protocol overhead etc. does happen to be around 15% (8 / 9.5 * 100).

I believe Cable Internet is more reliable than telephone line internet?

Reliable in what way precisely? As far as I know, one characteristic of cable networks compared to telecom networks is that the former often suffers from higher latencies (i.e. delays in dispatching packets/frames).
 
cable v dsl

Clubman, I don't mind telling you that what you are talking about is way over my simple head! That's why I had a question mark after my statement - someone just told me that cable was more reliable - though I have a friend with Eircom broadband 512 service and his speeds fluctuate on a daily basis (250 - 440) whereas with my NTL the speed is pratically constant since the day I got it a few months ago. Could the distance he is from the hub be a factor or does he just have a crap line? Not withstanding the issue of cable versus dsl (asdl?) the download limit of 1 gig a day with NTL beats the limits set by the telecoms by a massive margin.
 
Re: cable v dsl

Clubman - I didn't say there was one generally applicable rule of thumb for all protocols.

I was referring to WAN links specifically, and I still stand my rule of thumb for WAN links.

Try it yourself on a few different WAN links and see if you ever get significantly better throughput rates than the 8:9.5 I suggested.

z

p.s. in this sentence - " I'm not sure what the average empirical protocol overhead might be but the "9.5 bits for every 8 bits of data" idea doesn't really make much sense in the context of ethernet, 802.11 etc. even if the bandwidth "loss" due to protocol overhead etc. does happen to be around 15% (8 / 9.5 * 100)." - are you saying that even if the 9.5 for 8 bits idea is right in practice it's not right ? That's what it looks like to me.

p.p.s I didn't run podges figures through the calculator initially, but what do you reckon you get if you divide 1.5m by 9.5 and multiply by 8 ? Something near 1.3m maybe ?
 
Re: cable v dsl

In answer to demoivres original query - I am on eircom 512k download and I just got 432.64. So, no significant difference there.

Ooh, ooh, let me work out what 512/9.5*8 is . . .

z
 
Re: cable v dsl

Clubman - I didn't say there was one generally applicable rule of thumb for all protocols.

I didn't say that you did. I was just trying to give some more insight into the tehnicalities behind the issues that you and others were talking about. Given your smart arsedness I don't really know why I bothered... :rolleyes

I was referring to WAN links specifically, and I still stand my rule of thumb for WAN links.

I stand by my assertion that 9.5 bits for 8 bits of data is technically meaningless in the context of network links in general (not sure what specifically you mean by WAN links) even if the figures happen to work out at a c. 15% protocol overhead "loss" in the general case. 9.5 bits (or more) for 8 bits of data does make sense in the context of a simple serial line data transfer (e.g. due to the start/stop/parity bits overhead for each octet of data transferred). Otherwise the protocol overhead is protocol specific (e.g. ethernet header and frame checksum overhead per frame of up to c. 2KB of data) and then the bandwidth loss is further related to the number of retries, collisions, control frames (ACKs) etc.
 
Re: cable v dsl

It may be technically meaningless, but real world observation has shown it to be a relatively good guide for achievable download. I'm not going for the technical explanation, just for the observation based one.

I agree that the protocol overhead is protocol specific and will vary according to the protocols used.

Does anyone else want to try the speed test above (as per the original request) and report back on their results ?

z
 
Try a site that is [broken link removed]. Or if your desire is to test the speed of the 'net backbone (inconclusive at best), choose your poison.<!--EZCODE BR START--><!--EZCODE BR END--><!--EZCODE BR START--><!--EZCODE BR END-->435.8 Kbps or 53.4 K bytes/sec over EsatBT.<!--EZCODE BR START--><!--EZCODE BR END--><!--EZCODE BR START--><!--EZCODE BR END-->YMMV
 
According to the DSL Reports website a general rule of thumb on DSL is that if you are getting 80% of the nominal rated throughput (e.g. c. 410Kbps download on a 512Kbps downstream rated connection) then you are probably getting the best performance out of it. Note that the rule of thumb for other broadband connections (e.g. wireless, satellite, cable etc.) may differ. Note that "real world" performance is ultimately controlled/determined by the underlying technology and its characteristics so to understand the former it's necessary to understand the latter.
 
Nice set of links, Max Hopper...just added to my favourites
 
Back
Top