Talk:USB communications
 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
 | Text and/or other creative content from this version of USB was copied or moved into USB communications with [837997932 this edit]. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
Split
[edit]The previous article was 131 kB and difficult to navigate.
No mention of Thunderbolt 3 capability or generations (definition) as it relates to the versions/standards. — Preceding unsigned comment added by 69.109.246.207 (talk) 17:22, 13 February 2021 (UTC)
minimum transaction latency 940ns???
[edit]Transaction latency section currently says "where using 1-byte interrupt packet results in a minimal response time of 940 ns. 4-byte interrupt packet results in 984 ns.[citation needed]". I quickly searched for a citation for this but couldn't find one. But I saw a lot of places on the internet quoting this Wikipedia page's 940ns claim. I think it is better to delete this claim cause that is a pretty strong claim and there is no citation. Em3rgent0rdr (talk) 09:06, 7 January 2023 (UTC)
- Yes, please remove. The USB 2.0 specs from April 2000 don't support any of that. That claim was flagged in 2015 and has been there far too long. As far as I know, latency is *negotiated* and isn't a fixed period (outside a specific hardware and software setup). --Zac67 (talk) 10:23, 7 January 2023 (UTC)
- I made an edit removing that claim. And since the section then only talked about framing, I changed the section name from "transaction latency" to simply "framing". A hidden comment next to the 940 ns I noticed when in edit mode said "(125 µs/133)" which evaluates to 940 ns...my suspicion is that calculation was only accounting for how much time the bits of the transaction occupied the wire for, but that calculation didn't take into account any host controller and device controller overhead. Em3rgent0rdr (talk) 19:08, 7 January 2023 (UTC)
- Excellent job, well done! I was suspecting something along that line, too. --Zac67 (talk) 19:22, 7 January 2023 (UTC)
- I made an edit removing that claim. And since the section then only talked about framing, I changed the section name from "transaction latency" to simply "framing". A hidden comment next to the 940 ns I noticed when in edit mode said "(125 µs/133)" which evaluates to 940 ns...my suspicion is that calculation was only accounting for how much time the bits of the transaction occupied the wire for, but that calculation didn't take into account any host controller and device controller overhead. Em3rgent0rdr (talk) 19:08, 7 January 2023 (UTC)