Talk:List of interface bit rates/Archive 3

quickpath is dead

pls add quickpath (25Gbyte/sec) http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect —Preceding unsigned comment added by 89.139.32.131 (talk) 22:20, 20 October 2008 (UTC)

current qpi is wrong... qpi is 20 bit, not 16, so at 6.4GT it is 16GB/s not 12.8 —Preceding unsigned comment added by 70.15.43.26 (talk) 07:00, 28 December 2008 (UTC)

QPI Throughput should be stated per-direction QPI has error-checking and other overhead that limits actual data-throughput. See QPI literature on Intel web site: [1] Specifically, see the discussion on Pg19, above Table-6. QPI is a full duplex connection. The capacity values provided in the Wiki Throughput article for QPI should be PER DIRECTION (not sum), in order to be equivalent to the values provided for PCI-e and other full-duplex media. Intel claims 64 bits (8 Bytes) of payload is transferred per Flit. A Flit requires FOUR transfers. A transfer therefor conveys 2 bytes. Thus, a 4.8 GT/s QPI transfers 9.6 GBytes/sec in each direction (maximum, ignoring other protocol overheads and inefficiencies). A 6.4 GT/sec link transfers 12.8 GBytes/sec in each direction. The table should list 9.6 GB/sec and 12.8 GB/sec as the respective throughputs. RME-wiki (talk) 00:09, 18 June 2009 (UTC)

• Intel QuickPath has been abandoned, is this really worth explaining? It was never deployed on a wide enough scale to be worth the time to explain, as opposed to HyperTransport and PCIe and so on. Maybe QPI should be removed as a proprietary interface with no support today and not presently shipping - that would also get rid of a number of other useless but historically-interesting interfaces.

• • This is an old comment, but QPI is definitely not dead and is shipping on current Intel products. The LGA-1366 workstation/server platform and the LGA-1567 multi-socket server platforms both use QPI. All upcoming server sockets on the roadmap, including for the Itanium, also use QPI. The bus table does need work though, since it needs to only have unidirectional bitrate. Alereon (talk) 07:40, 10 June 2010 (UTC)

x.25 et al.

Where are the packet wide area networks? Jlodman (talk) 21:06, 3 June 2008 (UTC)

IEEE-488?

Shouldn't IEEE-488/HP-IB/GP-IB be listed under "Computer buses (external)"? 4.232.105.139 (talk) 14:19, 5 July 2008 (UTC)

WIreles section IP usre comments

Just to clarify for the ip user, The speeds ar ethe maximum theoricatl speed if all conditions are perfect. But regardless you are quoting two different speed terms and if you are gettign 3-4MB/s then you be on approx 40Mbit line not 10Mbit. And for last part it doesnt matter what your internet speed is that doesnt make a effect to your itnernal network speed.--Andrewcrawford (talk) 16:25, 9 July 2008 (UTC)

Wireless networking section changes

There seems to be no credible mention anywhere on the internet of the term "802.11gt" being used to refer to the Super G technology from Atheros, other than circular references back to this list, forum posts, potential typos, etc. I removed this reference and updated the list to reflect other similar technologies for completeness (especially considering the fact that 125HSM/Afterburner has reached very high market penetration through Linksys, et al.), but should all of these non-IEEE variants of 802.11 be removed instead? 67.160.204.59 (talk) 00:57, 10 September 2008 (UTC)

Which oines excately? as some are more important thatn other and reveleant--Andrewcrawford (talk) 06:52, 10 September 2008 (UTC)

I was originally asking about removing all of the vendor-proprietary extensions to the 802.11 standards, like 802.11b+, 802.11g with Super G, etc. only because they were not actual standards along the lines of regular IEEE 802.11g, for example. However on second thought, I would rather leave the list in its current state than remove them all if even one of them is considered relevant, since each of the major equipment manufacturers has chosen to support one of them. 67.160.204.59 (talk) 20:30, 10 September 2008 (UTC)

Superg i agree is a vendor one so isnt really needed here, b+ is formally one it was a revision i cant remember what for though, g should definitely stay as it really is one. I have nto had time to probably go through the list and see what you meaning but i will when i have a chance soon.--Andrewcrawford (talk) 20:37, 10 September 2008 (UTC)

1-Wire

Should 1-Wire be listed under "Computer buses (external)"? Thomas d stewart (talk) 10:37, 3 October 2008 (UTC)

mmm yes and no its communcation device but i dnt think it as straight forward as that. add it if you can think ofa appiorate place to put it and can provide sources to the bandwiwdth of it--Andrewcrawford (talk) 15:34, 3 October 2008 (UTC)

Extra Columns

Should an extra column be added for frequency? And an extra bus width column for parallel interfaces? —Preceding unsigned comment added by 24.215.196.53 (talk) 14:31, 17 October 2008 (UTC)

Do you mean carrier frequencies (0 Hz in most of the cases), or analog bandwidth in Hertz? Well, why not.

I also suggest an extra column for baud rate (symbol rate or pulse rate), one for gross bitrate (line rate), and one for maximum throughput (excluding data link layer overhead, data link layer retransmisions, etc). I don't see the point in having both bit/s and bytes/s columns. Mange01 (talk) 18:02, 6 December 2008 (UTC)

