Zeros are round like the wire so they can stack nicely.
Ones need to be put through the wire length-wise meaning they take up more space.
this post was submitted on 08 Jul 2025
279 points (98.6% liked)
Microblog Memes
8452 readers
2942 users here now
A place to share screenshots of Microblog posts, whether from Mastodon, tumblr, ~~Twitter~~ X, KBin, Threads or elsewhere.
Created as an evolution of White People Twitter and other tweet-capture subreddits.
Rules:
- Please put at least one word relevant to the post in the post title.
- Be nice.
- No advertising, brand promotion or guerilla marketing.
- Posters are encouraged to link to the toot or tweet etc in the description of posts.
Related communities:
founded 2 years ago
MODERATORS
Finally, an answer that makes sense.
Is that what happens in network congestion: a 1 bit gets in the wire sideways and takes a while to dislodge?
Yes. When that happens a network engineer has to blow through the cable, that's why it causes lag
And since they are round-ish it does not matter so much which way is up when you stack them. A computer will always recognize them as zeros.
A one has to be somewhat close to the right way up (or upside down works too).
The 1s get stuck more often because they have a serif
...it is a series of tubes!
Lesson #3 on why Baud/s != Bit/s
Lots of serial protocols use stuff bits at the data link layer. The data itself is the clock and if there is no change in the data, the clock is lost. So they after every 4 or so consecutive 0s it adds a fictitious 1 to make sure the recipient's clock is synchronized.
Doesn't USB use manchester encoding like ethernet? So you have a consistent clock frequency it's just weather the data edge is before or after the midpoint.
Hello from Manchester! 👋😃🇬🇧
Beats me. I just know that serial protocols do all kindsa fun stuff at the data link layer to maintain data integrity. Stuff bits, optional parity bits, weird timing changes.
Everybody knows 0s take more pixels to draw and are therefore heavier than 1s.
It's just common-sense physics, folks.
Surely that only works on a USB that is already zero'd out (meaning nothing to change)?
I wonder if this benchmark holds true on a USB that has seen some action and needs to commit large number of zeroes in random dereferenced space?
This is reading, not writing. USB sends a dummy zero every few consecutive 1s for framing purposes. If you want the details Ben Eater has a great video on it.
This is reading, not writing
Ah I see thanks
Ben Eater has a great video on it.
I'm not watching a video, but appreciate the pointing in the right direction
USB sends a dummy zero every few consecutive 1s for framing purposes
Huh, TIL about Bit-Stuffing and Framing Bits
Bit stuffing is the insertion of non-information bits into data ... is used for various purposes, such as for bringing bit streams that do not necessarily have the same or rationally related bit rates up to a common rate
Framing is the process by which, while receiving a stream of fixed-length frames, the receiver identifies the frame boundaries, permitting the data bits within the frame to be extracted for decoding or retransmission. A common practice is to insert in a dedicated time slot within the frame, a noninformation framing bit that is used for synchronization of the incoming data with the receiver.
They're reading from the USB into /dev/null (effectively throwing the read data away), not writing