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.

Kevin RiggleJul 13
Show threadZ̈oé ⛵

@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!

Jul 8 at 9:29amWeb
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é ⛵Jul 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.