Why do users care about baud rate? Nobody cares if the modem is sending 1 symbol/second or 20 symbols/second, so long as it's fast. IMHO we should stick with what users care about, and that's the speed - either bits/second or bytes/second. ---- Theaveng (talk) 17:05, 11 December 2008 (UTC)

Totally disagree with you there.74.170.34.226 (talk) 00:16, 12 December 2008 (UTC)

Can i ask who you are to decide what people care about and not? Wikipedia is about encolpedia this information could be useful for the article but one it has ot be sourced, and two it meaning and usefully has ot be explained to the averae reader if this can be acievhed then it has no eason not to be added--Andrewcrawford (talk) 20:56, 11 December 2008 (UTC)

I expressed an opinion. There's no call for "who do you think you are???" type comments. I merely think that there's no need for a symbols/second column; that's all. ---- Theaveng (talk) 18:15, 14 December 2008 (UTC)

Theaveng, I'm sorry, I don't understand your point. Wikipedia is not a practical how-to manual, it should present theoretical information of intererst not only to users, but also students, developers, researchers, etc. People often confuse what this article calls device bandwidth (i.e. net bit rate or useful bit rate) with other rate and bandwidth measures, and wikipedia should clarify the difference. Mange01 (talk) 22:11, 11 December 2008 (UTC)

Rename the article to List of device bit rates

Bandwidth is not a good name since we are talking about physical layer issues here, it can be confused with analog bandwidth. I suggest that the article shuold be renamed List of device bit rates or something similar. Mange01 (talk) 18:02, 6 December 2008 (UTC)

Although you are correct in bandwidth is not techincally correct name, 1st it what people see as data transfer rate, secon your suggested name wouldnt be entirely on topic to the article. I would agree and support a move if the article name would reflect the article and would not confuss the avergae reader or make it harder fora average reader to find.--Andrewcrawford (talk) 21:12, 6 December 2008 (UTC)

Your suggestion is List of device data transfer rates? Data transfer rate was defined as "average useful data rate" in its original article (now merged into the bit rate article). This is to my understanding synonymous to Throughput or Maximum throughput, which is not always constant, but may be affected by data compression, protocol overhead, retransmissions, etc. (I'm not sure everyone agrees on this definition, we should search for a definition in some source.) Anyway, what currently is presented in the list article is the physical layer net bit rate or useful bit rate. Mange01 (talk) 22:11, 11 December 2008 (UTC)

mmmm good point, maybe List of Communcations bit rate (bandwidth) or List of Device bit rates (bandwidth) this is quite a hard one.... if i remember tomorrow i will do some research and see if there is a term that might suit even better comment on the above might suggestion might lead to a better name, caus ei think device is also misleading as thigns liek OC aint devices, acutally maybe we shoudl split this article into two one for communcatiosn one for motherboard type stuff?--Andy Chat c 22:59, 28 May 2009 (UTC)

Few other suggestiongs List of Communcations transfer rate--Andy Chat c 22:59, 28 May 2009 (UTC)

Agreed, the communication speeds and system/memory bus speeds should be seperated to their own articles. I don't know if this would be more productive, it's just my opinion. All I know is that I found this article by searching "list of device bandwidths" because I wanted a list of all existing Internet terminal/modem speeds, never intending to look for motherboard speeds and such. However, I dispute the idea of replacing "bandwidth" with "bit rates." Bandwidth is more standard IMO.--Spectatorbot13 (talk) 01:20, 29 May 2009 (UTC)

No, separating them is foolish given that people often choose between internal or external devices using bit rates as the criteria, and given the history of seeing inside-the-box interfaces (like SATA or PCI) become outside-the-computer communications cables. It's fine as it is with these compared, though one could add a column or two indicating something things like shielding tolerances and maximum cable length that would make it obvious that some things just aren't supported/supportable outside a well regulated box. Not that this stops many people from running hard drives just sitting on a table with a ribbon, especially if they have cooling concerns. —Preceding unsigned comment added by 142.177.12.18 (talk) 14:02, 3 January 2010 (UTC)

Standardization and accuracy

I'm curious as to the level of standardization and accuracy involved in this list. For one, FiOS is a namebrand term for BPON and GPON access sold by Verizon. To which their max speed sold is 50Mb/s. While no other company has their namebrand listed. Also 50Mb/s is the max sold but it is restricted in total bandwidth sold the same as GPOn and BPON.

Also, cable's DOCSIS standards are listed with their max speed and ADSL is listed with an averaged bitrate.

A third point, though minor, is a 56k dial-up modem is restricted to 53k on connect speed.

So back to the main point, what is the standard for inclusion and actual speed? 65.13.151.42 (talk) 01:19, 12 January 2009 (UTC)

Yeah, I couldnt find any ITU standardization of "FiOS" hence I couldnt include any date of inception. Also, whats up with [ITU GPON standards page] that lists multiple dates of approval (2004-2008.) I listed 2008 as it seemed the most mature as the descriptions of earlier G.984 devices gave me the impression as being "incomplete," and as GPON seems more advanced than BPON (which was approved 2005) then I dont see the sense of listing GPON as older than the other.

About DOCSIS and ADSL, IMO it makes more sense to list ADSL's average since its speed fluctuates more frequently than cable, which is rather constant. ADSL's max speed is mearly theoretical and may never be reached. It isn't in the realm of fantasy, but not in the realm of reality either, so it would be misleading to list ADSL's max speed since the average is much lower. On a personal note, when I had ADSL, I had a 1024/256 plan but the maximum upload I ever reached was 232 kbits/s and the average maximum around 200.

A third point, though minor, is a 56k dial-up modem is restricted to 53k on connect speed. yes, 56K's actual max speed is 53 kb.--70.65.229.62 (talk) 01:13, 3 February 2009 (UTC)

i think the table should list maximum theorical speed xDSL, with a remark on the bottom of the table referring to the average speeds (as remarks are usualy done in other articles), because this article, to my knowledge, focuses on maximum theorical speeds. ie, see Bus speeds, like PCI-E, AGP, PCI, etc...

also, in the top of the article, the preface should mention that the article lists theorical maximum speeds. it is quite rare, often impossible, to reach the maximum (or close to) theorical speeds--LPCA (talk) 22:56, 9 June 2010 (UTC)

Avail dates

This article needs a new column added with dates on the inception of the device. E.g. 28.8 K modem 1994. 56 K modem 1996.

I came to this page to find out when T1 came to existence (I believe 1998-ish) but neither this page or the T1 page itself says when it was adopted for internet use. If we can all get together and find various sources from the web (or copy the bit of info if they exist on Wikipedia itself) we may successfully build a comprehensive list.

What do yall think?--70.65.229.62 (talk) 02:51, 27 January 2009 (UTC)

if it can be sourced then go ahead if not then no--Andrewcrawford (talk) 18:23, 27 January 2009 (UTC)

Page needs updating.

This page, 'List of device bandwidths' needs to be updated/revised as some of the data is now out of date. E.g. new devices released and new versions released and devices listed as 'planned' have now been released.

I stay away from updating and composing pages on Wikipedia as it is not my forte. I just thought I'd let someone know nonetheless.

58.178.228.223 (talk) 16:28, 7 March 2009 (UTC)

iSCSI over 100Gb ethernet!!!

Ok, someone's being silly here. multiplying the previous substrate speed by 10 to divine the speed of a completely silly medium really isn't encyclopedia. Add to that the high probability that you simply wouldnt have a data source to fill it that fast and I doubt you'd ever get that speed. 121.44.231.207 (talk) 02:08, 10 June 2009 (UTC)

This is not silly. In fact it's one of the few connections that would be likely to have the potential to reach close to the theoretical maximum data rate, because iSCSI (a storage and device access protocol) and Ethernet (the underlying link layer) are both designed to work with *multiple* data sources at once (SCSI is the longest-lived-and-still-used protocol for RAID, ethernet is a multicast protocol). Both have very long histories of being extremely scalable from 1970s technology to present, simply increasing in data rates to many orders of magnitude greater than what they were originally designed for. Consider that a 100Gb Ethernet connection (and there is no theoretical reason not to believe in 1Tb copper ether also someday, it's already in the works) can be saturated by a dozen 10Gb links which cost now under $700/port and draw under 5 watts/port - numbers from a recent Fujitsu release. Consider also that there are presently PCIe SSDs (exploiting the full transfer capacity of two x16 links, and eventually two PCIe 3.0 x32 links for four times the speed) shipping for the PC architecture, that even some cheap existing non-PCIe SSDs get 250MB/s = 2gbps data transfer and that PCIe 3.0 and HyperTransport cards will be available for 100Gb Ether fairly soon at rational prices (for this type of application) it is actually pretty easy to imagine feeding an iSCSI hog at a 100Gb/s trough that might need only a few loaded PC-class storage hosts with 50 current SSDs or a half dozen near-future SSDs to keep it saturated all the time. It's actually hard to imagine a RAID6 circa 2014 or so not relying on exactly this combination of device/protocol.

Seems the most rational configuration, given the dearth of long PCIe slots, might well be a PCIe SSD that actually contains intially 10Gb and eventually 100Gb ether right on it so that it can participate in a SAN or RAID or any scale using a separate 100Gb storage area network. That would take lots of transfers off PCIe buses leaving those for memory/graphics as you would want in a terminal. In other words SSDs and network cards might be merging just because the kind of speed we are talking about pretty much saturates the inside of PCs and higher grades of hardware (switches costing $700/port for 10Gb, soon $2000/port for 100Gb) not constrained by the PC architecture would be required to make such SANs work well.

There are hundreds of data centres willing to pay the price to deploy this the second that it is available. If you want to talk silly, misleading people into thinking that they will ever get USB3 (4.8gbps) speeds out of a single spinning platter is silly (2gbps would be an extreme outside guess of what current technologies to spin platters can do), yet so far USB3 connections lack the ability to support SSDs or RAIDs that might come close to saturating the interface. And that market is far less likely to engineer multi-source data transfers on the scale that the market that uses/wants PCIe and HyperTransport SSDs will certainly do. So you will see iSCSI on 100Gb ether reaching some throughput limit long before you ever see USB3 or SATA6G (which in most configurations shipped will support only 2 drives, at most 2 of each, in add-in cards or mainboards that will stick with 3gbps interfaces as long as most hard drives are not SSDs) get close to their limits. Anyone engineering a serious RAID6 (and most data centres are moving to that from RAID5 to avoid catastrophic multi-drive failures) is going to rely on the more robust iSCSI-over-Ethernet approach when they can get 100Gb and not use dying buses like Fibre Channel, weirdos like Infiniband or an interface like SATA that doesn't also provide power (which ethernet can at lower speeds and soon higher ones) or hobby-hacked SATA6G RAIDs on mainboards that no one else uses for this.

