Talk:List of device bandwidths
|
|
| Contents |
bits,bytes,kilo-,kibi-
I added a disclaimer near the top about why some numbers may appear to be off by an order of magnitude. The Ethernet numbers really screamed "ERROR!" at me before I realized that they were in BYTES, not BITS; They are ALWAYS quoted in bits, not bytes,(?) and for good reason: Ethernet is a SERIAL connection. Therefore, the number of BYTES throughput that you get depends very strongly upon the protocol used.
Let's look at modem speeds for an example. A plain 2400 bps modem without MNP4, MNP5, v.42, or v.42bis can move 2400 bits at a time. A plain 2400 bps modem WITH MNP4, MNP5, v.42, or v.42bis can still move 2400 bits at a time. We're talking about the number of bits going across the phone line, as measured by an oscilloscope or whatever.
Modem speed is measured in bits because modems transfer data across serial connections. Parallel connections such as, well, parallel connections, move data a byte at a time, therefore are measured in bytes. As soon as we try to measure modem speed in bytes, the ambiguities pile up, starting with "is that with error correction or data compresson, or is it plain, and what's the block size?" A plain 2400 modem that's not using MNP4, MNP5, v.42, or v.42bis uses 10 bits for a byte. When an error-correction protocol (MNP4 or v.42) are used, the modem starts transferring data synchronously, if I recall correctly, and the bits per byte goes down to 8, since the synchronous framing takes care of the need for the start and stop bits (there is already a CRC as part of the block overhead). That's a 25% increase in the BPS rate! When you add in data compression (MNP5 or v.42bis), things get worse.
So here's my suggestion: have two columns of figures, one in MB (megabytes) and one in Mb (megabits), with a tilde ("~") next to the appropriate value to indicate that it's an approximation, due to the bit <--> byte guesstimate. To be accurate, serial speeds should be quoted in bits and parallel data should be quoted in bytes
Scott McNay 17:29, 2004 Feb 8 (UTC)
- Sounds like the way to go to me (putting things into a table with both bits and bytes). I don't think we need to worry about being too exact, since with a lot of these devices, we're talking about theoretical bandwith, and that figure often has little to do with reality. ;) ShaneKing 06:24, 13 Feb 2004 (UTC)
- You're mixing problems here. A a normal modern byte is 8 bits. You take any number of bits and devide it by 8 and you get the equivalant number in bytes. The issue with modems without blocking is that they use 2 extra bits per byte for start/stop bits. So a 2400bps modem actually only transfers 240Bps, not 300Bps. It happens to use 10 bit bytes over the wire, so it is slower than it would otherwise seem. The solution is to measure the speed at the right place. Measuring it on the wire is interesting but not terribly useful (so 2400 doesn't mean anything), measuring it from software (like a zmodem download...) provides a useful number.
- Having two columns, one Bits and one Bytes doesn't really help, since one will always be 8 times larger than the other. Better would be to have seperate 'theoretical' and 'actual/useful' columns, where the 'theoretical' column would list 2400bps for a 2400 modem and 12mbps for usb1 and the 'actual/useful' column wouold list 240Bps and 8mbps (or whatever USB1 is after all the overhead is taken out). Audin 02:35, 22 Mar 2004 (UTC)
Another point - things should be expressed in the largest unit which they have a value larger than 1 in. For example, we have values like 0.01 MB/s, which should be 10 KB/s. Likewise for 2000 MB/s, it should be 2GB/s. There should probably be a note as to whether the decimal kilabyte (10^2), or the computer kilobyte (kibibyte? 2^10) is being used too. ShaneKing 06:30, 13 Feb 2004 (UTC)
Bandwidths are conventionally in bits/second as mentioned above, which solves ShaneKing's question about what base to use -- it's all in base 10. This is more important than first imagined because a megabit is 10^6 bits whereas a megabyte is either 10^6 bytes or 2^20 bytes depending on context. Referring to bandwidth in bits and using powers of 10 will make life easier all around. :) AndySmith 09:52, Mar 6, 2004 (UTC)
- Sorry, I should have been more clear so that didn't just look like a rewording of what ShaneKing said.. My point was that bandwidths should be discussed in bits using powers of 10 because both powers of 10 and powers of 2 are used in computing depending on context. For example, a hard disk may be measured in Gigabytes and a network interface in Gigabits. At first glance this is easy to deal with because we know that there's 8 bits in a byte. What is not so clear however is that the network interface people are using giga in base 10 (http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci213820,00.html) (i.e. 10^9), while the hard disk people are using giga in base 2 (i.e. 2^30)! Most people are conditioned to read a unit that ends in -byte as a power of 2, and when we get into the Giga- prefix range, the differences are noticeable. AndySmith 10:06, Mar 6, 2004 (UTC)
I have not heard of any bandwiths being specified in base-10 bytes, so why would we use them? If there are indeed instances of this occuring I have no problem with labeling like that, but unless somebody can point out a case where a bandwidth has used 1000 bytes/kbyte I don't see the use. I do like the idea of using some kind of scientific notation though, it makes it easier to represent the number and grasp it's magnatude in a short amount of time.
- All references to bandwidth are in base 10 (bytes do not come into it), including the encyclopedic link I gave above. A kilobit/sec is 1000 bits/sec, not 1024 bits/sec. There are plenty of references for this, for example, this whatis.com page on "megabit" (http://216.239.59.104/search?q=cache:okkMynWPHk8J:www.whatis.com/definition/0,,sid9_gci212541,00.html+megabit&hl=en&ie=UTF-8) states:
- Although the bit is a unit of the binary number system, bits in data communications are discrete signal pulses and have historically been counted using the decimal number system.
- WordNet (http://www.cogsci.princeton.edu/~wn/) also defines megabit as one million bits. Bandwidth is always measured in bits, not bytes, and indeed if you were to convert it to bytes then you must take account of transition from base 10 to base 2. AndySmith 00:59, Apr 14, 2004 (UTC)
This should be a no brainer. Bits/sec, Kb/s, Mb/s. Gb/s etc. Or do we use inches, fathoms and chains here on Wiki ? Let's stick with the metric system. Bytes/s are only relevant with parallel systems (eg. scsi) where a whole byte is transmitted at once - where they can be used provided comparison with other systems is not required.
- I agree it may be simpler to stick to only bits for bandwidth measurements, however I can also see that some people may find it easier to visualise something like "2.4Gb/sec" if it were reduced into Megabytes of data transferred per second. My point is that if we do so, then it should be pointed out that the Gb is 10^9 bits whereas the Megabyte is 2^20 bytes, not 10^6 bytes as a non-technical reader may assume. This added complexity may outweigh the advantage of translating to MB/sec in the first place. AndySmith 00:59, Apr 14, 2004 (UTC)
- Bytes are not always 8 bits, and characters are not always represented by just one byte, or 8 bits, parity bits on modems, etc. So representing the bandwidths in bits would be most accurate, and other conversions in bytes or whatever could be placed alongside it to ease understanding. And make sure that everything is labeled explicitly in the article. bits not b, bytes not B, kibi or kilo bytes, etc etc. - Omegatron 21:48, Jun 29, 2004 (UTC)
Some of these numbers are wrong
Some of these numbers, especially in the ethernet and serial sections were wrong.
The modem numbers have an interesting derivation. Before compression (introduced with 2400 baud modems), modems required at least one start and one stop bit per byte, so a 300 bps modem was 30cps due to 10 bit bytes on the wire. With compression came packetization. Bytes were transmitted as packets, with a single start and stop bit for the whole packet, giving much closer to 8 bits per byte on the wire. Compression raises this even higher, so a 28kb modem possibly could go much faster.
In the ethernet section, I think some theoretical numbers were put in that had no basis in reality. Similar to modem compression, ethernet packetizes bytes and adds start and stop bits. However, the overhead is significantly higher, with a very large number of hardware start bits and header bytes on top of that. In addition, there are manditory gaps between packets that are part of the protocol.
Fast ethernet may be able to transmit 12M/s in theory, but with protocol required start/stop bits and manditory gaps between packets, 9M/sec is more realistic, and 4M/sec more common.
I'm sure similar numbers are true for gigabit ethernet, but I have not studied it much. Typically with gigabit ethernet, the packet size is increased by two orders of magnitude to drastically reduce overhead.
When you say bandwidth on this page are you referring to bidirectional or unidirectional bandwidth? This is important when referring to specifications such as PCI Express since its physical interface has dedicated directional links (i.e. the page states 500MBps, however a PCI Express x1 link can only support a peak bandwidth of 250MBps in one direction).
- RS-232-C says it applied up to data rates of 20,000 bits per second. RS 422 says its applicable to 10 MB/s. While some "RS-232" compatible interfaces may be settable to 230 kB/s ( I thought the top end on a PC serial card was only 115 kB/s? ), can someone tell me if that data rate is covered by the latest revision of RS 232-C? My interest in serial communications is not deep enough to shell out $65 US for the latest edition of the standard, though it may be worth a trip to the library. --Wtshymanski 14:42, 18 Apr 2005 (UTC)
The table should use BITS, not BYTEs, for comparison purposes
There are several good reasons to change this table to use BITS as the unit of comparison.
- First, because bits are the canonical units of information, as used in Information Theory.
- Bytes do not exist in Information Theory, they're only useful constructions. Some theorics still use today the term "octects" to stress the fact that bytes do not exist, in scientific terms.
- Bits are also the greatest common denominator for device speeds, and as such, it should be the official measurement speed.
I'm willing to change the table, including more columns to help to clarify this and other obscure points. If someone don't like the idea, or wants to discuss it further, please leave your comments here.
CarlosRibeiro 12:37, 2 Aug 2004 (UTC)
I agree. While I don't know if there's any real agreed-upon standard, it seems that transfer rates are more often quoted in bits (if nothing else, to make the rates seem larger in advertising :-) Bytes are something of a higher-level construction on top of the bit. I think you should go ahead and change it. -- Wapcaplet 03:42, 15 Aug 2004 (UTC)
and how much is MB? :)
According to standards, 1024*1024 bytes is named MebiByte (MiB). You should count bytes in KibiBytes, MebiBytes, etc. and bits in Kilobits (*1000), Megabits, and so on..
and I vote for bytes. All I'm intereseted is how fast my MP3's will transfer ;)
Is there a standard saying bytes should necessarily be counted using the IEC prefix? As I understand it, transmission rates are almost universally measured in powers of ten (SI prefix "mega", "kilo", etc.) Applying the Google test to see whether bits or bytes should be used for transmission speeds:
- ~100 for "megabyte ethernet (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22megabyte+ethernet%22&btnG=Search)" versus ~5000 for "megabit ethernet (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22megabit+ethernet%22&btnG=Search)"
- ~3000 for "gigabyte ethernet (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22gigabyte+ethernet%22&btnG=Search)" versus ~1,000,000 "gigabit ethernet (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22gigabit+ethernet%22&btnG=Search)"
- ~16,000 for "kilobytes per second (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22kilobytes+per+second%22&btnG=Search)" versus ~67,000 for "kilobits per second (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22kilobits+per+second%22&btnG=Search)"
- ~31,000 for "megabytes per second (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22megabytes+per+second%22&btnG=Search)" versus ~100,000 for "megabits per second (http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=%22megabits+per+second%22&btnG=Search)"
Of course, this is not a final judgement; just an indicator of common usage. -- Wapcaplet 18:33, 18 Aug 2004 (UTC)
From a telecomms professional
...but a Wiki newbie.
Telecommunications circuits (modems, DS1s, Frame Relay, ADSL) are never measured or stated as providing throughputs of so many (kilo/Mega/Giga) bytes /sec (unless in marketing documentation). All circuits are specified as (kilo/Mega/Giga) bits/sec, where kilo = 10^3, Mega=10^6, Giga=10^9. that's how the engineers who build these circuits define them.
It could well be that memory bandwidth of memory interconnects are stated as so many (kilo/Mega/Giga) bytes/sec as these buses are parallel and are capable of transferring a byte at a time, rather than being bit-serial devices. Note, however, that USB and IEEE1394 are bit serial connectors and should, therefore, be defined in bits/sec.
I agree with those that say the table needs recasting. I would recommend that it shows both bits/s and bytes/s, with the term used by engineers familiar with the technology bolded.
It may be useful to have a link to a page showing the difference between kilo- and kibi-bytes and why the distinction needs to be made.
West London Dweller
Clarified ethernet terms...
I changed "thin ethernet" to just Ethernet, since thin/thick/TP ethernet is all nominal 10 Mb/s. Likewise, I put the more standard 10/100/1000base-X terminology in parens...having done that, let me add my voice to the chorus suggesting that expressing all units in bits, not bytes, per sec. In my experience bytes/sec is used only for parallel channels (scsi and other disk i/o comes to mind). Sharkford 17:55, 2004 Sep 9 (UTC)
Added kbit/s column
Well, I finally did it, and added the kbit/s column. I'm not sure that the ethernet bandwidths are correct, but this edit was mainly for format rather than correctness (!).
I've also modified the text as these are not actually device bandwidths, but actually connection bandwidths, and I think the title of the article should actually say that. Being a relative Wiki newbie, I don't know how to change that, and think it needs some discussion and agreement anyway.
If I've done an unpardonable Wiki sin, then please roll back to the previous text.
WLD 00:12, 10 Sep 2004 (UTC)
Ethernet, checking and formating
I've added ARCNET, Token Ring and FDDI to the LAN protocols.
I modified the bandwidths for Ethernet as I beleive the table should show that bit-rate for each technology, and discussions about actual effective throughput should be moved elsewhere - perhaps to my unfinished page on Measuring Data Throughput, where I've started on the detail of overheads etc. Beware of flame wars over the actaul effective throughputs of Token Ring and Ethernet
I've checked and modified some of the bandwidths, but in some cases I would need to go to the primary sources of the IEEE/OSI documents to make absolutely sure that the numbers are correct. Unfortunately, the OSI standards documents are not gratis, and I don't have copies. Unless I have the actual standard in front of me, I'm not going to document numbers as being definitely correct.
Thanks to ?Bobblewick for justifying the numbers. I have one small request/suggestion 'though - could the actual names of the connection technologies be left justified? I think it would lokk better that way, but I don't want ot get into an edit war, or be going against Wiki style.
WLD 18:02, 10 Sep 2004 (UTC)
Internal & External buses
Should we split up the Computer Interfaces section into two:
- One for interfaces/buses that are usually external (serial, SCSI, USB, IEEE 1394);
- One for interfaces/buses that are usually internal (AT, PCI etc)?
--WLD 22:14, 23 Nov 2004 (UTC)
Why ? And which category would you use for interfaces/buses that are commonly used internally and externally, such as SCSI and Serial ATA and I2C ? -- DavidCary 02:21, 13 Jan 2005 (UTC)
- Why? Well, it seemed a useful distinction to make for those not particularly familiar with the technlogies. And there's certainly a room for a third category of interfaces/buses that are used for both. Just trying to make the article more useful. WLD 17:07, 21 Jan 2005 (UTC)
Protocol overhead
I think for busses that use something like the 8B/10B encoding (eg PCI Express, Infiniband, Fibre Channel), we should use the BITS column to express the number of bits transferred per second and the BYTES column to express the number of bytes transferred. Then the values would be a factor of 10 different, not a factor of 8. I accept that this is a bit unfair as we don't discount protocol overhead for other systems (eg Ethernet framing), but there's other protocol overhead in 8B/10B systems that isn't taken into account too. MatthewWilcox 02:47, 24 Nov 2004 (UTC)
- You've got an interesting point there. The problem I see with it is that overheads are so variable - even on a simple technology like asynchronous serial. I've started an article called Measuring data throughput that is getting quite large, but only skims the surface of the topic - I've had to do a lot of it in my time.
- I think that the best approach would be to provide a link to a page for each technology describing the overheads and giving typical examples - but that is a lot of work. FDDI has the same issue as you raise, with the difference between the bit-rate and symbol rate, as do many other technologies.
- Could I suggest that perhaps we should add an asterisk or dagger or something pointing to some text that says pretty much what you've said above.
- Thank-you for your thoughts. WLD 22:30, 24 Nov 2004 (UTC)
- I agree that overhead should probably be taken into account, somehow. The bandwidth page defines bandwidth as "the amount of data that can be transferred through a digital connection in a given time period". To say, for example, that USB2 has a bandwidth of "480 Mbit/s" is simply not true: even with perfect cabling, infinitely fast CPUs, and so forth, there's no way the USB 2.0 protocol can transfer 480 million bits across the wire in one second -- the frame sizes simply don't allow it.
- Sweeping it under the rug of "theoretical" doesn't sit well with me. This "theory" seems to simply assume 1 cycle = 1 bit. (By that logic, SCSI and Wide SCSI have exactly the same bandwidth!)
- Ideally, I'd like to see 3 columns: Advertised Bandwidth, Maximum Throughput, and Minimum Latency. Of course, I don't know enough about the protocols to compute these values for anything but USB. (Are there be people who'd help do this?)
- While it's interesting to see how fast they cycle the wire, it's not the most helpful information. As somebody else here noted, most people really just want to know "How fast will it transfer my data?", which is something the table doesn't really answer accurately now.
- (P.S. This is a really neat table! Thanks to all who made it. I don't want to sound all grouchy, because I'm not, I'm happy. :-)
- Hi 4.16.250.33 - can I suggest you create an account, then follow convention and 'sign' your contributions onthe talk page? I agree that the rate of 'cycling the wire' is not the best comparison, but it's better than nothing. Defining the maximum throughput on some of the technologies would produce some contentious arguements - however, it would be great to capture your knowledge, either here (possible as a footnote to the USB entry), or in the main USB article - your contribution (even as an IP address) would be welcomed. WLD 09:03, 18 Feb 2005 (UTC)
"symbol rate" column
I'm thinking about adding a "symbol rate" column.
Some interfaces have bit rates *less* than the symbol rate:
- a 300 baud modem has a maximum data rate of 300 symbols/s * (8 data bits / 10 symbols) = 240 data bits per second, because it takes 10 binary symbols to transmit 8 data bits ( 8B/10B encoding ? )
- GPS runs at 1.023 Msymbols/s (the symbols are called "chips" in spread spectrum jargon) -- a much higher rate than the 300 baud modem. It has a navigational data rate of 50 data bits per second, far slower than a 300 baud modem.
- 100BASE-TX Ethernet is 125 Msymbols/s. But because it uses 4B/5B code, the maximum data rate is 125 M symbols/s * (4 data bits /5 symbols) = 100 data bits per second. ( MLT-3 Encoding has no effect on the bit rate ).
Other interfaces have bit rates *more* than the symbol rate (this requires amplitude modulation and/or parallel signal paths):
- Gigabit Ethernet (1000BaseT) is also 125 Msymbols/s. But because it uses PAM-5 modulation, the maximum data rate per pair 125 M symbols/s * (2 data bits / symbol) = 250 M data bits/s per pair. (Then it uses 4 pairs of wire in parallel to get 1000 Gigabits of data per second).
(see http://www1.us.dell.com/content/topics/global.aspx/power/en/ps4q01_patward?c=us&l=en&s=gen )
I hesistate, however, to label the symbol rate column with the technically correct name "baud rate", because historically it has caused a lot of confusion.
But an encyclopedia is exactly the right place to fix this confusion.
I know that historically modems have used the term "start bit" and "stop bit" ... but shouldn't they be "symbols" if we use modern terminology ?
-- DavidCary 02:21, 13 Jan 2005 (UTC)
- Be bold, and add it, preferably with links to articles explaining what the symbold rates are, and the differing encodings. WLD 17:09, 21 Jan 2005 (UTC)
DSL
I added DSL as 64 mbps since VDSL talks about a "theoretical limit" of 52 Mbit/s downstream and 12 Mbit/s upstream. Since the downstream and upstream share of the line can be configured at will, the line capacity is 64 mbps within 500 meters, perhaps? - Jerryseinfeld 02:19, 4 Dec 2004 (UTC)
- If the limit is 52 Mbit/s, then surely it can't carry more than 52 Mbit/s? If you mean 52 Mbit/s at a particular range from the CO, then that range should be stated, as it is not unusual for the possible bandwidth to be higher at ranges closr to the CO. Note that one should not sum the upstream and downstream capacities. If the technology is asymmetric, the upstream and downstream rates should be listed seperately. WLD 09:27, 4 Dec 2004 (UTC)
- I believe "the downstream and upstream share of the line can be configured at will". - Jerryseinfeld 21:49, 23 Dec 2004 (UTC)
ADSL
To 203.122.223.50 : can you justify increasing the upper limit for the ADSL upstream bandwidth, and also the limits for the lowest downstream bandwidth and greatest downstream limit?
There are places selling 128 kbit/s downstream and 64 kbit/s upstream ADSL (just Google for them), and as far as I understand the technology, the actual upstream granularity is 32 kbit/s - in other words, it would be possible to have a 32 kbit/s upstream limit - but I'm not aware of anywhere selling it. WLD 16:51, 5 Dec 2004 (UTC)
USB
I got pointed here from discussion on the USB Talk page. I corrected the naming conventions for USB by removing references to version numbers (which were wrong anyway, 1.0 is not low speed, and a 2.0 device can be a low speed device). SchmuckyTheCat 19:52, 9 Mar 2005 (UTC)
Move to Orders of magnitude (bandwidth)
Hi folks. I stumbled across this article, and had a spare afternoon, so I've reformated the table to fit in with orders of magnitude. I wrote a perl script to to the conversion, so it (or I) may have messed up some values (which is why its here on the talk page). I read the bits/bytes discussion above, and so the table is based in bits per second, with the bytes per second conversion from the old table.
This is part of a plan to move the article to [[Orders of Magnitude (bandwith)]], and add it to the orders of magnitude template. Osric 01:24, 14 Mar 2005 (UTC)
- Osric - rather than MOVE the aticle, can I suggest you make a re-formatted COPY with the title you suggest. People will stumble across this table when looking for throughput/bandwidth of various technologies, rather than wondering what technology operates at some specific bandwidth, if you see what I mean. Regards WLD 13:06, 14 Mar 2005 (UTC)
- could that not be handled by redirect? copying the same information across articles means one ends up stale. SchmuckyTheCat 21:11, 14 Mar 2005 (UTC)
- but on second thought, I don't like that table at all and wouldn't support a move. SchmuckyTheCat 21:17, 14 Mar 2005 (UTC)
New table
{{orders of magnitude}}
| Decade of bandwidth | Bandwith using SI prefixes | bit/s | bytes/s | Examples |
|---|---|---|---|---|
| 101 bits/s | ||||
| 102 bits/s | 3.0 × 102 bit/s | (30.0 byte/s) | Modem 300 baud | |
| 103 bits/s | 1 kbits/s | 1.2 × 103 bit/s | (120.0 byte/s) | Modem 1200 |
| 2.4 × 103 bit/s | (240.0 byte/s) | Modem 2400 | ||
| 8.0 × 103 bit/s | (1.0 Kbyte/s) | Frame Relay | ||
| 9.6 × 103 bit/s | (960.0 byte/s) | Modem 9600 | ||
| 9.6 × 103 bit/s | (960.0 byte/s) | Serial (RS-232, RS-422, etc) commonly | ||
| 104 bits/s | 1.4 × 104 bit/s | (1.4 Kbyte/s) | Modem 14.4k | |
| 2.9 × 104 bit/s | (2.9 Kbyte/s) | Modem 28.8k | ||
| 5.3 × 104 bit/s | (5.3 Kbyte/s) | Modem 56k* | ||
| 6.4 × 104 bit/s | (8.0 Kbyte/s) | ADSL upstream (slow) | ||
| 6.4 × 104 bit/s | (8.0 Kbyte/s) | SDSL (slow) | ||
| 6.4 × 104 bit/s | (8.0 Kbyte/s) | DS0 | ||
| 7.2 × 104 bit/s | (9.0 Kbyte/s) | IrDA-Control | ||
| 105 bits/s | 2.3 × 105 bit/s | (28.8 Kbyte/s) | LocalTalk | |
| 2.3 × 105 bit/s | (23.0 Kbyte/s) | Serial (RS-232, RS-422, etc) max | ||
| 2.6 × 105 bit/s | (32.0 Kbyte/s) | ADSL downstream (slow) | ||
| 10.0 × 105 bit/s | (125.0 Kbyte/s) | Bluetooth 1.1 | ||
| 106 bits/s | 1 mbits/s | 1.0 × 106 bit/s | (128.0 Kbyte/s) | ADSL upstream (fast) |
| 1.5 × 106 bit/s | (192.0 Kbyte/s) | USB Low Speed | ||
| 1.5 × 106 bit/s | (192.5 Kbyte/s) | DS1/T1 | ||
| 2.0 × 106 bit/s | (250.0 Kbyte/s) | 802.11 legacy 0.125 | ||
| 2.0 × 106 bit/s | (256.0 Kbyte/s) | E1 | ||
| 2.3 × 106 bit/s | (287.5 Kbyte/s) | G.SHDSL | ||
| 2.5 × 106 bit/s | (312.5 Kbyte/s) | ARCNET (Standard) | ||
| 3.0 × 106 bit/s | (375.0 Kbyte/s) | Bluetooth 2 | ||
| 4.2 × 106 bit/s | (520.0 Kbyte/s) | Token Ring (Original) | ||
| 4.6 × 106 bit/s | (576.0 Kbyte/s) | SDSL (fast) | ||
| 8.0 × 106 bit/s | (1.0 Mbyte/s) | Parallel (Centronics) | ||
| 8.0 × 106 bit/s | (1.0 Mbyte/s) | ADSL downstream (fast) | ||
| 107 bits/s | 1.0 × 107 bit/s | (1.2 Mbyte/s) | Ethernet (10base-X) | |
| 1.1 × 107 bit/s | (1.4 Mbyte/s) | 802.11b DSSS 0.125 | ||
| 1.2 × 107 bit/s | (1.5 Mbyte/s) | USB Full Speed | ||
| 1.2 × 107 bit/s | (1.5 Mbyte/s) | SCSI 1 | ||
| 1.2 × 107 bit/s | (1.5 Mbyte/s) | VDSL (upstream) | ||
| 1.6 × 107 bit/s | (2.0 Mbyte/s) | Token Ring (Later) | ||
| 3.4 × 107 bit/s | (4.3 Mbyte/s) | E3 | ||
| 4.4 × 107 bit/s | (5.5 Mbyte/s) | 802.11b+ non-standard DSSS 0.125 | ||
| 4.5 × 107 bit/s | (5.6 Mbyte/s) | DS3/T3 ('45 Meg') | ||
| 5.2 × 107 bit/s | (6.5 Mbyte/s) | OC1 | ||
| 5.2 × 107 bit/s | (6.5 Mbyte/s) | VDSL (downstream) | ||
| 5.4 × 107 bit/s | (6.8 Mbyte/s) | 802.11g DSSS 0.125 | ||
| 5.4 × 107 bit/s | (6.8 Mbyte/s) | 802.11a 0.75 | ||
| 8.0 × 107 bit/s | (10.0 Mbyte/s) | Fast SCSI 2 | ||
| 8.0 × 107 bit/s | (10.0 Mbyte/s) | typical Hard disk average transfer rate | ||
| 108 bits/s | 1.0 × 108 bit/s | (12.5 Mbyte/s) | FDDI | |
| 1.0 × 108 bit/s | (12.5 Mbyte/s) | Fast Ethernet (100base-X) | ||
| 1.6 × 108 bit/s | (19.4 Mbyte/s) | OC3 | ||
| 1.6 × 108 bit/s | (20.0 Mbyte/s) | Fast Wide SCSI 2 | ||
| 2.6 × 108 bit/s | (33.0 Mbyte/s) | Ultra DMA ATA 33 | ||
| 3.2 × 108 bit/s | (40.0 Mbyte/s) | Ultra Wide SCSI 40 | ||
| 4.0 × 108 bit/s | (50.0 Mbyte/s) | FireWire (IEEE 1394) 50 | ||
| 4.8 × 108 bit/s | (60.0 Mbyte/s) | USB Hi-Speed | ||
| 5.3 × 108 bit/s | (66.0 Mbyte/s) | Ultra DMA ATA 66 | ||
| 6.2 × 108 bit/s | (77.8 Mbyte/s) | OC12 | ||
| 6.4 × 108 bit/s | (80.0 Mbyte/s) | Ultra2 SCSI 80 | ||
| 8.0 × 108 bit/s | (100.0 Mbyte/s) | Ultra DMA ATA 100 | ||
| 8.0 × 108 bit/s | (100.0 Mbyte/s) | Fibre Channel | ||
| 8.0 × 108 bit/s | (100.0 Mbyte/s) | FireWire (IEEE 1394b) | ||
| 10.0 × 108 bit/s | (125.0 Mbyte/s) | Gigabit Ethernet (1000base-X) | ||
| 109 bits/s | 1 gbits/s | 1.1 × 109 bit/s | (133.0 Mbyte/s) | Ultra DMA ATA 133 |
| 1.1 × 109 bit/s | (133.0 Mbyte/s) | PCI 32/33 | ||
| 1.2 × 109 bit/s | (150.0 Mbyte/s) | Serial ATA | ||
| 1.3 × 109 bit/s | (160.0 Mbyte/s) | Ultra 160 SCSI | ||
| 2.1 × 109 bit/s | (266.0 Mbyte/s) | AGP 1x | ||
| 2.4 × 109 bit/s | (300.0 Mbyte/s) | Serial ATA (SATA300) | ||
| 2.4 × 109 bit/s | (306.0 Mbyte/s) | OC48 | ||
| 2.6 × 109 bit/s | (320.0 Mbyte/s) | Ultra 320 SCSI | ||
| 4.0 × 109 bit/s | (500.0 Mbyte/s) | PCI Express (x1 link) | ||
| 4.3 × 109 bit/s | (532.0 Mbyte/s) | AGP 2x | ||
| 4.3 × 109 bit/s | (533.0 Mbyte/s) | PCI 64/66 | ||
| 4.3 × 109 bit/s | (533.0 Mbyte/s) | PC66 SDRAM | ||
| 5.1 × 109 bit/s | (640.0 Mbyte/s) | Ultra640 Scsi | ||
| 6.4 × 109 bit/s | (800.0 Mbyte/s) | PC100 SDRAM | ||
| 8.5 × 109 bit/s | (1.1 Gbyte/s) | AGP 4x | ||
| 8.5 × 109 bit/s | (1.1 Gbyte/s) | PCI-X 133 | ||
| 8.5 × 109 bit/s | (1.1 Gbyte/s) | PC133 SDRAM | ||
| 1010 bits/s | 1.0 × 1010 bit/s | (1.2 Gbyte/s) | InfiniBand | |
| 1.0 × 1010 bit/s | (1.2 Gbyte/s) | OC192 | ||
| 1.0 × 1010 bit/s | (1.3 Gbyte/s) | 10 Gigabit Ethernet | ||
| 1.3 × 1010 bit/s | (1.6 Gbyte/s) | PC800 RDRAM (single-channel) | ||
| 1.3 × 1010 bit/s | (1.6 Gbyte/s) | PC1600 DDR-SDRAM | ||
| 1.3 × 1010 bit/s | (1.7 Gbyte/s) | OC255 | ||
| 1.6 × 1010 bit/s | (2.0 Gbyte/s) | PCI Express (x4 link) | ||
| 1.7 × 1010 bit/s | (2.1 Gbyte/s) | PC1066 RDRAM (single-channel) | ||
| 1.7 × 1010 bit/s | (2.1 Gbyte/s) | PC2100 DDR-SDRAM | ||
| 1.8 × 1010 bit/s | (2.1 Gbyte/s) | AGP 8x | ||
| 1.8 × 1010 bit/s | (2.1 Gbyte/s) | PCI-X DDR | ||
| 1.9 × 1010 bit/s | (2.4 Gbyte/s) | PC1200 RDRAM (single-channel) | ||
| 2.2 × 1010 bit/s | (2.7 Gbyte/s) | PC2700 DDR-SDRAM | ||
| 2.6 × 1010 bit/s | (3.2 Gbyte/s) | PC800 RDRAM (dual-channel) | ||
| 2.6 × 1010 bit/s | (3.2 Gbyte/s) | PC3200 DDR-SDRAM | ||
| 3.4 × 1010 bit/s | (4.2 Gbyte/s) | PC1066 RDRAM (dual-channel) | ||
| 3.8 × 1010 bit/s | (4.8 Gbyte/s) | PC1200 RDRAM (dual-channel) | ||
| 4.0 × 1010 bit/s | (5.0 Gbyte/s) | OC768 | ||
| 5.1 × 1010 bit/s | (6.4 Gbyte/s) | HyperTransport (800MHz, 16-pair) | ||
| 6.4 × 1010 bit/s | (8.0 Gbyte/s) | PCI Express (x16 link) | ||
| 1011 bits/s |
Sneaker-nets
Should somebody add the bandwidth for cars filled with backup tapes , walking with floppy disks , etc ? --2mcm 22:52, 4 Apr 2005 (UTC)
- that sounds about as useful as listing the bandwidth of RFC 1149, so No. SchmuckyTheCat 00:16, 5 Apr 2005 (UTC)
- Never underestimate the bandwidth of a station wagon filled with mag tapes is a proverb from the Jargon File. But seriously, some ballpark comparisions to non-computer examples such as a fast typist, a dialy newspaper, the data sent by a TV channel per second, etc. might make the torrent of numbers more appealing to the non-computer-professional. --Wtshymanski 04:30, 11 Apr 2005 (UTC)
- If I remember correctly, the quote was from Andrew Tanenbaum, who said Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. grendel|khan 18:09, 2005 Apr 18 (UTC)
- Maybe a stub (that would later be expanded) could be made for these other numbers ? "List of bandwidths for unusual devices"? Just an idea. --2mcm 03:58, 20 Apr 2005 (UTC)
- Never underestimate the bandwidth of a station wagon filled with mag tapes is a proverb from the Jargon File. But seriously, some ballpark comparisions to non-computer examples such as a fast typist, a dialy newspaper, the data sent by a TV channel per second, etc. might make the torrent of numbers more appealing to the non-computer-professional. --Wtshymanski 04:30, 11 Apr 2005 (UTC)