Jump to content

Talk:List of interface bit rates/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

Referenced to just the US NIST and radio station WWVB. Someone should add references for at least the links for the main European (MSF, DCF77)and Japanese (JJY) stations, as their use is more pervasive than WWVB's. Spamhog (talk) 10:32, 11 July 2013 (UTC)

Add more or less software-defined modes / protocols / waveforms?

Many wireless protocols are implemented in software + FPGA designs, not necessarily nailed in a hardware layer. I am not fully aware of the layer hierarchies but why then not add some modes that exist in some kind of Software Defined Radio, defined as spectra and waveforms, defined at baseband (some at audio baseband) etc? STANAG 4285, STANAG 5066, JT65, WSPR, PACTOR or any of those referenced here http://maser.com.au/latest/images/nalos_narrowband_location_system_sml.pdf Spamhog (talk) 23:50, 11 November 2013 (UTC)

GDDR5

GDDR5 is missing, see e.g. List_of_Nvidia_graphics_processing_units#GeForce_700_Series. User:ScotXWt@lk 22:20, 23 June 2014 (UTC)

Line rates and usable net rates completely messed up

Sorry, but this article is a pretty mess without the possibly important distinction of line (signalling) rates and net (usable) rates. In the cases of PCIe, SATA and such, the nominal bit rates are line rates (bits/symbols on the physical wire) with net rates being up to 20% lower. Other standards like Ethernet are identified by their net rates and usually use higher line rates (1000BASE-CX, -SX, -LX, ...).

Could we possibly have a marker to show if line rate or net rate is indicated? Or even split the rate column in two? Zac67 (talk) 18:19, 22 July 2014 (UTC)

I'd also like to point out that it's a bit odd that wpm and "cps" are used as rates in a table under a section that says all rates are in kilobytes per second.--Ryoushi19 (talk) 21:58, 14 September 2014 (UTC)

Morse code - wrong numbers?

"2000 bits/min or 55.6 bits/s" 2000/60=33.3. Lots of error (not accounted by space between words?). What else is wrong or maybe just some one number? Note Morse code is not full ASCII.. comp.arch (talk) 11:52, 18 September 2014 (UTC)

I don't think you can really compare Morse Code directly to the others. Each dot and dash is more-or-less a bit. Letters have a variable number of dots and dashes. I will try to do some rough calculations. Bubba73 You talkin' to me? 04:36, 19 September 2014 (UTC)
I know, doesn't change the error I pointed out. I could have looked more into it, there was however no source, so I would have to guess if the 2000 number or 55.6 numer was correct. Either is wrong and possibly more, but at least either and I just thought someone who put this in might know.. comp.arch (talk) 11:06, 22 September 2014 (UTC)
The calculation seems to be flawed: 40 words/min with 10 chars/word gives 400 chars/min ≈ 6,67 characters/sec. However, one quinary symbol does not equal 5 bits (which could encode 25 = 32 different messages) but rather log25 ≈ 2.32. Thus, 400 chars = 5400 ≈ 2929 different messages ≈ 929 bits of information → 15.5 bits/s. Zac67 (talk) 18:54, 22 September 2014 (UTC)

The following is my own work, so it should NOT be put in the article. I tried two methods. First, I assumed that a dot or dash is one bit and I used the International Morse Code.

1. The reference gives sending "PARIS" 40 times in a minute. "Paris" has 14 "bits" in this scheme. There is 2/3 of that per second, or 9.3 bits/sec, or 0.0093 kbs.

2. I figured that the average word is six letters long (a lot of small words were left out when sending a telegram). I wrote a program to examine all of the six-letter words in a word list. They averaged 15.86 "bits"/six-letter word, or 2.64 "bits" per character. The reference gives 4 characters per second, so that is 10.56 "bits" per second, or 0.011 kbs.

So both of these are in the neighborhood of 0.01 kbs.

However, I don't see any accurate way to compare Morse code to the others, so unless we find a reference for this, I think it should be left out of the table. Bubba73 You talkin' to me? 04:13, 23 September 2014 (UTC)

I've used the information from Morse code that it uses a (somewhat) five-symbol code which can be thought of to represent 2.32 bits in each symbol, resulting in 15.5 bit/s on the symbol level. Alternatively, you look past the morse code to how much information it transports. The 36 alphanumeric characters plus a word pause are 37 different symbols. log237 equals 5.21 information bits, so PARIS + pause come up to 31.26 bits of information. 40 words/min = 20.84 bit/s. Zac67 (talk) 13:33, 23 September 2014 (UTC)
Yes, it could be looked at from an information theory standpoint. However, you have to take into account the frequency of the letters. Morse code is designed so that frequently used letters are shorter than less-frequent ones. The letters don't carry an equal amount of information. Bubba73 You talkin' to me? 18:00, 23 September 2014 (UTC)
That's what I did on the second calculation (over-all). If you ignore how morse code works it's what it boils down to and it's probably the best approach. From a line code POV there are two distinct encoding steps: first, you encode letters into morse "groups" like "-..." for "b", each consisting of one or more morse "symbols". Second, you put the symbols on the physical line, adding additional symbols "intermediate gap" between morse symbols, "short gap" between plaintext letters and "medium gap" between plaintext words. These additional symbols are required for synchronization between sender and receiver – they serve pretty much the same purpose as clock bits in MFM code. Note that using shorter morse "words" for more frequent letters results in better encoding efficiency (for natural speech) and results in a higher bit rate in the over-all calculation. My first calculation analyzed just the second step (symbol encoding) where you clock out a quinary code. Zac67 (talk) 21:26, 23 September 2014 (UTC)
Yes, but there are too many possible ways to do it, so I think it should be taken out of the table, and perhaps be replaced with "N/A" or put a footnote about it. Bubba73 You talkin' to me? 22:39, 23 September 2014 (UTC)
Yes, could use N/A, but then not even order of magnitude comparison.. I didn't mean to rock the boat that much. Can't we do both. "N/A, depends on words (and the person's talent) but for the word PARIS about X words/sec. (or our unit.. "PARIS "/sec..) could be achieved. That can be translated to bits/sec for that word.. comp.arch (talk) 21:44, 24 September 2014 (UTC)
Yes, put a note explaining. Bubba73 You talkin' to me? 00:17, 25 September 2014 (UTC)
I think we have a consent – I've changed the bit/s and added a ref note explaining the figure. Zac67 (talk) 11:19, 25 September 2014 (UTC)

Linking the units

List of interface bit rates/Archive 4 hasn't experienced the perfect amount of linking of the many types of units. It recently went from no linking to linking them all. The reason why they were all linked has now been fixed so that, in the spirit of WP:LINK, only choice, strategic units need be linked. (Esp. see the first few sections there, WP:UNDERLINK and WP:OVERLINK.)

I've started on the first few tables, but work remains to be done on the rest of the tables. Happy editing! — CpiralCpiral 19:46, 1 August 2015 (UTC)

Even though Module:Val will soon be in put into production here, linking the top and bottom rows of each table will remain valuable, and easily kept intact during the transition away from the temporary template:Ntsgaps. Just change u= to ul= inside {{Ntsgaps|...|u=}}. — CpiralCpiral 07:33, 3 August 2015 (UTC)

 Done — CpiralCpiral 04:47, 7 August 2015 (UTC)

"Template:Val" instead of value on page

From List_of_device_bit_rates#Dynamic_random_access_memory halfway through the line "PC3-13000 DDR3 SDRAM" and onwards "Template:Val" stops working. Is there a maximum number of templates that can be used or what's going on? Is there a feasible workaround? Dragnmn (talk) 18:42, 17 May 2015 (UTC)

Yes it's likely hitting templates limits, this one appears to total inclusion size hence the inclusion in Category:Pages where template include size is exceeded. It's one of the reason the old ntss template used to do hardcoded conversions as when I originally tried doing something similar to Val back in the day it ran into the same type of issues ( though a different limit ). Looks like we either need to reduce overhead of val or possibly get ntss restored and go back to that for the short time. @Jimp: thoughts? PaleAqua (talk) 00:15, 19 May 2015 (UTC)
There isn't a fixed maximum number of templates that can be used on a page. It depends on the templates and the specific uses of them. So, {{val}} needs to be reduced somehow; Lua would probably do the trick. In the meantime, though, something smaller (like {{ntss}} was) would probably be the go. However, simply resurrecting {{ntss}} wouldn't be optimal. The page now uses {{val}} syntax and all that would have to be changed to the old {{ntss}} syntax and then back again once {{val}} is trimmed (or the template limits are changed) to reinstate {{val}} (as would be the ultimate goal). So, we'd be better off with something like what {{ntss}} was which uses the relevant parameters of {{val}}. Jimp 14:56, 19 May 2015 (UTC)
{{Ntsgaps}} has been created with fewer parameters than {{val}} allowing it to be used more times than {{val}}. The parameters {{ntsgaps}} does use are the same as {{val}}, so if {{val}} ever gets a trim, {{ntsgaps}} can easily be switched back to {{val}}. Jimp 16:09, 19 May 2015 (UTC)
Thanks. Also agree that switching to lua seems like the a good long term solution. PaleAqua (talk) 17:29, 19 May 2015 (UTC)
Found a couple typos and it looks like {{ntsgaps}} doesn't handle the unit sort parameter correctly so switched the ones using that to {{val}} for now. PaleAqua (talk) 17:59, 19 May 2015 (UTC)
It should be working now. Jimp 04:46, 20 May 2015 (UTC)
{{Ntsgaps}} now works with the new Val/units setup. — CpiralCpiral 19:37, 1 August 2015 (UTC)
{{Val}} Lua version is almost done, and then we can switch back to Val from Ntsgaps. — CpiralCpiral 19:37, 1 August 2015 (UTC)
The Val version of List of interface bit rates/Archive 4 is back. It's the Lua version of Val, and it loads the page in under 3 sec. — CpiralCpiral 04:57, 7 August 2015 (UTC)

 Done

In the table of different type of Dynamic random-access memory (RAM) throughputs and speeds, wikipedia engine, presumably automatically, assigns a link to first row of each column (to Mhz is assigned article about megahertz, to MB is assigned article about megabytes), but to GT/s (gigatransfers per second) it automatically wrongly assignes article about measurement units called Teslas (which is obviously wrong, because as just mentioned, GT in this context of RAM speed means Gigatransfers, not Gigateslas. Can somebody more experienced and knowledgable please try to fix this issue or report it to someone who can fix this? — Preceding unsigned comment added by Zusurs (talk • contribs) 22:51, 22 April 2016 (UTC)

Well spotted. A link to Transfer (computing) would make more sense, but I don't know how to add it either. For now I have removed the link to tesla. Dondervogel 2 (talk) 23:34, 22 April 2016 (UTC)
I've raised an issue on Template talk:Val#GT/s → Tesla/s, hopefully someone can fix it. --Zac67 (talk) 09:15, 23 April 2016 (UTC)

Memory Clocks were initially incorrect in the Dynamic Random-access memory section

DDR 400 and DDR2 400 share the same base clock in MHz. The generation has no impact on the module's operating MHz. I have cited a source on this subject as and also provided a link to the Memory Divider page on here which is the method that addresses speeds such as DDR3-1600 and how they operate within a computer's internal structure. (A DRAM:FSB (this has actually become the Core Reference Clock or the CPU speed with a 1x multiplier which is typically 200MHz) ratio of 4:1 is required for DDR3-1600 which means 200MHzx4=800MHz) That is not to say that the internal chips do not operate differently between generations, however.

[1] Vedalken (talk) 14:37, 10 November 2016 (UTC)

Hello fellow Wikipedians,

I have just modified 2 external links on List of device bit rates. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:58, 21 May 2017 (UTC)

Infinity Fabric

The Infinity Fabric calculations seem to be incorrect. Even though AMD's website is sorted, theoretical memory bandwidth is not the same as Infinity Fabric bandwidth / rate and would also require multi-core memory access. Not all memory accesses would be traveling the same links or across sockets. — Preceding unsigned comment added by 173.90.0.13 (talk) 20:22, 2 November 2017 (UTC)

Hello fellow Wikipedians,

I have just modified 6 external links on List of device bit rates. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:31, 29 December 2017 (UTC)

PCIe x32

I see there are PCIe x32 values listed on the table. However, I have never seen or heard of a x32 connection or product. Even the PCIe consortium uses x16 when describing the max speeds offered [1]. Is there a cite that these are real? Otherwise this seems like OR and should be removed. Dbsseven (talk) 21:14, 21 February 2018 (UTC)

The Conventions section should mention the baud rate?

Baud (baud rate) should be mentioned (at least) in the section "See also" as a basis for the data transfer? The baud rate describes the transmission speed of symbols (the transmission speed of elements). Normally, an element carries an information amount of several bits, so the baud rate is much smaller than the bit rate (bps). The value of Baud / s is equal to the bit / s only for the binary transfer. Then the (binary)element has only two values, namely 0 and 1.

"Bit" is also a unit for measuring the amount of information. Therefore, the word "bit" is not only used in data transfer rates, bits / sec.

Baud: https://en.wikipedia.org/wiki/Baud

Bit: https://en.wikipedia.org/wiki/Bit Iota~fiwiki (talk) 12:50, 19 March 2018 (UTC)

DDS interface rates

The article should mention the rates for DataPhone® Digital Service[2][3] (DDS), which AT&T introduced in 1974. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:00, 29 June 2020 (UTC)

References

  1. ^ http://www.hardwaresecrets.com/everything-you-need-to-know-about-ddr-ddr2-and-ddr3-memories/
  2. ^ "Dataphone Digital Service", The Free On-line Dictionary of Computing
  3. ^ "How Digital Data Transmission Technology Is Determining the Direction of the Future.", The Free On-line Dictionary of Computing

Missing information

I've added an entry for the Bell 208A and 208B, which are 4800 bps synchronous modems, but I don't know the baud rates or the year. Also, I don't see any 56Kbps modems using a leased line and V.35, which were in use well before V.90; in fact, I don't see the V.35 interface at all. Does anybody have documentation relevant to the missing information? Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:25, 16 July 2020 (UTC)

In the course of tracking down the baud rate (I still don't know the year), I came across a useful resource:

Jack L. Douglass (1984), Applied Data Communications Handbook (PDF), Universal Data Systems, Motorola Inc.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:06, 20 August 2020 (UTC)

Bad title: should be list of interface bandwidths

It's not devices, but interfaces or protocols or ports that are being compared. Very very few devices reach the maximum speeds of the more modern interfaces or protocols, making the distinction very important. If you wish to retain the name then add some actual device bandwidths:

  • typical throughput of a spinning platter hard drive in MB/s
  • typical throughput of various types of lower-speed RAM chips especially those used in SSDs
  • typical throughput of wireless links under different conditions
  • compressed and uncompressed throughput of CD, DVD and Blu-Ray

Among other things it would make the "list" very useful to see if there is any practical advantage in moving to an interface that is much faster, as the device it is connecting to may be too slow typically to make that worthwhile.

Maybe, but that adds other complications. In the (currently discussed) floppy disk rates, that makes some sense, as the idea of FM and MFM is to increase the data rate, without increasing the signal rate (bandwidth). Signal rate depends on bandwidth and S/N ratio, such that with proper coding you can get more data at the same bandwidth. But then you have to explain that. That is why we have things like DDR RAM, to get twice the data rate, for the same bandwidth, though with tighter timing tolerance. You can see the squiggle traces on PC boards, as they get the signal lines the same length. The tolerance is very tight on signal timing! Gah4 (talk) 15:15, 16 September 2021 (UTC)
Sorry, but double data rate isn't about bandwidth of the signal (which it doesn't change), it's about increasing the signal rate without increasing the (separate) clock signal rate. --Zac67 (talk) 20:09, 16 September 2021 (UTC)

your figures are _usable_ bit rates (w/o MFM encoding overhead

A recent revert has the summary: your figures are _usable_ bit rates (w/o MFM encoding overhead. This doesn't make sense. For one, MFM is designed to have less overhead than FM. But also, the HD 5.25in and 3.5in bit rate has to be the same as the 8 inch bit rate, because it is the same. Otherwise, you should only compare FM with FM, or MFM with MFM. The original 8 inch FM format runs 250kb/s, and later MFM at 500kb/s. Then it was reduced by half for 5.25in (and later 3.5in), to 125kb/s for FM and 250kb/s for MFM. Then, using different magnetic material, 5.25in (and 3.5in) HD went back to the earlier (not half) date rate for 250kb/s FM and 500kb/s MFM. Even later, and never caught on, 3.5in ED at twice that rate, so 500kb/s FM and 1Mb/s MFM. (The only one I ever knew to use this is NeXT.) Gah4 (talk) 12:40, 16 September 2021 (UTC)

The full edit summary was The page is about _interface_ bit rates - your figures are _usable_ bit rates (w/o MFM encoding overhead). FM or MFM makes no difference. On the Shugart interface, data is transferred encoded in FM (early formats) or MFM. It's encoded/decoded by the floppy disk controller, residing on the mainboard or controller card. That encoded signal rate is the topic here. FM or MFM carry 50% overhead, so the usable data rate is half the interface rate. You can compare that to SATA's 8b/10b encoding (20% overhead) with e.g. 6 Gbit/s interface rate resulting in 600 MB/s usable rate. MFM reduces the encoded signal's bandwidth, so it enables higher data rates. --Zac67 (talk) 12:54, 16 September 2021 (UTC)
OK, but in that case the HD 3.5in and HD 5.25in have to be the same as the 8in rates, because it is the same interface. But also, you should not list FM and MFM in the table, implying that they are different. The highest flux transition rates are the same for FM and MFM, but the timing tolerance is tighter for MFM. (And precompensation is used to help with that.) Early 5.25in drives did run FM, but they didn't become so popular until the MFM days, with both half the rate of 8 inch data rates. If you just compare FM, it is 250kb/s for 8 inch, 125kb/s for 5.25 (and 3.5) inch, and 250kb/s for HD 5.25in and 3.5in. (FM was rare for the latter, but the controllers will do it.) And finally, twice the HD rate for ED. Gah4 (talk) 13:38, 16 September 2021 (UTC)
Oh, also, 8in and 5.25in HD run at 360RPM, the rest at 300RPM. That is where the 1.2MB vs. 1.44MB comes from. So half the bit rate for 5.25in, along with the 5/6 speed change, means that the bit spacing is about the same as 8in. And running SD and DD disks in HD drives, runs at 300kb/s MFM (or 150kb/s FM) due to the speed change. Gah4 (talk) 15:08, 16 September 2021 (UTC)
8″ floppies used various interface bitrates from 33 to 500 kbit/s – 250 kbit/s was used on the most popular formats. Please recheck your edits. --Zac67 (talk) 20:20, 16 September 2021 (UTC)
The 500's are MFM, which as you note uses the same highest flux change rate as FM. Some formats may never have been used in FM, at least not in commercial hardware, but the controllers that I know will do it. The List of floppy disk formats also considers single/double side, and different block sizes. Tradition of 8 inch floppies was to buy them (low level) formatted. (Not all hardware could do it.) Tradition in 5.25in was to sell them unformatted, until the IBM PC became so popular. I am not against putting in the double numbers of MFM, but it has to be all or none. Gah4 (talk) 20:47, 16 September 2021 (UTC)
Also note that the DEC RX02 format uses FM sector headers with MFM sector data. That means they don't have to redo the low-level format. There is a complication that they have to make sure that no bit pattern that looks like an FM address mark ever appears in the data. Gah4 (talk) 20:47, 16 September 2021 (UTC)
I don't know if it matters, but these are not actually the bit rate limits for the interface, but for the disk itself. It is how close you can put the bits, divided by the linear velocity for the inner track. 8 inch disks are faster because the disk is larger. HD disks use a different magnetic material that allows closer transitions. Gah4 (talk) 21:57, 1 October 2021 (UTC)

WiFi 2.4 GHz / 5 GHz

Should the Wi-Fi section have 2 different columns - for 2.4 GHz and for 5 GHz?

For example, IEEE 802.11n (aka Wi-Fi 4) has both options and the table seems to only list the speed that corresponds to 5 GHz (which is the fastest), so Wi-Fi 4 at 2.4 GHz does not have a representation in the table. — Preceding unsigned comment added by 66.81.168.154 (talk) 09:23, 17 May 2022 (UTC)

GDDR5 and GDDR5X "lanes"

> The total GPU memory bus width varies with the number of memory chips and the number of lanes per chip. For example, GDDR5 specifies either 16 or 32 lanes per "device" (chip), while GDDR5X specifies 64 lanes per chip

Is this correct? It needs a reference. To my knowledge, all GDDR generations specify an aggregate 32-bit data bus channel per chip (possibly divided into smaller channels and/or pseudochannels); i.e. 32 lanes per chip OpenEyeSignal (talk) 03:18, 24 May 2023 (UTC)

Whither wideband?

Shouldn't there be coverage of wideband, a range of speeds used on leased lines? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:12, 26 September 2023 (UTC)

HSSI Interface is missing

Hi editors, maybe you can add the HSSI interface to the list, see here: https://en.wikipedia.org/wiki/High-Speed_Serial_Interface 145.64.134.4 (talk) 14:50, 8 February 2024 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:List_of_interface_bit_rates/Archive_4&oldid=1223031770"