If you want to fix something in this article deletionism isn't the way to do it, the way to do it is to address duplexity and theoretical versus overhead-adjusted maximum data rates and actually-realized-in-practice rates as some of the other commenters have asked. A day does not go by when some vendor does not brag in a press release that they have achieved a new breakthrough data transfer speed on an existing medium, so it should not be hard to find many credible verifiable claims, far more credible than calculations of overhead adjustment or theoretical future speeds of buses that (odds say) will be dead before they are upgraded.

iSCSI and ethernet are two buses/protocols that are certain to outlive 99% of the rest of the list however, and if nothing else the fairly obviously bogus numbers help illustrate the bogosity of less round numbers on it, like FSB or HyperTransport speed claims. Presently AMD does not ship any processor that uses the 32-bit wide transport of HT, in such cases it is entirely appropriate to indicate that the interface simply isn't implemented in practice.

DUPLEXITY and Shared vs. Dedicated capacity should be comprehensively identified in the table

The table often fails to tell the reader which media are full-duplex and which are half-duplex (or multi-access). There may be significant differences in the performance provided. A full-duplex media provides (essentially) twice the capacity as a half-duplex (shared access) media. In addition, a full-duplex media need not suffer the inefficiency associated with a channel-access protocol which mediates the sharing of the channel. (This can be a big win, especially on media with significant latency, or risk of hidden-node issues.)

For example, the table cites 802.11n as providing 600Mbps. Yet, even under optimum RF conditions, a simple 100Mbps full-duplex Fast Ethernet may provide similar (or superior) performance.

The issue is also relevant to internal computer busses. (true buses, such as ISA, have a single pool of capacity; whereas newer technologies, such as PCI-e, provide indendent (and full-duplex) capacity to each slot)

We help to inform the reader if we can find the right wording to put in the table to diffentiate between full-duplex, half-duplex, shared-capacity and dedicated-capacity media. Without such guidance, thw reader may be taken-in by marketing hyperbole. RME-wiki (talk) 00:52, 18 June 2009 (UTC)

This is correct, such buses as HyperTransport and the chipsets that support them can't be easily assessed without this directional limit information. Considering the payoff to pretend that something is twice as fast as it is without being sued, marketing literature inevitably fuzzes these things, so Wikipedia ought to help sort it out.

wattage, price per port, scalability

One way past the problem of data rate vs. bandwidth vs. throughput is to simply label this a list of hardware interface standards and provide a wider range of useful information that a real person could really use to practically assess the benefits of choosing a given port or interface or protocol. If this article is to become very useful it could reasonably expect to be updated as often as, for instance, the intricate articles on chipsets. That means it is possible to consider what information is actually useful to make decisions. For instance:

• Listing the watts each port of that each particular interface typically consumes and (if power is available on that port) the watts available to each device helps with heat and power calculations which are absolutely central in large data centre designs where one might have a choice between many architectures. For instance one might choose 10Gb ether over teamed 1Gb ether ports simply because at five watts / port the 10Gb generates less power and heat, or one might choose 1Gb powered ethernet over 10Gb unpowered to get an AC transformer out of the rack and rely on the 48VDC input from a DC source in another room (without heat issues). These factors drive hardware architecture decisions more than theoretical speeds.
• Price per port is another consideration. While the port might be integral to a mainboard when talking about CPU sockets or HyperTransport or PCI slots, it's still possible to identify the price differential for a board with versus without that particular port on it. Two columns could identify price per port on a discrete add-in-card) versus incremental price of the dedicated device when integrated as part of a mainboard.
• Scalability of the interface is important for long term future-proofing. SCSI and Ethernet have scaled up from 1970s data rates to present (see above re iSCSI on 100Gb ether) and show no signs of running into any problem that prevents future expansion to terabit speeds. This is important information when comparing oddballs like FibreChannel or LightPeak or whatever to something proven. Inside-the-PC buses like PCI scale reasonably well but rarely more than one order of magnitude in speed before they are totally replaced. So a simple number showing the orders of magnitude of scaling from original inception in its wide deployed form to current standardized maximum would be a helpful number to be sorting on - if you don't have a good reason to use an interface without much history of scaling, you probably shouldn't just to get a few more theoretical extra bits. —Preceding unsigned comment added by 142.177.12.18 (talk) 13:49, 3 January 2010 (UTC)

Cell alignment

The Inception column should be aligned left, not right, as it looks ugly with the refs bulging it out of place. Somebody do it, because all my attempts resulted in the whole table being aligned left.--Spectatorbot13 (talk) 15:30, 5 August 2009 (UTC)

Table sorting of device speeds

Many of the speed tables are sortable, however, since the values list the unit of speed as well as the number, ("125 MB/s" instead of just "125"), the sorting is done alphabetically, not numerically. For example, the sort would place "20 MB/s" as faster than If we standardize the unit at the top of the table, "MB/s" for exmaple, and list the speeds without units, the tables will sort properly. This may make the information less readable though. I vote for sortabiliy over readability. Zm634 (talk) 15:35, 7 August 2009 (UTC)

Agreed.--Spectatorbot13 (talk) 10:56, 8 August 2009 (UTC)

cant see if we standardish all units how it be unreable in fact i say it make it mroe readable, convert to a common stand of either KB/s or MB/s--Andy (talk - contrib) 15:39, 7 August 2009 (UTC)

I agree with Zm634.

The sort-able feature of the table class="wikitable sortable" is currently useless for sorting the numeric values.

The unit should be placed at the top of the column (Mb/s, MB/s, etc..) and only numeric text placed in the cell.

The next question is, does class="wikitable sortable" know how to sort text and numbers?

J_Tom_Moon_79 (talk) 04:29, 18 August 2009 (UTC)

I've set up Template:Ntss to also work with sorting bits and bytes. The template internally works by converting all the values into bits, so for asynchronous values Template:Ntsh with the number of bits can be used. I've manually gone through and updated all the tables to be sortable using these templates. PaleAqua (talk) 17:54, 28 November 2009 (UTC)

Thanks much! J_Tom_Moon_79 (talk) 04:42, 9 February 2010 (UTC)

Audio section

Hello, I added I2S, AC97 and McASP but I don't know how fast they are. Could somebody please fill out the missing information? Thanks! --Micru (talk) 07:32, 25 September 2009 (UTC)

Serial Rapid I/O ??

No mention of SRIO, a fast packet switched serial technology used to connect high end embedded processors and FPGAs. Current used standard is 1.3, which allows up to 4 lanes of 3.125Gbps (10B8B encoded) giving a raw throughput of 10Gbps. New std is out and devices should be forthcoming soon. see [2] Please add this, thx. (80.254.147.84 (talk) 14:18, 2 October 2009 (UTC))

'Bandwidth', 'Data Rate' and 'Speed'

The proper term for bits per second is DATA RATE, not bandwidth. Bandwidth is something else. In well written articles, the term Data Rate is used, especially in technical journals and textbooks where digital radio subjects are discussed. Thus, data rate and analog (radio) bandwidth subjects are more clearly defined.

In addition, the term ‘speed’ is incorrect. ‘Speed’ is first derivative of position (dx/dt) and is expressed in measurements such as miles per hour, feet per second, etc.

The fact that so many have commented on this issue must mean that it has importance. —Preceding unsigned comment added by Rolsenn (talk • contribs) 02:41, 3 November 2009 (UTC)

It makes no difference to me, so I am not anti pro either term, but that a lot of people discuss this issue doesn't signify importance. Not to sound rude, but some people simply have nothing better to do, or there is little else to talk about in the article, thus many people bring up the most obvious issue simply to be constructive and raise legitimate concerns. Is it really important to change title to "List of device data rates" when most people recognize it better as "bandwidth" with respect to a digital device?--Spectatorbot13 (talk) 01:30, 4 November 2009 (UTC)

Given that the correct term "data rate" also very often appears in press release and is far more easily understood by someone not already committed to learning jargon, there is no reason not to rename the article and explain the real meaning of this (and of throughput).

However, there are good reasons why it should be described as a list of "hardware interfaces" or "ports" of which rate/throughput is only one major feature. If the table can be made usefully sortable (by putting everything in metric megabits) then there is nothing lost as it will be possible to list by data rate in one click. However the article probably should cease to pretend to be a "list" and also stop pretending to be useful to make real decisions with, for reasons some others have explained. —Preceding unsigned comment added by 142.177.12.18 (talk) 13:58, 3 January 2010 (UTC)

'Bandwidth' is incorrect language use

Bandwidth is a measurement of frequency, not data throughput, so it is incorrectly used here. This is a common error. —Preceding unsigned comment added by 209.204.169.179 (talk) 11:56, 20 July 2009 (UTC)

It's far too common a usage to be called an error. See wikt:bandwidth sense 3. -- BenRG (talk) 20:20, 20 July 2009 (UTC)

Nevertheless, wouldn't it be wise to use the term throughput instead? It isn't less common and lacks the ambiguity of bandwidth, which is used in computer networks in its meaning of range of frequency as well as of data rate. --92.79.150.6 (talk) 14:22, 23 July 2009 (UTC)

The term throughput seems like a good compromise.
Maybe a preliminary section to the article briefly explaining these word confusions? J_Tom_Moon_79 (talk) 04:42, 9 February 2010 (UTC)

"Bandwidth usage not correct language" - Get Over It

To you purists fussing over the usage of the label "Bandwidth" being incorrect for this article. Have you visited retail electronic stores lately? Will the average lay consumer ask about data through-put knowing the difference between small "b" and big "B"? Hardly. The consumer just asks how fast with what equipment, so titling this article with "Bandwidth" is totally appropriate for an audience curious about general data speeds. —Preceding unsigned comment added by 67.180.161.243 (talk) 22:13, 19 October 2009 (UTC)

Wikipedia is not a retail electronic store. J_Tom_Moon_79 (talk) 04:42, 9 February 2010 (UTC)

Metric Units for speed? Not really

The beginning of this article states that the all the quoted bandwidths are in metric (x1000) units - however, if you do the math, the per-byte measurements are x1024, as they should be; we need to explain this so readers don't confuse the fact that per-bit measurements are x1000 and per-byte measurements are x1024 -- 148.63.161.214 (talk) 00:16, 27 December 2009 (UTC)

They should actually all be metric and not kibi units since we are talking data-rate here. Looks like the octet (8-bit byte) per second values seem to be a mixture between both and should be fixed where wrong. I could probably create a template that does the calculations automatically in most case. I'll look at it when I get back home. PaleAqua (talk) 06:31, 29 December 2009 (UTC)

Often the labeled datarate and the actual datarate don't match no mater which scaling is used. Mux'ing systems, like telcos and the Internet in general use binary scaling simply because it fits much cleaner than decimal. Generally, when it comes to digital data-streams, binary units should be assumed unless known otherwise. Evanh (talk) 10:37, 12 December 2010 (UTC)

In datacom/telecom literature, modem specifications, etc, 1 kbit/s bit rate has always meant 1000 bit/s. Also before 1998 when kbit was redefined as 1000 bits and kibibit was introduced by ISO. 1 kByte/s is however ambigous, but I suggest that we follow new standards. Linux and OS X now measure file size as 1 kByte = 1000 Byte, disc manufacturers have always used that definition, while Microsoft Windows and RAM memory manufacturers still define 1 kByte = 1024 Byte.

I wouldn't be so sure about the bit rate being so well define but either way it doesn't apply to the mux's simply because they go up in powers of two and yet it's still called, for example, 2Mb/s even though it isn't a decimal scale. So, best case scenario would be neither decimal nor binary. Evanh (talk) 23:45, 14 December 2010 (UTC)

When it comes to computing in general, including the Internet, binary is always assumed unless otherwise specified. I'd be happy with renaming everything to KiB/MiB/GiB ... but it does seem a bit redundant when a K is already 2^10. Evanh (talk) 23:45, 14 December 2010 (UTC)

Labeled data rate is a well-defined measure. Normally it implies physical layer net bit rate. The reason that datarate typically do not match the maximum throughput or goodput is that datarate typically includes payload at layer 2 and higher in the OSI model, while throughput is measured at a reference point somewhere higher in the OSI stack. Goodput only includes useful data. Data rate is sometimes confused with transmission rate (gross bit rate), which also includes physical layer overhead. (Are there rules against changing discussion thread headings? My attempt to make the heading more correct was reverted.)Mange01 (talk) 10:44, 14 December 2010 (UTC)

I'd suggest the main reason is because the exact rate, just like an exact size, is not important for marketing. So an easy round number is chosen. So, in turn, the scale of measure is also not important for marketing. That is, until, someone gets sued for it ... Not a good idea for Wikipedia to go around redefining standards based on product labeling! Evanh (talk) 23:45, 14 December 2010 (UTC)

Regarding the heading, the OP is disputing the global assertion of decimal scaling for the speeds. I think it's to the point. You could change "speed" to "data-rate" without changing the meaning but you deleted the disputed challenge also. I have no idea what rules there are other than it's considered bad to modify others' talk. Evanh (talk) 00:12, 15 December 2010 (UTC)

I just reverted an edit from Feb 18 2011 which wrongly assumed that "in the ICT world you should use 1024". It is well-established that data transfer rates use decimal prefixes. The table makes it very clear: A 14.4kbps modem is a modem that sends 6 bits at a time at a rate of 2400 bauds, giving 14'400 bits per second = 14.4kbps. Where kbps means 1000 bits per second, not 1024. Note also the list of examples in Data_rate_units, which confirms that for instance, SATA 2 has a transfer rate of 300,000,000 bytes per seconds, which is 300 MB/s and not 300 MiB/s. Ratfox (talk) 16:34, 18 April 2011 (UTC)

Well spotted - in telecommunications and most ICT scenarios binary prefixes don't make sense nor are they regularly used (outside MS Windows). Zac67 (talk) 17:32, 18 April 2011 (UTC)

Consistent data across tables

In some tables you list PCI-express 1.0 as being 2000mbit, and others are listed as 2500mbit.

Can you please stick to a standard across all interfaces and agree on it.

With PCI-Express 1.0 the signalling rate is 2500mbit, but the avalable datarate that is usable is 2000mbit

So if you where to say PCI-Express 1.0 is 2000mbit everywhere cause that is what you can push though it? Then I believe the iscsi over tcp/ip should be modified also, as you can't actually pump 100mbit, 1000mbit, 10gbit of iscsi traffic over that network, cause of ip, tcp, iscsi overheads, and inner packet spacing, mac, ...

74.95.90.234 (talk) 15:03, 29 December 2009 (UTC)

probably should be best to alter the tables to list only the maximum thoerical speeds (even if they are wrong, as signaling rates), and then add remarks to the bottom of each table mentioning the real speeds--LPCA (talk) 23:09, 9 June 2010 (UTC)

USB 3 is listed at 4.8 Gb/sec in the main text but 5 Gb/sec in the relevant table. I believe the former to be correct but being unable to absolutely ascertain the correct value which is nowhere to be seen in a relevant position at www.usb.org I'll leave that alone for the meanwhile.--Misterakko —Preceding undated comment added 05:25, 5 June 2011 (UTC).

Speed for ATA interface (see: Storage) is given as MBites/sec for each flavor up to UDMA/33, then is given as MBytes/sec from UDMA/66 and above. As a consequence, according to the table, UDMA/33 performs at 33MBytes/sec and UDMA/66 at 8,25MBytes/sec, which is non sense. I am going to update UDMA/66 /100 and /133 to 66,7MBytes/sec 100MBytes/sec and 133MBytes/sec respectively. --Golffies (talk) 00:36, 6 September 2011 (UTC)

mark abandoned/obsolete interfaces/protocols

There are also some of these that are simply no longer sold on any new equipment, and others abandoned entirely by their only sponsor before widespread commercial deployment (like QuickPath Interconnect which Intel has abandoned in favor of PCIe 3.0 and LightPeak).

i think not because all kinds of users use this wiki, not just the ones who own recent hardware, but also the ones who use the older hardware. also, wikipedia is an encyclopedia, and encyclopedias are known to aggregate knowledge. how would we feel if suddenly someone erased the egyptian, greek and roman articles (to name a few), because today we build in a different way, using concrete, steel, wood and glass, and back in the day, they did it with stones? their constructions are "obsolete", but the story matters. besides, they still stand and work, just like my 13yo computers that use ISA, PCI, Socket 7 and SIMM slots. let's stick to comparing the old, the current and the new, and not throw out in the garbage what's old--LPCA (talk) 23:17, 9 June 2010 (UTC)

missing..

This list is missing at least:

• Infiniband
• G.hn —Preceding unsigned comment added by 142.177.106.219 (talk) 11:53, 31 December 2009 (UTC)
• Futurebus Cgmusselman (talk) 03:09, 23 January 2011 (UTC)
• Secure Digital - at storage Alecssicius (talk) 21:27, 12 January 2012 (UTC)

Video cards

Some high-end video cards should be added. they reach much higher memory bandwidths then main memory (far exceeding 100 GB/s). --MrBurns (talk) 02:04, 2 February 2010 (UTC)

Table clarity

What's up with the speed rates on these columns? For instance: ADSL 8,192/1,024 kbit/s Well, which is it? 8,192 or 1,024? Is one download & the other upload? The table doesn't say. —Preceding unsigned comment added by 68.214.28.117 (talk) 01:39, 9 February 2010 (UTC)

symbol rates of effective data rates

For interfaces that employ line codes such as trellis coding, 8B/10B and 64B/66B, what rates should be listed - symbol rates (total number of bits transmitted) or data rates (bit rates after decoding and error correction)? I don't see a consistent pattern of handling this across all these tables. --188.123.237.4 (talk) 08:59, 10 February 2010 (UTC)

THere are five different bandwidth measures of interest: net bit rate (most important), gross bit rate, symbol rate (in baud), maximum throughput and spectral bandwidth (occupied analog bandwidth in Hertz). Is it okay to create separate columns for them? In some of the other lists of bandwidths at Wikipedia these numbers are provided. Maximum throughput and spectral bandwidth are not always well-defined and must be measured in experiments, and consequently need good sources.

A column with the year of introduction would also be interesting. Then we could plot the development over time. It is easier to find the year when the standard was ratified, but more interesting to find the year the first commercial product was available.Mange01 (talk) 11:08, 14 December 2010 (UTC)

More

It might be nice to compliment this with a comparison of demands for bandwidth: voice call (in kpbs) skype video calls, SDTV, HDTV, Full HDTV, analog FM radio... —Preceding unsigned comment added by Fulldecent (talk • contribs) 19:07, 10 March 2010 (UTC)

Additional details

This project is great! I wish for details like sustained speeds and burst speeds be distinguished in storage devices, or where applicable. Also, it would be great to have the different Fiber Optic cables (single mode and multimode MFF) as applied to FC and other technologies be included in the list with their maximum corresponding distance (length), baud rate, and bit rates. Also, grouping items by category as in Ethernet, SCSI, FC, or at least sorting them alphabetically would make it easier to read and appreciate the numbers presented. However, data redundancy might be required in another table.

With the ability to create PDF files, this project and this site is a true winner. -perc- 112.201.74.8 (talk) 07:25, 4 June 2010 (UTC)

DVI Discrepancy

On the DVI page, it says the bandwidth of a single link DVI is about 3.95 Gbits/s, but on this page, it says around 4.95 Gbits/s. So which is it? —Preceding unsigned comment added by 68.79.135.153 (talk) 04:27, 26 July 2010 (UTC)

8 or 10 bits per byte?

The table defines 1 byte = 10 bit for all modems. This was perhaps true for very old modems, since they were based on asynchronous communications (8 data bits, one start bit, one or two stop bits and sometimes a parity bit), but is not correct in more recent modems. Do you know in which modem standard? We need a source for this instead of footnote 3.

Actually, in the old asynchronous modems, the word lengths could be configured to 7 bits, meaning that the net bit rate was 7/9 of the gross bit rate if no parity bit was used. Old modems only offered half duplex communications, which also should be indicated by the table. (I also asked questions about these issues at Talk:Modem#8_or_10_bit_per_byte.3F ) Mange01 (talk) 18:52, 2 January 2011 (UTC)

Please change the unit for PCIe as used in the notes from Gbit/s to GT/s (GigaTransfers)

Notes section items 38 & 39

38 ...... PCIe 2.0 effectively doubles the bus standard's bandwidth from 2.5 Gbit/s to 5 Gbit/s

39 ...... PCIe 3.0 increases the bandwidth from 5 Gbit/s to 8 Gbit/s and switches to 128b/130b encoding

Source, Page 27 of "PCI-SIG Technology Seminar" presentation in PDF at PCISIG.com: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=fbefb81d7207cb4f7c42a4525fe6aa76c3bb1a40

Excerpt:

- Introduced at 2.5GT/sec [Spec Revs 1.0, 1.0a, 1.1]
  - Commonly called 2.5GHz
    - PCI-SIG eventually adopts GigaTransfers per Second (GT/s) terminology

Hawkwindeb (talk) 02:39, 12 October 2011 (UTC)

Correction completed Hawkwindeb (talk) 03:26, 9 November 2011 (UTC)

Referencing note typo for PCI Express 2.0 (x32 link)

"PCI Express 2.0 (x32 link)[39]" should be referencing note 38 not 39 Hawkwindeb (talk) 02:47, 12 October 2011 (UTC)
Correction completed Hawkwindeb (talk) 02:57, 9 November 2011 (UTC)

Please add a row for: PCI Express 3.0 (x8 link)

Should be stated as:

Technology	Rate (bit/s)	Rate (byte/s)	Year
PCI Express 3.0 (x8 link)[39]	63.02 Gbit/s	7.9 GB/s	2011

Reason is that x8 is an important listing for PCIe 3.0 especially in the server market and should be represented. Note: Rate stated as estimate using 1/2 of stated rates for PCIe 3.0 (x16) Hawkwindeb (talk) 03:10, 12 October 2011 (UTC)

SD card and SDIO

There should probably be entries for SD cards in the Storage section, and SDIO in the Portable section. They're relatively common formats, and certainly appear next to other buses on many laptops and in cameras. — Preceding unsigned comment added by 212.44.19.5 (talk) 16:15, 30 March 2012 (UTC)

I agree. I came to this page initially looking for a comparison between SD speeds and that of other devices. GeiwTeol 17:07, 26 April 2012 (UTC)

need to add hdmi 1.4

http://en.wikipedia.org/wiki/HDMI#Version_1.4

Says total thoroughput is 8.16 Gbit/s with 8b/10b overhead removed — Preceding unsigned comment added by 93.97.195.139 (talk) 22:09, 3 May 2012 (UTC)

SATA 3.0 speed wrong?

Sorry, but this is unclear. Under STORAGE the speed of SATA III is quoted as follows: Serial ATA 3 (SATA-600)[44] 4,800 Mbit/s while the Wikipedia article of serial ATA declares a speed of 6 Gbit/s. Which one is true? — Preceding unsigned comment added by 217.162.130.68 (talk) 09:36, 5 June 2011 (UTC)

For now I've adjusted the conversion Mbit/s -> MB/s — Preceding unsigned comment added by GianoM (talk • contribs) 15:21, 16 May 2012 (UTC)

Please read up on Serial ATA. The physical rate is 6 Gb/s which is 8b10b encoded, so it's a usable rate of 4.8 Gb/s = 600 MB/s. Zac67 (talk) 20:30, 16 May 2012 (UTC)

sata 2

I believe I am correct in assuming SATA 2 should have a "MB/s" of 150, since we're measuring in bytes, which should exclude transfer overhead? Rogerdpack (talk) 20:15, 23 July 2012 (UTC)

conventional transportation missing from WAN table

How much intercontinental bandwidth do you get by loading a container ship or CSX train full of 1TB hard drives? I'm pretty sure that IBM moves truckloads of backup disks around. — Preceding unsigned comment added by 108.18.250.35 (talk) 17:16, 13 August 2012 (UTC)

Yes, this should definitely be in the list. Many industries use various means to physically move huge files. For years carrier pigeons were used to move large chip designs around between facilities on microfilm.

Random access memory

• Do we need all these non-JEDEC/non-standard RAM types? They're not even listed in their corresponding articles.
• There's no clock speed for async DRAM. Unless there's some explaining to a somewhat equivalence this needs to be removed.

Zac67 (talk) 18:15, 11 September 2012 (UTC)

Missing interfaces

Would it be possible to add the NUMAlink and Interlaken_(networking) interconnects, or is there some reason for them not to appear in this table? 140.78.198.22 (talk) 12:01, 4 February 2013 (UTC)

SAS 2 and SATA-600

The table shows both SAS 2 and SATA-600 as having the same MB/sec but different Mbit/sec bandwidth. This seems suspicious, as the conversion to/from MB/s and Mbit/s is just a factor of 8.

Storage

Technology	Rate (bit/s)	Rate (byte/s)	Year
Serial Attached SCSI (SAS) 2	4800 Mbit/s	600 MB/s
Serial ATA 3 (SATA-600)	6000 Mbit/s	600 MB/s

71.174.87.54 (talk) 17:25, 30 October 2012 (UTC)

The confusion spawns here:

[SATA 3] runs with a native transfer rate of 6.0 Gbit/s, and taking 8b/10b encoding into account, the maximum uncoded transfer rate is 4.8 Gbit/s (600 MB/s).

Since this chart shows actual throughput, I believe the 4.8 Gbit/s speed should be used? It cannot be left as-is.

174.100.201.240 (talk) 10:17, 27 December 2012 (UTC)

If you want actual throughput, then bytes per second is plenty. I think that the bits per second should be the real transfer bit rate including overhead, especially in the case of SATA and SAS since they're literally marketed by transfer rate instead of effective bandwidth. — Preceding unsigned comment added by 174.54.132.35 (talk) 07:47, 22 February 2013 (UTC)

Missing: the slow, one-way LF - VLF - ELF RTTY links to submarines.

Someone's gotta add them! Spamhog (talk) 10:32, 11 July 2013 (UTC)