Talk:List of interface bit rates/Archive 1

Archive 1

Archive 2

Archive 3

Archive 4

Please add new topics to the bottom of the page. —Preceding unsigned comment added by Theaveng (talk • contribs) 16:53, 3 December 2007 (UTC)

Wireless split up?

Hi. Why are we splitting up different types of wireless? Would be nice if they were together so people could compare. I find the existing splits kind of arbitrary, given that uses can change (e.g. 802.11 being used for neighborhood mesh networks) --Treekids (talk) 22:03, 7 January 2008 (UTC)

OC-256

Google finds lots of hits to OC-256, but after clicking a huge number of them, none provide more detail than a speed. I can not find any reference to equipment or standards related to such a speed, so I've removed it. As further example of this mindless copy-and-pasting across the internet, OC-255 also produces hits, yet is most certainly not real. Mrand 14:26, 21 March 2006 (UTC)

Full Duplex numbers

• PCI-Express x1 is 2Gbit/s full duplex - list states 4Gbit/s
• Gigabit Ethernet is 1Gbit/s full duplex - list states 1Gbit/s

The first makes comparision between full and half duplex links easier, the second sounds technically more correct to me. Mixing both causes confusion.

It's worse than that. By far the most common listed rate is the simplex rate, Eg: Fast Ethernet is 200 Mbit/s full-duplex but listed as 100 Mbit/s.

Evanh (talk) 10:47, 16 January 2008 (UTC)

Very similar page

I've have a very similar page for years.

Note I used MB/s (that's 10^6 bytes per second) throughout as that is the most common unit of speed/size that people work with in computer systems currently.

Perhaps a link to my page would be appropriate?

Photos or graphs

With the variety of units it is dificult to compute the volume of information here. I suggest including some kind of graph for each section, to depict differences in speed. The only barrier I see to this is making something that can be edited later by anyone, so that leaves out images. Perhaps a text format, like a pipe for each 500 bits, or something? --Digitalgadget 05:45, 11 September 2006 (UTC)

Please discuss this prototype. My intention is to provide some kind of visual comparison. In creating this file, the main problem I see is portraying tiny values with huge ones, which I tried to solve here by jumping to powers of ten. --Digitalgadget 02:45, 20 February 2007 (UTC)

Would it be possible to (mis-)use meta:EasyTimeline to create these graphs? EasyTimeline makes it easy for anyone to edit a graph in text format. --68.0.120.35 04:20, 18 August 2007 (UTC)

Thanks! I can see this working with a lot of effort. Perhaps someone with a strong programming background could use EasyTimeline as a template for making a table meta. Or maybe one exists and I am too new to know where to look. The hard part will be appropriately representing the minute differences between speeds while making it easy to see both ends of a wide spectrum (as I have mentioned before). --67.160.113.95 17:38, 19 August 2007 (UTC) --DigitalGadget 17:40, 19 August 2007 (UTC) (log in timed out)

Only way (at least that to me is satisfactory) to compare such differing values is using a log scale. Trouble is that's confusing to a lot of people. M0ffx 00:45, 2 October 2007 (UTC)

The picture looks good, but still confusing. IMHO I've found the easiest way to communicate information is to strive for consistency. i.e. Use the same measurement for everything. So for example when I'm trying to communicate how s-l-o-w my old modem used to be, I'll say that it was 0.3 kbit/s versus today's 768 kbit/s DSL or 3000 kbit/s Cable. If I want to communicate how much faster today's PCs are, I'll say that my Commodore 64 was 1 megahertz versus today's Pentiums running at 3000 megahertz.

By using the same scale throughout, people can HEAR how much bigger the numbers are for modems/cpus/whatever. The huge size of the numbers (0.3 versus 3000 kbit/s) (1 versus 3000 megahertz) conveys the information. - Theaveng 15:05, 2 October 2007 (UTC)

Serial Attached SCSI 2

I removed the SAS-2 entry because the spec isn't finalized yet, as of 1/17/2007, and I couldn't nail down the operating speeds. Feel free to replace it with correct numbers, if you can. "6Gbit/s" and "600MB/s" don't correlate. |- | Serial Attached SCSI 2 || 6 Gbit/s || 600 MB/s 206.165.137.194 02:33, 23 January 2007 (UTC)

Real references

I made a big edit and I moved all the content of the references and linked them with the <ref> tag. I hope you don't mind. Feel free to edit. --Ysangkok 17:13, 21 January 2007 (UTC)

I think it was the wrong thing to do. Sorry. WLD^talk|edits 17:33, 13 July 2007 (UTC)

External Serial ATA (eSATA) to Computer interfaces (external)

I would like to see eSATA added to the "Computer interfaces (external)" section. But I am no expert. So someone else maybe could do this?

eSata isn't really a general purpose external data bus any more than DVI-I or TOSlink are. On the other hand, I kind of wonder whether or not duplicating SCSI (The Macintosh equivalent of parallel ports for most of its history) into the external section would be a good idea...207.177.231.9 12:25, 17 May 2007 (UTC)

Protocol overhead again

Additionally to what already have been said I wonder whether anyone ever checked whether the numbers listed are with or without protocol overhead, or somewhere between?

For example here's DOCSIS 2.0, which contains not only packets but all kinds of dirty tricks to make sure the data arrives through a noisy wire, they use variable sized forward error correction, different size encapsulations, etc.

I would guess these values are all raw bit transfer rates, which means that the BYTES column means even less than I tried to emphasize in the notes; with "theoretical" 43Mbits which includes noise, packet headers, checksums, FEC, and god knows what, it may be well much less useful-bits-in-second, which gives then useful bytes-per-sec times 8...

And there is IP and TCP protocol overheads too. For example for an ftp transfer it means 52 bytes for every 1500 bytes (at least for those packets I just checked) which is ~1.035 difference.

The BYTES column is a good approximation, but I believe its imprecisity(sp?) should be emphasized. --grin ✎ 09:43, 29 January 2007 (UTC)

grin, you are right about the imprecision of the bytes column - which is part of the reason there is a link to Measuring network throughput, which goes into more detail about protocol overhead. Feel free to make the imprecision of the bytes column clearer! WLD^talk|edits 11:21, 29 January 2007 (UTC)

I don't think it's possible. Even DOCSIS - which is "just one cable tv net protocol" - defines dozens of encoding combinations, and throughput depends even on the data sent. I just wanted to justify my warning in the notes, because someone referred me to this page and I kindly wanted to prevent people to believe the B/s value is holy grail. :-) --grin ✎ 01:20, 31 January 2007 (UTC)

