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: jstage.jst.go.jp/article/elex/…
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.
@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.
@smochi @ArabellaLovejoy @to SRAM is also (gate) capacitors, just statically connected to the voltage rails via a feedback path instead of dynamically refreshed ^^
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.
@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.
@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...
@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).
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 😅
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?
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.
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?
A theory: I vaguely remember reading about signal formatting for telecom (probably elderly T1 signaling or similar) where a specific pattern of bits was used for control signals. If the data had this pattern, there was a workaround to allow it.
Perhaps the USB standard has some similar aspect, so the transfer has more overhead as the host has to constantly say “you’re not going to believe this, but there’s some more empty bytes coming.”
@recursive i can only conclude that USB 2 is a 12 Mbps physical layer that was unwillingly stretched to be 40 times faster with very little help to do that
Are there even any other half duplex cabling standards of that speed? Everything else I can think of moved to dedicated tx/rx lanes and better encoding long before (physical or logical like the 1GbE stuff).
Yeah but pushing that speed half duplex is itself part of the cursedness, and why the PHY is designed the way it is. Most well designed modern clock embedding systems are intended for unidirectional links.
@piggo @recursive @whitequark also, wouldn't having a separate differential pair for clock make it even more of a mess, since over a long cable it'd be hard to match the delays?
having the clock embedded, as you're describing, is easier to deal with than having a clock separately, right?
(although PCIe and HDMI do have a separate refclock... but they still do clock-and-data recovery on the data pairs too, right? Is the refclock only to get their PPLs in the right ballpark, to make the CDR lock quicker?)
@wolf480pl @recursive @piggo yes, it's mostly useful for power management (lets you disable the PLLs without worrying it'd take the CDR too long to lock)
it's also used for EMI (refclock is often spread spectrum modulated)
@whitequark @wolf480pl @recursive @piggo You can run PCIe without refclock, just with a separate oscillator on the device side, as long as spread spectrum is not used.
@wolf480pl @recursive @piggo you can do it with the host doing spread spectrum too, you just won't be EMI compliant on the device side (i've seen it done)
@whitequark @wolf480pl @recursive @piggo I thought that config was technically not compliant with the jitter/whatever specs for clock recovery? I'm sure it works anyway for some devices though...
@wolf480pl @recursive @piggo my understanding is that the tolerances on the clocks work out regardless of whether one side does spread spectrum or both
i'm not even sure it could be defined any other way, your elasticity buffer and skip insertion needs to be spec'd for the worst case (and it is, quite tightly in case of PCIe)
I've had to do CE/FCC validation for usb high-speed products before and part of the discussion there was what sort of dummy data to use, because the one-y data radiates a bunch more than zero-y data
That may be the least cursed thing about USB though. One bits commonly take longer to transmit over many different systems, for example on HDLC a zero gets stuffed in after every 5 ones.
The GPD MicroPC 2 is a 7-inch laptop with swivelling touchscreen, Intel N250 chipset, and plenty of ports - will Linux users like it much as the original?
The GPD MicroPC 2 is a 7-inch mini laptop with a 'retina' quality rotating touchscreen, and an Intel N250 CPU - but will Linux love it much as the original model?
I wish I had Linux back on my steamdeck. But because of anti cheat I’m forced with windows, and I don’t think this feature would come to windows, unless the Xbox project for windows adds it.
shapez 2 is a wonderfully chilled factory building sim that recently had a huge upgrade, and hopefully in November it will be ready for the full release.
Climate change and increasing urbanization are causing more and more heat, which is particularly noticeable these days. Locals and tourists are therefore looking for ways to avoid direct sunlight. Of course you can change sides of the road, but this…
Companies That Tried to Save Money With AI Are Now Spending a Fortune Hiring People to Fix Its Mistakes futurism.com/companies-fixing-… C suits are the worse ones. They just think one quarter and how much stock is going up. That is all.
Video Games Europe, a trade association that represents a bunch of major game publishers, have issues a statement pushing back against Stop Killing Games.
They accuse the petitioners of demanding something that they have never demanded and point out negative effects that will never occur. Why are you doing this? Why doesn't the VGE argue honestly? Are they afraid that if they put forward the real arguments, their business model will collapse?
We are increasingly moving towards a world in which I have to buy a new cooking pot every 2 years because the manufacturer has developed a new model and thus deactivated the old one...
If people were smart, they would stop buying AAA games, or even better, pirate them, if we can't legally own our games, then might as well go Yarr Harr Harr on their asses
Note: Piracy it's a completely valid way of boycott
If you think humanity's doomed, a reminder from UNICEF: - Since 1990, annual under-five child mortality has declined by 60%. - Since 2000, the number of children with stunting has declined by 40%. - Safe water is available to 2.1 billion more people than 20 years ago. unicefusa.org/stories/10-ways-…
I bought the book a few years ago, but I found out recently that they've added a free course on Coursera that seems to have all the same materials: coursera.org/learn/build-a-com…
it steps you thru the process of building up a working computer architecture from the most barebones starting point; if you're interested in learning on a lower level how computers work, I'd highly recommend it--it feels rigorous without being unapproachable
Learn how computers work by building one from the ground up in this hands-on course from the Hebrew University of Jerusalem. Explore logic gates, architecture, compilers, and more. Enroll for free.
Chloe has decided she likes my chair. Now I'm sitting in a second chair next to her, because it's what she wants. Knowing what she wants is a luxury. Knowing she's happy is a joy.
Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
Adrian Tombu
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Adrian Tombu • • •5225225
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •0b01010101would transfer the fastest of them all)Asahi Lina (朝日リナ) // nullptr::live
in reply to 5225225 • • •Wilfried Klaebe
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •The USB 3 high-speed pairs use something better, nor?
@5225225 @to
Samantaz Fox
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •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)
PortabelloBelle🚚🇪🇺🏳️⚧️
in reply to Adrian Tombu • • •1s are heavier 😁
PortabelloBelle🚚🇪🇺🏳️⚧️
in reply to PortabelloBelle🚚🇪🇺🏳️⚧️ • • •Speaking of weight, does physical memory get heavier the more data you add to it?
Asahi Lina (朝日リナ) // nullptr::live
in reply to PortabelloBelle🚚🇪🇺🏳️⚧️ • • •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: jstage.jst.go.jp/article/elex/…
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.
Räucherkäse
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Räucherkäse • • •PortabelloBelle🚚🇪🇺🏳️⚧️
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@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.
Räucherkäse
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Eragon
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Is it still true in USB 3.0 (or 3.1 or any other newer revisions with their cursed naming scheme)
Asahi Lina (朝日リナ) // nullptr::live
in reply to Eragon • • •Ember
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Ember • • •Gerard Braad
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •letterbeen
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •mmu_man
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to mmu_man • • •Z̈oé ⛵
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •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!
Jean-Baptiste Quéru
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Aatch
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Marc
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Janek @ IndieDev.site
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •the USBus is coming
#memes #programmer_humor #funny
Jan
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •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?
Greg Brooks
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •MacBalance
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •A theory: I vaguely remember reading about signal formatting for telecom (probably elderly T1 signaling or similar) where a specific pattern of bits was used for control signals. If the data had this pattern, there was a workaround to allow it.
Perhaps the USB standard has some similar aspect, so the transfer has more overhead as the host has to constantly say “you’re not going to believe this, but there’s some more empty bytes coming.”
recursive 🏳️🌈
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •✧✦Catherine✦✧
in reply to recursive 🏳️🌈 • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •Are there even any other half duplex cabling standards of that speed? Everything else I can think of moved to dedicated tx/rx lanes and better encoding long before (physical or logical like the 1GbE stuff).
Edit: Oh, right, FireWire 400...
✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •Piggo
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Piggo • • •Wolf480pl
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •also, wouldn't having a separate differential pair for clock make it even more of a mess, since over a long cable it'd be hard to match the delays?
✧✦Catherine✦✧
in reply to Wolf480pl • • •@wolf480pl @piggo @recursive you would have two pairs, one in each direction, with clock embedded in each
(this is how USB 3 works already, like PCIe and SATA and SGMII and basically every other high speed protocol since 2005 or so)
Wolf480pl
in reply to ✧✦Catherine✦✧ • • •@whitequark @recursive
I was referring to @piggo 's
> because the clock sync is in-band, right?
having the clock embedded, as you're describing, is easier to deal with than having a clock separately, right?
(although PCIe and HDMI do have a separate refclock... but they still do clock-and-data recovery on the data pairs too, right? Is the refclock only to get their PPLs in the right ballpark, to make the CDR lock quicker?)
✧✦Catherine✦✧
in reply to Wolf480pl • • •@wolf480pl @recursive @piggo yes, it's mostly useful for power management (lets you disable the PLLs without worrying it'd take the CDR too long to lock)
it's also used for EMI (refclock is often spread spectrum modulated)
Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@wolf480pl @recursive @piggo my understanding is that the tolerances on the clocks work out regardless of whether one side does spread spectrum or both
i'm not even sure it could be defined any other way, your elasticity buffer and skip insertion needs to be spec'd for the worst case (and it is, quite tightly in case of PCIe)
artemist
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Az
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Markus Osterhoff
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Kees N ✅
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •(yes, I'm getting old).
Ingrid
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Christian Berger DECT 9314
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •