You must log in or register to comment.
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.
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
Finally, an answer that makes sense.
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).
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.
The 1s get stuck more often because they have a serif
…it is a series of tubes!
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
Removed by mod