We have 8Mbit in one MB (1MB)

If we assume that 1MB = 8Mbit, giga=1000 mega this is correct::

• Serial ATA (SATA-300) 2.4 Gbit/s 300 MB/s

and this is NOT::

• Serial Attached SCSI 3 Gbit/s 300 MB/s

We just can NOT declare, that 300X=2.4Y in one line -- and NEXT line below that 300X=3Y :|. BTW: Gbits are signaling rate and MB are throughput.

Just FYI:: SAS supports higher transfer speed (1.5, 3.0 or 6.0 Gbps). SAS supports point data transfer speeds up to 3 Gbit/s, but is expected to reach 12 Gbit/s by the year 2012. —Preceding unsigned comment added by Jan Kunder (talk • contribs)

I think the problem is that serial connections do not always have 8 bit per byte (but can have start- and stop-bits and/or parity bits) so the conversion is anything but a simple "division by eight".

To make things worse, different manufacturers are free to specify things from different perspectives - for example "standards body 1" might say "we can get 10Mbyte through this and we use 10bit/byte so we're going to quote 100Mbit/sec" while "standards body 2" might say "we managed to squeeze 100Mbit/sec through this link so at 8bit/byte this makes 12.5MByte/sec so that's the number we're going to quote because it makes our stuff seem faster than that other standard by standards body 1".

I think the whole table could stand a disclaimer that all these numbers are at best good to within an order of magnitude.

Iron Condor 18:49, 29 May 2007 (UTC)

Device/Connection table organization

As this page is edited and evolves into something more complex, please keep in mind that this content needs to be easily understood by ordinary folks. For instance, the idea of organizing the table by "Order of magnitude of bandwidths" may result in greater technical accuracy, but it is much easier to find specific device specifications in the current table format, and it also is much easier to read and comprehend the information because similar device/connections are grouped together (for the most part) and seperated by bold headlines. It's not perfect, but as is, the list is easier for those of us who are NOT engineers! The proposed new table organization makes it very difficult to quickly scan the table and find something...Perhaps a link to an alternative "order of magnitude" version of the table would be helpful, but please, don't replace the existing table...

Add Ethernet cable bandwidth to table

It would be very helpful if Ethernet cable specifications and bandwidth were added to this list, such as Cat 5, Cat 5e, Cat 6, etc. This seems necessary because components with the appropriate technical specifications must be used to connect all these various technologies together and achieve the bandwidths listed. Geopix 07:52, 25 May 2007 (UTC)geopix

Channel Capacity is not Bandwidth

If both are named in the article, the difference should be pointed out. (If in almost all cases the numbers quoted by manufacturers etc is Bandwidth, then I see no reason to mention channel capacity at all in the first place.). Iron Condor 18:40, 29 May 2007 (UTC)

Connection column

Why is the "Connection" column now flush right, instead of flush left (as I believe it once was)? This is very bad graphic design in a table like this. There are times to use flush right alignment in tables, but in this case, the column contents have become more difficult to read. Flush left alignment allows readers to quickly scan each section, find the device they are seeking and see the bandwidth. Flush right might have worked if the variations in device name line widths weren't so great, but it does not work — at all — in this instance. Please, fix this. Geopix 12:46, 18 June 2007 (UTC)GEOPIX

It appears this was done so that the other columns (which are better when aligned to the right) would be right-aligned. The entire table is right-aligned. I'm not sure there is an easy way to align only some of a table's columns to the right in the wiki syntax. — Aluvus t/c 17:46, 18 June 2007 (UTC)

Thanks and comments on ISDN and 1xRTT

Hi - I stumbled upon this while researching comparative effective speeds for mobile wireless networks. This is an excellent cheat sheet and very useful! However a few comments. - I am going to add a link to CDMA2000#CDMA2000_1xRTT - I think the ISDN section needs clarification - most people are going to be looking for "what is my effective bandwidth" - and for basic ISDN US aggregate bandwidth for Basic rate interface is 128 kbps,etc see [1]--Boscobiscotti 16:25, 27 June 2007 (UTC)

Bandwidth? (in Hertz!)

If we are going to falsely title an article with the term "bandwidth" even though the article is really about channel capacity not bandwidth, could we at least actually include the bandwidth in the table? I was hoping to find the bandwidth (Hz) of some items and this article seems like the place to look. Alas, it is not. --Miken2005 08:33, 8 July 2007 (UTC)

Aw, crap. You caught us. The radio is dead you see so we figured no one would notice if we borrowed a word or two. It's so troublesome to invent our own, and bandwidth just rolls so much better of the tongue than channel capacity.

Truthfully bandwidth is often used in the way this article does, as a measure of channel capacity. It probably stem from the fact that channel capacity tends to be proportional with bandwidth, which leads the average geek (read: me) to equate bandwidth with channel capacity.

Technical terms are often twisted and abused by non-techies, and that's the demographic Wikipedia articles tends to be written by. Check out Use and Abuse of Technical Terms for a small collection of abused terms.

--Anss123 16:18, 8 July 2007 (UTC)

As the general said, the old guard dies but does not surrender. Twenty years from now the literal meaning of "bandwidth" will be a footnote, and those few whose work requires the concept will be saying "frequency range". That's what I found in Basic Rate Interface, looking for the bandwidth of that connection. I inserted and linked the old term, in parentheses. Actually the losing general said "merde" but it's the same thing. Jim.henderson 17:29, 8 July 2007 (UTC)

Calling it "bandwidth" is not my biggest complaint. More I am just suggesting that since we are calling it bandwidth, it would be fitting to include the bandwidth (Hz) -- perhaps in an additional column. --Miken2005 20:43, 8 July 2007 (UTC)

If you like. A quick look at a few of the linked articles found one using "bandwidth" literally, several lacking the word, and several using it to mean transfer rate. I surmise that it is rare to quote literal bandwidth at all. Perhaps you should start in the linked articles, adding literal bandwidths when you can find them. Once you've got half a dozen, you can start including them in this list in parentheses, and when there are a dozen or two, perhaps that's the time that the table should have another column. Jim.henderson 20:41, 12 July 2007 (UTC)

The table format is fubared

The table is not laying out correctly, and my knowledge of Wikitables isn't good enough to resolve this. I was trying to put a comment in the text so that well-meaning editors don't change the modem figures back to 8 bits/octet/byte when I discovered this. Could some kind soul rescue the table - and while we are at it, could we put the notes at the bottom of each section, where they belong, rather than at the end of the article. Thanks. WLD^talk|edits 17:32, 13 July 2007 (UTC)

I glanced at the tables, but don't see anything wrong. Why do you say it isn't laid out correctly? —EncMstr 17:47, 13 July 2007 (UTC)

The column titles were displaying below the first rows (IIRC) - anyway, I found and fixed the fault. WLD^talk|edits 21:06, 21 August 2007 (UTC)

Add a date introduced column in the table

This will allow for better understanding and comparison of the various technologies —Preceding unsigned comment added by 91.113.23.134 (talk) 06:59, August 27, 2007 (UTC)

Missing things like PCMCIA, PC-Card, Expresscard, etc.

I can't seem to locate bandwidth mentions for things like PCMCIA, PC-Card, Expresscard -- i.e. technologies typically used to extend laptop buses. Was this an intentional exclusion?

No. If you can find references to bandwidths for those technologies, feel free to add them. Cheers. WLD^talk|edits 16:59, 4 September 2007 (UTC)

ExpressCard just uses a USB or PCI-Express link, so bandwidth would match whichever of those was being utilized. — Aluvus t/c 18:34, 4 September 2007 (UTC)

Order of sections

Shouldn't the Local area network be before the Wide area network? It just seems more natural to me. 89.120.124.53 10:20, 20 December 2006 (UTC)

The idea seems to be more to put the slowest devices/interfaces at the top, and the the faster ones at the bottom. LAN is almost invariably faster than WAN unless you have an expensive broadband connection and a coax Ethernet or early Token Ring adaptor... 82.46.180.56 00:26, 4 September 2007 (UTC)

Legacy PC buses

This list is painfully lacking. I don't see VLB, EISA, or MCA on the list, to name a few of the more prominent 1990s bus technologies. 71.116.217.242 20:09, 28 June 2006 (UTC)

It's also a bit innaccurate with the more popular stuff. ISA wasn't ISA until the 16-bit, 14-IRQ, 7-DMA IBM AT Bus launched with the 286 had been unofficially adopted as a widespread 'standard' and manufacturers started to retcon it into their terminology. The earlier 8-bit, 7-IRQ, 3-DMA and otherwise reduced-functionality PC & XT buses (with circuitry and connectors for 5 and 8 cards respectively) seen in 8088/8086/80186 computers isn't really 'ISA' at all. Both, however, officially ran at 7.16mhz (half the main system timer, with the original 8088 being 1/3rd) independently of CPU/FSB speed (4.77, 6.0 thru 33, 40mhz or more) though it could be unofficially overclocked a little (to, wow, 7.2, 7.5, 8.0, 8.33mhz...) through advanced jumper or BIOS settings if none of your expansion cards played up. This speed stayed in place even for EISA, and the (E)ISA part of MCA/VLB, and on into the Pentium III/Athlon era of 200+mhz FSBs, GHz+ CPUs and USB2.0 adaptors that could overload the even a decent PCI bus... no wonder people wanted shot of it!

And it could of course do with some alternative buses - Mac and Sun come up for one, Atari Cartridge, Sinclair expansion edge connector, etc :) 82.46.180.56 00:26, 4 September 2007 (UTC)

32 bit HyperTransport

HyperTransport supports an auto-negotiated bus width, based on two 2-bit lines to 32-bit lines. The full-sized, full-speed, 32-bit bus in each direction has a transfer rate of 20,800 MByte/s (2*(32/8)*2600), making it much faster than many existing standards. Buses of various widths can be mixed together into a single application (for example, 2x8 instead of 1x16), which allows for higher speed buses between main memory and the CPU, and lower speed buses among peripherals as appropriate. The technology also has much lower latency than other solutions.

This is the fastest bus, and i miss this in the list

110 baud modem

Someone deleted the entry for the 110 baud modem. They did actually exist. See [2] and [3]. WLD 08:25, 29 August 2006 (UTC)

Not to mention the 75 baud upstream mode of certain split-standard 1200 baud downstream modems... 82.46.180.56 00:26, 4 September 2007 (UTC)

Conveying the Magnitude of Varying Speeds to non-technical persons

(WAS: "Photos or graphs")

With the variety of units it is dificult to compute the volume of information here. I suggest including some kind of graph for each section, to depict differences in speed. The only barrier I see to this is making something that can be edited later by anyone, so that leaves out images. Perhaps a text format, like a pipe for each 500 bits, or something? --Digitalgadget 05:45, 11 September 2006 (UTC)

IMHO I've found the easiest way to communicate information is to strive for consistency. i.e. Use the same measurement for everything. So for example when I'm trying to communicate how s-l-o-w my old modem used to be, I'll say that it was 0.3 kbit/s versus today's 768 kbit/s DSL or 10,000 kbit/s Cable. If I want to communicate how much faster today's PCs are, I'll say that my Commodore 64 was 1 megahertz versus today's Pentiums running at 3000 megahertz. Likewise I'll say my C64 was 0.064 megabytes versus a modern PC's 1000 megabytes of RAM. ---------- By using the same scale throughout, people can HEAR how much bigger the numbers are for modems/cpus/whatever. The huge size of the numbers (0.3 versus 3000 kbit/s) (1 versus 3000 megahertz) (0.064 versus 1000 megabytes) conveys the information.

With that thought in mind, I have updated the article. That way non-technical persons can see at a glance, how much faster different standards are, compared to others. - Theaveng 16:09, 2 October 2007 (UTC)

Only problem is, now the bold figures are not necessarily the most commonly cited, as claimed at the top of the article. - dcljr (talk) 23:29, 3 October 2007 (UTC)

Sure they are. Just because you say "0.1 meters" instead of "100 millimeters" doesn't change the size of the object being measured. It's still the same exact size no matter how you say it. ----- Plus, I think it's more important to communicate to "newbies" the relative sizes of these differing standards, and the best way to do that is to be consistent in your units (i.e use the "meter" from beginning to end). - Theaveng 08:33, 4 October 2007 (UTC)

I am not entirely convinced that "newbies" are the sort of people that would commonly want to compare the speed of DOCSIS and a V.21 modem. But many comparisons would still run into the old problems. For instance, "Wireless networking" standards are all currently listed in kbps and kBps... but "Local area network" standards are listed in Mbps and MBps. If someone wants to compare 802.11n and Ethernet (which I would say is a much more likely and much more useful thing to want to do), they will have to make a conversion. Moreover, they didn't have to make any conversion previously; wireless networking standards were all quoted in Mbps and MBps, and I'm not sure why this was changed. The only way to completely avoid this sort of issue would be to force everything into a single standard prefix, which is far from ideal and does not scale well (imagine a future link that is 1 Pbps, or 1,000,000,000,000 kbps... and imagine that this page needs to list several later, slightly faster generations as well).

I "get" the desire to make this information more accessible to non-technical readers. But I would say that something like "802.11n: 540,000 kbps" does a disservice to such readers. To the very non-technical it is confusing ("why does the box say 540 Mbps?"); to the somewhat technical it is a stumbling block in comparing this information to outside information. For technical readers, it probably takes more effort to check data against what they already know ("wait, 540,000 kbps? Let's see... yes, that's right") than to simply make conversions as needed. And if their intent is to look something up and discuss it with other technically knowledgeable people, this will only generate more confusion (and perhaps a shade of embarassment). Very non-technical readers are unlikely to really want to make comparisons between wildly different standards so much as very similar ones; more technical readers are already capable of making their own conversions, or can quickly learn how.

