Asahi Lina (朝日リナ) // nullptr::liveJul 8

Yes, a file full of zero bits transfers faster over USB2.0 than a file full of one bits.

I've known this forever but it still feels ridiculous when you actually test it and it's true!

USB truly is cursed.

Show threadEmber ​Jul 8
@lina does it interpolate between the speeds? like, would sending a 90% zeros file be faster than a pure random file?
Show threadAsahi Lina (朝日リナ) // nullptr::live
@Ember It depends on the distribution of the bits. A file that is 90% zeros all in a row and 10% ones all in a row (1.6% overhead) would actually be slower than a pure random file that is 50/50 (0.8% overhead).
Jul 8 at 8:36amWeb
×
Asahi Lina (朝日リナ) // nullptr::liveJul 8

Yes, a file full of zero bits transfers faster over USB2.0 than a file full of one bits.

I've known this forever but it still feels ridiculous when you actually test it and it's true!

USB truly is cursed.

Show threadAdrian TombuJul 8
@lina But... why? 😳
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@to Because USB 2.0 has to throw in an extra dummy zero bit every 6 consecutive one bits or else it loses its place in the data!
Show thread5225225Jul 8
@lina @to i'm surprised that doesn't also apply to long spans of zeros (so 0b01010101 would transfer the fastest of them all)
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@5225225 @to It's NRZI encoded so a long span of zeros is actually sent as 0101010101!
Show threadCloudmom ColetteJul 8

@lina @5225225 @to I'm so glad I'm moving from USB to ethernet on my side project for data transmission

Give me UDP before USB ever again

Show threadCloudmom ColetteJul 8
@lina @5225225 @to luje: I was DISMAYED to not be able to beat 2Mbit of goodput on that project. Part of it was the STM libraries not having a good USB implementation for their own baked in transciever but mostly its just a nightmare to try to squeeze performance out of. Since I was facing interacting with an external PHY either way— ethernet seemed far less intimidating and problematic
Show threadWilfried KlaebeJul 8

@lina The USB 3 high-speed pairs use something better, nor?

@5225225 @to

Show threadMarcus MüllerJul 8
@wonka @lina @5225225 @to I mean, yeah, USB 3 uses 8b/10b in USB3 (or 128b/132b in errr USB 3.2 Gen 2×1 and 2×2, but not in 1×2) as line code.
Show threadSamantaz FoxJul 8

@lina @to Oh, so kinda like bit stuffing in CANbus where an extra bit of the opposite level is added after 5 consecutive bits of the same value.

However I don't understand why in USB it only applies to ones and not zeroes.

EDIT: Just reat the other post about NRZI coding, it now makes perfect sense! But that remains cursed nonetheless x)

Show threadPete Alex Harris🦡🕸️🌲/∞🪐∫Jul 13

@SamantazFox @lina @to

The line between makes perfect sense and deeply cursed is where computer science thrives.

Show threadMaypop the DragonJul 8
@lina @to why six
Show threadMaypop the DragonJul 9

@lina @to hey undyne what is one more than the number of consecutive 1 bits that can be sent over usb 2.0 before sending a dummy 0 bit

#undertale #shitpost

Show threaddoragasuJul 8
@to @lina Google "bit stuffing". That's the reason.
Show threadPortabelloBelle🚚🇪🇺🏳️‍⚧️Jul 8

@to @lina

1s are heavier 😁

Show threadPortabelloBelle🚚🇪🇺🏳️‍⚧️Jul 8

@to @lina

Speaking of weight, does physical memory get heavier the more data you add to it?

Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8

@ArabellaLovejoy @to Take this with a grain of salt, but I get that a modern SSD using 3D NAND gains around 0.05 picograms per terabyte of data stored. 0s are heavier and an empty SSD is all 1s.

Roughly going by the cell geometry and electron density mentioned in this paper, which works out to around 300 electrons per programmed cell, taking 150 as an average (whitening) and assuming TLC flash: https://www.jstage.jst.go.jp/article/elex/17/23/17_17.20200335/_pdf

This does not apply to RAM since that uses capacitors, so you take electrons from one side and move them to the other, so no net weight change.

Show threadRäucherkäseJul 8
@lina @ArabellaLovejoy @to Nitpick: DRAM is capacitors, but SRAM isn't. On the other hand, latches are usually symmetric, so they may balance out nicely, too.
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@smochi @ArabellaLovejoy @to SRAM is also (gate) capacitors, just statically connected to the voltage rails via a feedback path instead of dynamically refreshed ^^
Show threadPortabelloBelle🚚🇪🇺🏳️‍⚧️Jul 8

@lina @smochi @to

When I posed this question, I was expecting to get a chuckle, or perhaps a bit of philosophy, I'm astonished that I got this wonderful information in response to what I thought was a bit of whimsy.

Show threadCassandrichJul 9
@ArabellaLovejoy @lina @smochi @to There's probably also some cursed phenomenon by which the entropy difference imposes a mass difference.. 🙃
Show threadC++ Wage SlaveJul 9

@dalias

I'm not sure whether you were joking, but, yes, there is a plausible theory that information has mass:

https://bigthink.com/hard-science/dark-matter-theory/

@ArabellaLovejoy @lina @smochi @to

There is no dark matter. Instead, information has mass, physicist says

Is information the fifth form of matter?

Big Think
Show threadRäucherkäseJul 8
@lina @ArabellaLovejoy @to Strictly speaking, the gate capacitors do play a role, but they are not exactly designed to be the information carriers. If you build an SRAM cell with BJTs, it's the small hold currents and the transistor's switching thresholds that store the information. The same is true with FETs - the hold currents will just keep the gate capacitors in charged/discharged state continuously. But you're not wrong - you can totally look at this from different angles.
Show threadEragonJul 8
@lina This is so cursed.
Is it still true in USB 3.0 (or 3.1 or any other newer revisions with their cursed naming scheme)
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@eragon It's true with all 480Mbps and slower devices. For USB 3.0 SuperSpeed instead they just did a misleading marketing and the "5 Gbps" they advertise are instead 4 Gbps, but at least it's independent of what data you send. See my previous thread for some discussion on that...
Show threadEmber ​Jul 8
@lina does it interpolate between the speeds? like, would sending a 90% zeros file be faster than a pure random file?
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@Ember It depends on the distribution of the bits. A file that is 90% zeros all in a row and 10% ones all in a row (1.6% overhead) would actually be slower than a pure random file that is 50/50 (0.8% overhead).
Show threadGerard BraadJul 8
Everybody knows zero weighs nothing... ;-)
Show threadletterbeenJul 8
@lina
So, theoretically, you could make a faster transfer mechanism that counted the amount of 0s, and conditionally flipped every bit before and after the transfer? You would have to read the whole file twice though, so probably not a practical solution 😅
Show threadWilfried KlaebeJul 8

@letterbeen or "just" use a compressing content transfer encoding like gzip 😉

@lina

Show threadCassandrichJul 9
@letterbeen @lina Easier than that, just encrypt it.
Show threadmmu_manJul 8
@lina I suppose the encoding used forces a maximum number of contiguous ones by inserting symbols or something… or there's a special empty block frame like sparse files on disks?
Show threadAsahi Lina (朝日リナ) // nullptr::liveJul 8
@mmu_man It inserts a zero every six consecutive ones.
Show threadZ̈oé ⛵ WHY2025 📞 4963Jul 8

@lina Few people know it but the reason for this is very simple. While zeroes are round, a 1 has a sharp corner and a hook that could get stuck and damage the insulation around the copper if you would completely fill the line with ones. Instead, sending some zeroes every now and then to flush any stuck „1“ before a clog can develop.

A 0 can be neatly pushed through the copper at high pressure without damaging the cable.

Now you know!

Show threadKaustcVantasJul 8

How did we ever survive in the age without /s tags


#With-gusto-and-panache #apparently
Show threadrastilinJul 9

@kaustcvantas @lina @uint8_t@chaos.social

I think people tend to forget that ironic shitposting is still shitposting.

Show threadStefan EissingJul 8
@uint8_t @lina Should have imagined more complex bits. Then we'd have 0 and i.
Show threadZ̈oé ⛵ WHY2025 📞 4963Jul 8
@icing @lina the problem with i is that it’s often used in for loops so it could get entangled in the software threads, or its value might change unexpectedly and rapidly if it gets into the wrong scope
Show threadEfraim FlashnerJul 8
@uint8_t
Sometimes you have to stop what you're doing and find the dots which have fallen off the top of the is. It's been proven that despite the 1s getting suck on corners it's still faster than searching for the dots.
@icing @lina
Show threadlp0 on fire Jul 8
@efraim @uint8_t @icing @lina, ı·iıi·.ı0i·iı
Show threadC++ Wage SlaveJul 9

@uint8_t

In addition, if the USB cable is kinked, the dot of the i can snap off the body. Now you have two bits where there was one before, causing a buffer overflow.

@icing @lina

Show threadF4GRX SébastienJul 9
@icing @uint8_t @lina thats done with QPSK but not on usb links.
Show threadRäucherkäseJul 9
@icing @uint8_t @lina It would make interface circuitry much more complicated, because you'd have to consider every signal from an imaginary angle.
Show threadStefan EissingJul 9
@smochi @uint8_t @lina This seems to happen on the internet a lot already.😌
Show thread2¢Jul 8
@uint8_t @lina Finally, someone explains NRZI so it makes sense!
Show threadF4GRX SébastienJul 9

@Qbitzerre @uint8_t @lina Usual line coding is NRZ, which encodes bits in levels. 1 high 0 low, simple.

But USB is NRZI-S, it encodes bits in level *changes* : https://en.wikipedia.org/wiki/Non-return-to-zero#Non-return-to-zero_inverted

This means a zero is encoded by a level change and a one is encoded by no change. You need bit suffing because USB does not transmit the associated clock, and with no transition in long strings of ones, the receiver would loose sync.

Non-return-to-zero - Wikipedia

Show thread2¢Jul 9
@f4grx @uint8_t @lina ah, clocks! makes me nostalgic for the days of bisync, SDLC, etc. The serifs on the ones were very big in those days. We used axle grease to keep the current loop devices from getting constipated.
Show threadMark T. TomczakJul 8
@uint8_t I am so angry about how close to the actual explanation this is. 😉
Show threadRyan PetersJul 9

@uint8_t @lina my pipes get the same way.

I use drain-0

Show threadSparrowsJul 13
@uint8_t @lina I understand backpressure a little more now.
Show threaddoragasuJul 13
@uint8_t @lina This is, surprisingly, not completely wrong!
Show threadmorphJul 13
@uint8_t are numbers pushed into the cable with the top or bottom first? I can totally see 1’s getting stuck if they’re sent bottom-up, maybe they should make a new protocol that takes numbers shapes into account. Also fonts are a thing, sending 1’s sans-serif should improve the throughput a lot
Show threadBill BraineJul 13

@uint8_t @lina

That’s why we only send files with 0 and O bits.

Show threadJean-Baptiste QuéruJul 8
@lina That was similarly true on the ZX Spectrum, a 0 took 0.5ms whereas a 1 took 1ms.
Show threadAatchJul 8
@lina eh, "cursed" seems a little harsh. The NRZI encoding and bit-stuffing makes sense for real-world scenarios.
Show threadMarcJul 8
@lina gah thanks Lina now "bit stuffing" is in my work Google history
Show threadJanek @ IndieDev.siteJul 8

@lina the USBus is coming

#memes #programmer_humor #funny

Show threadJanJul 8
@lina It’s interesting to see how the standards evolved.
Since USB 3.0 it uses an 8b/10b scheme, 3.1 Gen 2 moved to 128/132b.
Do you know what kind of hardware improvements made this possible? Better clock stability of the transmitters?
Show threadKeenan TimsJul 8
@jangw @lina I'd assume just a desire to keep implementation complexity low to satisfy the Universalness of USB, and since its overhead on random data is less it should have slightly better real world throughput. 8b/10b was in use in the 80s so it was certainly a known option, but implementation is quite a bit more complex than bit stuffing. It was probably more that DC balance and lowering the required channel bandwidth became more critical at higher speeds.
Show threadCarlos SolísJul 8
I wonder if that has to do with the zeroes requiring less voltage to transmit than the ones.
Show threadGreg BrooksJul 8
@lina but what if the 1s were standing up instead of lying down end to end?