Standardizing prefixes sounds good in theory, but in practice it doesn't solve the problem. It just moves the problem, and for very common use scenarios it makes the problem worse. My suggestion would be to use the prefixes that are in most common use (with a note/link to aid those unfamiliar with how to make conversions), and live with the difficulties that come from that. The next best option is to add another column to list the most common form, but this still runs into problems when large disparities arise (and makes them even worse by taking up horizontal space, unfortunately). Apologies for the big block of text. — Aluvus t/c 04:41, 11 October 2007 (UTC)

I disagree. Since I've changed this article to use common prefixes (within each heading), I've found this article MUCH more useful & I refer to it almost-daily. I'm an engineer (i.e. technically-minded), but even so I find it easier to use a common measure throughout each sub-heading. ----- For example, it's much easier to compare the speed of a 1200 baud modem with a DSL line, now that they are expressed using common terms: 1.2 kbit/s versus 8000 kbit/s. I can tell with just a glance how much bigger the DSL is, and without having to make mental gymnastics trying to convert units.

The old format of 1200 bit/s v. 8 Mbit/s did not convey the magnitude of the difference (in fact, it makes the 1200 look faster than the 8, which is confusing to non-techs). It's basically the same reason why you do not' say, "I drove 10 kilometers to the airport, and then I flew 10 Megameters to Europe." Although it's technically proper to say 10 Megameters, next-to-nobody knows what it means; it totally fails to communicate information to the reader. So instead you stay consistent in your units ("I drove 10 kilometers, and then flew 10,000 kilometers"), so people understand what you just said. Consistency leads to understanding & better communication.

As for your Wireless 802.11 v. Ethernet example..... that's a bit like comparing apples & oranges. Like comparing a cellphone's bandwidth (low) versus an Internet videophone's bandwidth (high)... they're just not the same. They are separated by several orders of magnitude, and that's why they are under different headings & use different measurements. IMHO.

"Why does the box say 540 Mbps?" If they have the box in front of them, why are they needing to look it up? Typically people come to wikipedia because they don't have the box in front of them. ----- "Wireless networking standards were all quoted in Mbps and MBps, and I'm not sure why this was changed." ----- No. The wireless networking section used Kbyte/s and Mbyte/s. It was confusing. Now that they are all consistent it's much easier to see, just by glancing, relative speeds of different technologies.

BTW I like that idea of adding a third column (typical usage). My browser's got enough whitespace to add not just 1, but 2 more columns to the right, so I don't think it would be too wide. But. I don't think it's necessary at this point. Maybe in the future. - Theaveng 19:57, 11 October 2007 (UTC)

Perhaps you refer to it a lot because you have converted it into a format that is convenient for yourself. It is dangerous to assume that this translates into being useful for other people. The example of IEEE 802.11 standards and Ethernet is a prime one: this is a very common comparison that people do in fact want to make, one that shows up in forums often (asked by people of varying technical knowledge), and one that is worthwhile to ask (if you have a 10 Mbps Ethernet network and are considering replacing 802.11g access points with 802.11n access points, it should certainly be of interest to you, for example). Maybe you don't make that sort of comparison often, but many other people do. I would wager that comparing some variant of Ethernet and some variant of 802.11 is one of the most common reasons people visit this page.

Conversely, I would wager that virtually no one comes to this page wanting to compare ancient dialup modem standards to modern broadband standards. Evidently you do, but I doubt many others do. And such people are most likely technically knowledgeable to begin with, so they are hardly representative of the non-technical readers that your changes were supposed to help.

Wireless networking standards were all listed in Mbps as far back as I cared to look; here is what it looked like at the beginning of the month. You yourself changed them all to Kbps the next day, while also moving the section farther from the LAN section. There was no obvious reason to do this. — Aluvus t/c 00:55, 12 October 2007 (UTC)

You're right. I did change it from Mega to kilo.... and no I don't remember why I did that. (shrug). Well then I'll just move the wireless networking back with the wired network. I was just trying to improve the article so it would be easier to understand (whereas previously, it was not easy to understand when the units kept changing). - Theaveng 20:15, 12 October 2007 (UTC)

Token Ring

The article here states 1Gb token ring exists, however nowhere else can I see 1Gb token ring, even on the token ring article. —Preceding unsigned comment added by 68.82.202.52 (talk) 17:12, 3 October 2007 (UTC)

Come to think of it: where did the 4.16 MBit/s figure come from? The token ring article states the original token ring ran at 4 MBit/s (which as far as I know, is correct, if by original token ring the author is referring to the IBM network later standardised by 802.5) 144.32.136.46 14:04, 13 October 2007 (UTC)

The 4.16 Mbit/s figure comes from the IEEE standard. The token ring article is incorrect. See also http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/tokenrng.pdf. I too would like to know where the figures for >16 Mbit/s came from. WLD^talk|edits 17:34, 27 November 2007 (UTC)

Silly me - I just reread the standard - and guess what - no 4.16 Mbit/s. Looks like the Cisco document is wrong. WLD^talk|edits 18:23, 27 November 2007 (UTC)

Campoftheamerica's Point-of-View edits

Your attempt to change the Bandwidth article to a Anti-USB point-of-view has been reverted. This is an encyclopedia, not a place for you to enter your non-sourced opinions & comments. Thank you. - Theaveng 11:08, 19 October 2007 (UTC)

I guess you overlooked the sources huh? CDRFAQ.org? The defacto authority? And who you calling a USB lover? Did you even read? I think the sustainable transfer rate for USB is more like 25MB/s, not the 60MB/s. Don't be an asshole. Try reading before you jump to conclusions.

"Asshole"??? Nice. The purpose is not to "think" what USB does, but to quote what is claimed in specs. There is already a note at the top of the page to warn readers that these are "maximum" specs, not necessarily real-world results. That should be sufficient. - Theaveng 18:32, 19 October 2007 (UTC)

It wasn't my thinking I put in the article, just sourced quotes. You threw out the stuff out without reading it, and then flamed me for writing something I didn't.

If you have something to add, continue it here: http://en.wikipedia.org/wiki/Talk:List_of_device_bandwidths#Sustained_bandwidth_vs_burst_speeds--Campoftheamericas 05:06, 20 October 2007 (UTC)

Hey, I'm sorry. I would just like to get along. --Campoftheamericas 05:15, 20 October 2007 (UTC)

Sustained bandwidth vs burst speeds

Hi for a fair comparision between devices I'd like to see the sustained and burst speeds. IE USB High Speed has a burst speed that does not fair well as compaired to Firewire 400.

Thanks

 Neil C.

I agree, I put some sourced quotes, and then "theaveng" says I am vandalizing? This is what is getting taken out:

--- COMPARISON OF CD VERSUS DVD:

From http://cdrfaq.org/faq05.html#S5-22 :

It has been stated that, at a rotational speed equivalent to about 50x at the inside of a disc, the polycarbonate starts to deform and the disc becomes unreadable. Experiments (e.g. an episode of the "Mythbusters" TV show from 2003) have demonstrated that discs will warp when they get up around 25,000 to 30,000 RPMs. However, recent 52x drives only read data that quickly from the outside of the disc, actually reading at about 21x near the inside. This requires a speed of 10,000 to 12,000 RPM, which is safe for discs in good condition. Reading at 52x from the very inside of the disc would require a speed of about 27,500 RPM, and read data at 137x near the outside.

Incidentally, "1x" on a DVD-ROM drive is 1353KB/sec, which is roughly 9x the speed of a "1x" CD-ROM drive. A 16x DVD-ROM drive reads at a speed equivalent to a 144x CD-ROM drive! The DVD doesn't actually spin 9x as fast, though, because the DVD "bit density" is higher. The drive can read roughly three times more data in a single revolution from a DVD than it can from a CD. (Incidentally, the 1353KB/sec figure comes from the DVD maximum user data rate of 11.08Mbps, where the 'M' is 1000*1000.) For more details, see http://www.dvddemystified.com/dvdfaq.html#4.2.

Has no relevance to this article, because it does not discuss 50x speeds. It only lists 1x speeds. - Theaveng 18:56, 19 October 2007 (UTC)

--- COMPARISON OF FIREWIRE VS USB

From USB.ORG:

"With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints."

From http://lists.apple.com/archives/Usb/2007/Jul/msg00035.html :

"I am achieving around 8 MB/s of data transfer speed (checked it with USB Analyzer), whereas the same device when run on Windows/Linux machines gives bandwidth of more than 20 MB/s. The device is a High speed one." (bulk transfer)

From http://lowendmac.com/macdan/05/1007.html :

Bare Feats tested USB 2.0 drives against FireWire in May 2004 and found that sustained read and write speeds with USB 2.0 drives were only about half that of the same drives on a FireWire 400 bus on Apple's hardware. (The same report showed FireWire 800 up to 50% faster than 400. It also mentions that USB 2.0 is faster on Windows PCs, where it rivals FireWire 400 for throughput. TechTV did a thorough comparison on Windows PCs and found that FireWire 400 outperformed USB 2.0 by 15-70% depending on the test.)

A good Firewire impl, for instance, should beat USB when dealing with a single device - thanks to its interrupt driven nature. The reverse is also true if there are many devices on the bus as USB deteriorates more gracefully thanks to its polling nature. In other words, it’s not straight forwards to determine sustained bandwidth for any bus as you need to keep in mind implementation details and usage scenarios. Favoring one usage scenario easily falls into POV territory, so I believe a more rounded discussion in their respective articles to be a better option. --Anss123 14:04, 19 October 2007 (UTC)

Likewise I don't see how this has any relevance to the article, since the purpose is to compare maximum rates, not sustained. That's why the 56K modem says "56 kbit/s" even though we all know ~45 is more typical. - Theaveng 18:56, 19 October 2007 (UTC)

There needs to be a comparison list, and the most useful comparison is the real world transfer rates. Perhaps the following: links to the respective information on wikipedia, right next to the maximum number so people can find what they really care about: sustained throughput.--Campoftheamericas 21:27, 19 October 2007 (UTC)

The place to put your "real-world" results is not here, but on each separate, dedicated page. i.e. On the USB page. And we already provide a link to that page for people to learn more about USB, along with any criticisms (such as yours) about the standard. - Theaveng 20:59, 20 October 2007 (UTC)

Theaveng wrote: "VANDALISM. If you want to push your pro-USB viewpoint, please do it in the TALK page where it can be reviewed FIRST & consensus reached. Do not ruin the encylopedic entry with random opinions" Please "assume good faith" and do not accuse of vandalism, without having first read what the other person has written, like you did here: http://en.wikipedia.org/wiki/Talk:PlayStation_2#sockpuppetry . Also, the "real world" results are not my own. They were quotes from sites which I linked to, namely CDRFAQ.org. If I were to say they were my own I would be plagiarizing.--Campoftheamericas 23:34, 21 October 2007 (UTC)

I'm sorry. When I looked at the page, it looked like chaos, and I immediately jumped to the conclusion "vandal". We had a similar incident at the HD Radio page where a single person essentially destroyed the page, and wasted almost a full day just trying to restore it. When I saw your edits, I thought I was experiencing a repeat of that. - Theaveng 20:48, 22 October 2007 (UTC)

What do you think about changing the title of this article to "List of device maximum theoretical bandwidths", or something like that? This may help to ease future disagreements of this nature (consider why this section exists). How can it be made more clear that the bandwidth listed is not what you will get in "real world" use.--Campoftheamericas 22:35, 21 October 2007 (UTC)

Naa. An entirely correct title would be List of device maximum channel capacity specified by the manufacturer. The point of the name, however, is to be descriptive to the majority of users. A few, like you, will wonder why we don't actually list bandwidth or in your case: actual transferee rate. English is simply not a precise medium so compromises has to be made, those compromises include shortening the name and abusing a word in this case.

--Anss123 22:51, 21 October 2007 (UTC)

There is a note at the top that reads "Many of these figures are theoretical maxima", which seems to mostly do the trick. I don't think it is necessary to make the title longer. — Aluvus t/c 22:53, 21 October 2007 (UTC)

Glad you noticed: I changed to bold "Many of these figures are theoretical maxima"  ;-) Perhaps it should be the first thing that is said, but I am content with the way it is, if anything because I don't feel like getting flamed again.--Campoftheamericas 23:37, 21 October 2007 (UTC)

other bus'

i'm not sure what the plural form of bus is. I'd like to see some other common bus' here, such as sbus (25MHz 64 bit iirc) the GIO line, gio 32, gio 64, vmE, NuBus (32 bit at 10, or 20MHz) I belive HP had a few bus' used in their systems. There's also the bus Intel's been using for gigabit ethernet, the name escapes me, and in addition to those, are the connections used between the northbridge and the south bridge. I believe VIA calls theirs V-link. also single and dual link dvi might be interesting.

'Buses', surely? :) It does look like some of these have now been added, which is nice. 82.46.180.56 00:26, 4 September 2007 (UTC)

Camera Link

The data rates listed seem all over the place. It also may supports or is split into 3 speeds, just do not know the speeds. http://www.adept.net.au/grabbers/coreco/pccamlink.shtml

http://www.machinevisiononline.org/public/articles/archivedetails.cfm?id=1528 255, 382, 680MBps (x8 for Mbps)

http://aegiselect.com/products/cameralink-cameras.html "Camera Link® technology features the combination of both high-speeds (1.2, 2.4, & 3.6 Gbps) and high-resolution imaging."

http://www.tmworld.com/article/CA377231.html "The three levels accommodate the wider data paths required by multi-tap cameras (with more than one video-output stream) and allow for future expansion. The full Camera Link configuration achieves an effective bandwidth of 4.8 Gbps."

--Flightsoffancy (talk) 21:54, 9 January 2008 (UTC)

Well, I had time at work (since we work with it) to read up on it, and learn the details. I have updated both this and the CL page. Excellent info to have. --Flightsoffancy (talk) 14:13, 22 January 2008 (UTC)

NFS over Infiniband faster or slower then iSCSI over 100G Ethernet ? both is valid according to the table.... also something about the formating.

Hi, it looks like there is the one ore another error in the table. NFS over Infiniband 120000 Mbit/s 12000 MB/s iSCSI over 100G Ethernet (Planned) 100000 Mbit/s 12500 MB/s How it could be that NFS is faster in bits but slower in bytes than iSCSI ? it would be also nice if the units are more or less the same.... i mean sometimes KB and sometimes kB in the byte column. Bold and none Bold is also mixed. and sometimes there ar seperators for thousand and sometimes not. —Preceding unsigned comment added by AssetBurned (talk • contribs) 17:29, 14 January 2008 (UTC)

I only found one instance of "KB" instead of "kB" and that was just a typo. No big deal. ---- Theaveng (talk) 16:10, 22 January 2008 (UTC)

Infiniband uses 8b/10b encoding, so every 10 bits sent carry only 8 bits (one byte) of data. There is a convention with 8b/10b systems to quote the bit rate as all bits sent. I do not know the exact logic behind this convention, but it is widespread. Entries in bold previously were the most commonly-cited form of a link's speed, but this is no longer consistently true. — Aluvus t/c 21:55, 22 January 2008 (UTC)

I believe the logic behind it is to do with acutal speed versus maximum speed and something to do with data control. I to aint 100% up on it just read the thoery behind it.--Andrewcrawford (talk) 16:27, 9 July 2008 (UTC)

Some of the listed figures are overly precise

For example: FireWire 393.216 Mbit/s . Has the speed truly been measured to 6 signifigant digits of accuracy? I would think "393 Mbit/s" would be good enough (especially since most of these numbers are theoretical, not real-world values). ----- There are a couple other data values given that are also overly precise IMHO.  :-) Theaveng (talk) 22:23, 28 January 2008 (UTC)

article reorganization

After thinking about the changes that another user and I made earlier this afternoon, I think that it would be best to reorganize the article as follows:

• Have only two main sections: Networking and Computer Buses.
• Make the currently existing sections into sub-sections of these two main sections.
• Do not duplicate any technology between sections; thus, for example, ADSL2 should be in only one sub-section, DOCSIS v2.0 (Cable modem) should be in only one section, etc.
• Change the title of Modems/Home user connections back to "Modems," because we should just lay out the information and let the reader decide which types of connection are more appropriate for home-user applications versus business/mission-critical applications.

69.140.152.55 (talk) 23:00, 28 January 2008 (UTC)

I'm okay with those ideas, but I do object to only listing DSL or Cable modems under one section. Somebody moved them to WAN, and I disagree they should go there. When I think of those technologies, I think of my living room where I watch streaming television, not some distant network somewhere. I like (and I'm sure other readers like) being able to make a quick comparison between the older 28k or 56k technology versus today's DSL/cable options. i.e. To see how far internet-to-home connections have progressed. ----- An acceptable solution IMHO is simply to list them in two places. And why not? Wiki's got ~100 terabytes of space. A few extra 0.0000000001 terabytes (few extra characters) is not going to make much difference. ---- Theaveng (talk) 18:32, 29 January 2008 (UTC)

idea to the lists!

I just dont do this because i dont have availble time, im in the working time now. but it would be cool if the lists provide the user on the top of each columm a button that sort the entries by name, or velocity, so the people can find the information that they need faster than using ctrl+f thanx dudes —Preceding unsigned comment added by Ogat (talk • contribs) 20:45, 18 February 2008 (UTC)

Raw speed?

I'd like to know the speeds that one can get over raw POTS, raw cable, and raw fiber. For example, cable typically carries dozens of TV channels plus who knows how many DOCSIS cable internet connections; I'd like to know how much data could theoretically be pushed across a cable. Ditto for POTS and fiber. Get out your time machine and tell me what you think Wikipedia will say, about 100 years from now, what the max customer and provider bandwidths will be for them. I'm sure there are specs out there, I just haven't been able to find them. It looks like DSL is already up to 250Mbps, much higher than I thought it could go. --Scott McNay (talk) 13:15, 7 April 2008 (UTC)

Incorrect conversion between bit rate and byte rate

The conversion between gigabits-per-second and megabytes-per-second is incorrect for Fibre Channel, SAS, SATA, and Infiniband. These protocols incorporate the 8b/10b encoding method. An 8-bit byte is converted to a 10-bit transmission character. Thus to convert from bit-rate to byte-rate one divides by 10, not 8. Fibre Channel products are avilable today, off the shelf, at 1, 2 and 4 gigabits per second (Gb/s) which in bytes is 100, 200, and 400 megabytes per second (MB/s). Note the lower case 'b' for bits and upper case 'B' for bytes. Ten gig Fibre Channel is on the horizon. These data rates are simplex. Fibre Channel is fully duplex so marketeers like to double these numbers, which is permissable from an engineering point of view. It is difficult to find computers and disk drives that can read and write at full speed in both directions at the same time but it is still technically correct to advertize it that way. SAS and SATA products are presently available at 1.5 Gb/s and 3 Gb/s with 6 Gb/s products appearing in private technology demonstrations (it is now Spring 2008). I don't play with Infiniband so I'm not sure what is available there. There is one notable difference between Fibre Channel and SAS/SATA. Fibre Channel was the first protocol to utilize the 8b/10b encoding scheme. The original architects wanted Fibre Channel to deliver 100 megabytes per second under true operating conditions. When it became apparent that the protocol would impose a performance penalty of 6.25% they increased the clock rate from 1.000 Gb/s to 1.0625 Gb/s to compensate. Thus, Fibre Channel operating at the base rate of 1.0625 Gb/s truely delivers 100 MB/s in real-world operating conditions. In Fibre Channel this concept scales to the higher speeds also. The same is not true for SAS and SATA. The penalty imposed by the protol is not compensated. Still, in the SAS/SATA world it is common to claim 3 gigabit transmission rates equate to 300 megabyte data transfer rates and so forth. Like Fibre Channel, SAS and SATA are full duplex technologies. One needs to be careful when reading the advertizements whether the quoted rates are simplex or duplex.

Ken Stewart gordon_ken_stewart@msn.com —Preceding unsigned comment added by 207.224.123.54 (talk • contribs) 18:24, April 19, 2008

simplex, duplex, symmetry

it might be helpful to add a column with a two or three character that indicates whether the device is capable of a duplex connection, whether duplex connection is symmetrical, and an optional footnote.

(footnotes would permit adding info on things like asymmetrical upload/download rates while keeping the table width reasonable.) —Preceding unsigned comment added by 69.253.239.161 (talk) 18:49, 22 April 2008 (UTC)

Archive 1

Archive 2

Archive 3

Archive 4