This is a short article about allowing RAM sizes that aren't powers of 2, like 24 GB or 48 GB instead of just the steps 8 GB, 16 GB, 32 GB. I initially thought this was going to be about using multiple states on the data pins to encode more bits per clock.
> Pulse Amplitude Modulation 4-level (PAM4) is a multilevel signal modulation format used to transmit signal. Each signal level can represent 2 bits of logic information.
> NRZ
> Non-Return-to-Zero (NRZ), also called Pulse Amplitude Modulation 2-level, is a binary code using low and high signal levels to represent the 1/0 information of a digital logic signal. NRZ can only transmit 1 bit, i.e. a 0 or 1, of information per signal symbol period.
That's what PAM-4 signaling does. Quaternary signals can be easily broken up to binary ones on the other end because the bits divide cleanly. For the same reason why hexadecimal encodes binary very well.
Signalling systems that don't divide cleanly into a number of bits are more complicated to work with; you need to group bits together into another group of terts[0] and assign states to each. It's less like "picking the bits between the bits out" and more like MFM/GCR encoding for magnetic media.
[0] Ternary digits. No clue what the official name is for these but I am not going to go with the obvious choice.
RAM works on a wide set of bits per transfer so if you're using ternary the mapping will waste very little. Encoding 64 bits in ternary only wastes half a bit in the mapping for example which is less than 1% waste and thus irrelevant. It would even be a good moment to do a mapping that includes ECC by default as ternary signal integrity may very well be trickier and all RAM should have ECC anyway.
Alas, sensing the contents of a DRAM cell in the time allotted is already a tough ask. Having to discriminate between multiple voltage levels would surely make have a nasty latency impact.
OTOH, I believe DRAM senses entire rows at a time -- so after that latency hit, bandwidth might be unchanged.
Any idea if it is even possible with existing capacitive DRAM cells?
There was a Soviet computer called Setun (Сетунь) which used ternary logic, though I can't find much in English about it (and my Russian is very poor).
Thank you, that is probably what I too-vaguely recalled. Burroughs is usually the go-to, in the West, for wacky architecture. If B. could have made a reliable card reader, they might have survived longer.
The phrase is newer, sure, but what was measured hasn't changed. Computers always measured their memory base-2, manufacturers always labeled using base-10.*
If software developers were:
1. Measuring using base-2 (what we would now call Kibi, Mebi, Gibi)
2. Reporting memory using base-10 prefixes (kilo, mega, giga)
Then its those software developers, not advertisements/sales that were the problem. Those prefixes mean a very specific thing accross all fields. Using kilo to mean 1024 instead of 1000 is objectively wrong. No other field does that.
There is a vast difference between those things. The prefixes "kilo", "mega", and "giga" have well-defined meanings that apply to every other field. A kilometer is a 1000 meters, no more, no less. Same with milliliters. Same with everything else.
No other field is coming up with their own meaning of "kilo". The meaning of the metric system is not up for debate. It is defined by the ISU. It is not a "maybe" or an "almost" or situational. It is a hard set of rules to make communication and measurement easier.
What a "byte" is depends on the implementation. It's generally 8 bits but some systems are different. It's not a hard definition like the metric system. No standards organization came together to say a byte must always and only be 8 bits in every situation.
You are comparing two completely different situations.
> No other field is coming up with their own meaning of "kilo".
Neither is the computer field, really. "kilo" by itself isn't affected.
> The meaning of the metric system is not up for debate.
Nobody is saying it's metric, either. "metric kilobyte" is a thousand bytes.
It's like having different tons.
> What a "byte" is depends on the implementation. It's generally 8 bits but some systems are different. It's not a hard definition like the metric system. No standards organization came together to say a byte must always and only be 8 bits in every situation.
If it depends on implementation, why are you insisting a gigabyte is exactly 8 billion bits?
What if I said a "byte" could be 8.59 bits?
> You are comparing two completely different situations.
I don't see it that way, because I'm only making an argument about "gigabyte" as a single unit. (And kilobyte, megabyte, terabyte.) The vagueness of both applies.
>Neither is the computer field, really. "kilo" by itself isn't affected.
Yes, it is. When software measures in factors of 1024 but reports these using metric prefixes (kilo, mega, giga, or their shorthands KB, MB, GB), it's wrong. Imagine if a chemist had 1024 milliliters and reported that as a liter. People would be up in arms about it.
>If it depends on implementation, why are you insisting a gigabyte is exactly 8 billion bits?
I didn't. I never set bits. Bytes.
A gigabyte is always 1 billion bytes, and a Kilobyte is always 1000 bytes. How many bits that is is implementation-dependent.
>What if I said a "byte" could be 8.59 bits?
...there's no such thing as fractional bits.
>I don't see it that way, because I'm only making an argument about "gigabyte" as a single unit. (And kilobyte, megabyte, terabyte.) The vagueness of both applies.
There is vagueness in how many *bits*, but not how many bytes. That is a critical distinction.
Again, the prefixes aren't up for debate. They always mean the same thing. Using them to mean factors of 1024 is just factually wrong.
> Imagine if a chemist had 1024 milliliters and reported that as a liter. People would be up in arms about it.
Not if that method went back decades.
I'll repeat the comparison to tons, since you didn't acknowledge it. Tons are different sizes in different places, and people manage. (And I'm including tonne because it's pronounced the same and has the symbol 't'.)
> I didn't. I never set bits. Bytes.
> A gigabyte is always 1 billion bytes, and a Kilobyte is always 1000 bytes. How many bits that is is implementation-dependent.
So if I handed you a full CD and said it had 350 megabytes, because it has a million sets of 16 bits, you wouldn't object to that?
Or if a drive manufacturer decided they're going to market based on 6 bit bytes, you wouldn't object to that?
> ...there's no such thing as fractional bits.
Sure there is. One printable ASCII character can store six and a half bits. Two of them can store thirteen bits. You can also entangle multiple bytes into a single storage unit if you want to. Base64 and base85 are useful comparisons here. If I declared that one character was a byte and it had 85 possible states, the math would work out fine.
This is exhausting. You are being obtuse for the sake of it and missing the main point.
All manufacturers of storage are going to market assuming 8 bit bytes. Yes, that is not a standard. The computer using it may divide up the bits differently and thus have a different number of bytes. But 8 is so insanely common that it's really a non issue. Would it be better if they advertised the number of bits instead? Sure. But assuming 8-bit bytes, at least they're honest when they use the metric prefixes.
My issue is not the number of bits, bytes or the manufacturers. My issue is software.
If Windows (for example) is measuring GiB and calling it gigabytes or GB, that's wrong. Those are two different units. One is base 2, the other base 10.
It doesn't really matter which they use to measure, as long as they're consistent. If they want to use gigabytes that's fine, as long as they really mean 1 billion bytes.
The terms should be used properly. Giga should never mean anything other than billion, because otherwise that's confusing and inconsistent with every other field.
We should be consistent with other fields because that makes communication easier.
It's stupid to have our own make believe fairytale version of the metric prefixes. It serves no purpose. We have GiB, KiB, MiB now and should use them if that's what is meant.
> This is exhausting. You are being obtuse for the sake of it and missing the main point.
Disagreeing is not missing the point.
I'm not serious when I suggest an 8.59 bit byte, but I am serious when I say you shouldn't care so much about the "mega" part of "megabyte" being precise when "byte" isn't precise.
> But assuming 8-bit bytes, at least they're honest when they use the metric prefixes.
They're not. Technical correctness is not honesty, and they're giving people an unrealistic expectation of drive size. It doesn't matter if those expectations are based on "wrong" information.
> It doesn't really matter which they use to measure, as long as they're consistent.
They are consistent. They're so consistent that they've been using "GB" since long before the term "gibibyte" even existed.
Gibibyte is not truly a separate unit, because until fairly recently it was spelled gigabyte whenever anyone talked about it.
> It's stupid to have our own make believe fairytale version of the metric prefixes. It serves no purpose. We have GiB, KiB, MiB now and should use them if that's what is meant.
The split is dumb but all words are made up and the ibi prefixes don't solve a real problem. If someone wants to be metric-accurate they should just use metric.
Most of my data structures exist in powers of two memory space. All of my calculations of complexity are also represented in powers of two. If I double the data I'm dealing once, twice, ten times, I expect to have to increase my storage by the same amount, not by 103% for each interval.
This is because of the units used. Advertising/sales uses units with factors of 1000 (KB, MB, TB), while computers use factors of 1024 (KiB, MiB, TiB).
So your 1TB is definitely 1000GB. But it's 931 GiB.
Some claim it was easier for consumers to understand factors of 1000 rather than 1024. But conveniently it also makes the number look bigger for no extra cost, so eh. I'd put my money on the later.
Well yeah but it's not interesting. It's like saying there's a whole new kind of tire - that is 13.5" wide unlike the 13" tires we're used to. Useful? Yes. interesting? No.
It was never worth it to go to the halfway points before. Slower progress in RAM (and a higher proportion of large system cost being RAM) makes it more worthwhile to fine tune this. I think it's interesting because it's yet another symptom that we're just not getting more density of memories-- now it's justified for memory controllers to be slightly fancier to deal with this.
I wish I could have more readily built a 96GB system instead of the 128GB one that I just did. I wanted overkill (more than 64GB), but I didn't need 2x overkill.
> And we had triple channel memory before, which eats of most of the novelty.
If reaching peak performance requires stuffing all the memory channels, then you still have choices that vary by a factor of 2 choices.
> Couldn't you have put one 32GB and one 16GB module in each channel?
It's a mini-itx board, so only 1 DIMM per channel. I also generally just prefer to put one dimm per channel in machines, because more loading on the memory bus often equals having to tune for less performance.
I’m all for saving money. But it’s a stretch to say it’s particularly interesting news. But my wife gets excited about credit card point promotions, so I guess some folks are excited to save a few bucks and would find this thrilling. But I will always remember this article as the most disappointingly boring article, other than that one my wife sent me about Hilton Honors points.
No kidding, the last paragraph in particular sounds written by GPT:
> Overall, the release of the non-binary DDR5 RAM is a major milestone in the tech industry and is expected to have a significant impact on the way that devices are designed and used. It is likely that we will see a wide range of devices adopting the new memory technology in the coming years, as businesses look to take advantage of its many benefits.
https://openai-openai-detector.hf.space/ rates the article as 99.98% fake; I wonder if it is in fact an AI-generated summary of the Register article it links to.
(Edit to add: the same tool rates the source Register article as 99.98% real.)
I was imagining something like super fast analog not-quite-precise storage for things that don't need a huge number of IEEE-754 bits, like maybe graphics cards. I bet there are lots of applications for fast FPUs that don't care about a few LSBs.
68 comments
[ 3.0 ms ] story [ 135 ms ] thread> Pulse Amplitude Modulation 4-level (PAM4) is a multilevel signal modulation format used to transmit signal. Each signal level can represent 2 bits of logic information.
> NRZ
> Non-Return-to-Zero (NRZ), also called Pulse Amplitude Modulation 2-level, is a binary code using low and high signal levels to represent the 1/0 information of a digital logic signal. NRZ can only transmit 1 bit, i.e. a 0 or 1, of information per signal symbol period.
How is PAM4 not just 2 "NRZ"?
Because it's on one wire. (Or one wire pair for differential systems.)
The headline made me think about storing two bits per cell, like MLC flash does, with 4 levels of charge instead if 2.
Signalling systems that don't divide cleanly into a number of bits are more complicated to work with; you need to group bits together into another group of terts[0] and assign states to each. It's less like "picking the bits between the bits out" and more like MFM/GCR encoding for magnetic media.
[0] Ternary digits. No clue what the official name is for these but I am not going to go with the obvious choice.
Alas, sensing the contents of a DRAM cell in the time allotted is already a tough ask. Having to discriminate between multiple voltage levels would surely make have a nasty latency impact.
OTOH, I believe DRAM senses entire rows at a time -- so after that latency hit, bandwidth might be unchanged.
Any idea if it is even possible with existing capacitive DRAM cells?
Forgive me for being an old guy, but how would that facilitate emoji?
https://en.wikipedia.org/wiki/Decimal_computer
His message facilitated the emoji because he has not fully thought out what decimal ram would entail before sending his post.
More. Coffee. Required.
But the computer doesn't report gigabytes (GB). It reports Gibibytes, GiB. Different units.
Not saying it's not a dumb situation, just why it's happening.
If software developers were:
1. Measuring using base-2 (what we would now call Kibi, Mebi, Gibi)
2. Reporting memory using base-10 prefixes (kilo, mega, giga)
Then its those software developers, not advertisements/sales that were the problem. Those prefixes mean a very specific thing accross all fields. Using kilo to mean 1024 instead of 1000 is objectively wrong. No other field does that.
> objectively wrong
So is assuming a "byte" has 8 bits. But outside of prescriptivist pedantry, gigabyte has long been used for mostly base two.
No other field is coming up with their own meaning of "kilo". The meaning of the metric system is not up for debate. It is defined by the ISU. It is not a "maybe" or an "almost" or situational. It is a hard set of rules to make communication and measurement easier.
What a "byte" is depends on the implementation. It's generally 8 bits but some systems are different. It's not a hard definition like the metric system. No standards organization came together to say a byte must always and only be 8 bits in every situation.
You are comparing two completely different situations.
Neither is the computer field, really. "kilo" by itself isn't affected.
> The meaning of the metric system is not up for debate.
Nobody is saying it's metric, either. "metric kilobyte" is a thousand bytes.
It's like having different tons.
> What a "byte" is depends on the implementation. It's generally 8 bits but some systems are different. It's not a hard definition like the metric system. No standards organization came together to say a byte must always and only be 8 bits in every situation.
If it depends on implementation, why are you insisting a gigabyte is exactly 8 billion bits?
What if I said a "byte" could be 8.59 bits?
> You are comparing two completely different situations.
I don't see it that way, because I'm only making an argument about "gigabyte" as a single unit. (And kilobyte, megabyte, terabyte.) The vagueness of both applies.
Yes, it is. When software measures in factors of 1024 but reports these using metric prefixes (kilo, mega, giga, or their shorthands KB, MB, GB), it's wrong. Imagine if a chemist had 1024 milliliters and reported that as a liter. People would be up in arms about it.
>If it depends on implementation, why are you insisting a gigabyte is exactly 8 billion bits?
I didn't. I never set bits. Bytes.
A gigabyte is always 1 billion bytes, and a Kilobyte is always 1000 bytes. How many bits that is is implementation-dependent.
>What if I said a "byte" could be 8.59 bits?
...there's no such thing as fractional bits.
>I don't see it that way, because I'm only making an argument about "gigabyte" as a single unit. (And kilobyte, megabyte, terabyte.) The vagueness of both applies.
There is vagueness in how many *bits*, but not how many bytes. That is a critical distinction.
Again, the prefixes aren't up for debate. They always mean the same thing. Using them to mean factors of 1024 is just factually wrong.
Not if that method went back decades.
I'll repeat the comparison to tons, since you didn't acknowledge it. Tons are different sizes in different places, and people manage. (And I'm including tonne because it's pronounced the same and has the symbol 't'.)
> I didn't. I never set bits. Bytes.
> A gigabyte is always 1 billion bytes, and a Kilobyte is always 1000 bytes. How many bits that is is implementation-dependent.
So if I handed you a full CD and said it had 350 megabytes, because it has a million sets of 16 bits, you wouldn't object to that?
Or if a drive manufacturer decided they're going to market based on 6 bit bytes, you wouldn't object to that?
> ...there's no such thing as fractional bits.
Sure there is. One printable ASCII character can store six and a half bits. Two of them can store thirteen bits. You can also entangle multiple bytes into a single storage unit if you want to. Base64 and base85 are useful comparisons here. If I declared that one character was a byte and it had 85 possible states, the math would work out fine.
All manufacturers of storage are going to market assuming 8 bit bytes. Yes, that is not a standard. The computer using it may divide up the bits differently and thus have a different number of bytes. But 8 is so insanely common that it's really a non issue. Would it be better if they advertised the number of bits instead? Sure. But assuming 8-bit bytes, at least they're honest when they use the metric prefixes.
My issue is not the number of bits, bytes or the manufacturers. My issue is software.
If Windows (for example) is measuring GiB and calling it gigabytes or GB, that's wrong. Those are two different units. One is base 2, the other base 10.
It doesn't really matter which they use to measure, as long as they're consistent. If they want to use gigabytes that's fine, as long as they really mean 1 billion bytes.
The terms should be used properly. Giga should never mean anything other than billion, because otherwise that's confusing and inconsistent with every other field.
We should be consistent with other fields because that makes communication easier.
It's stupid to have our own make believe fairytale version of the metric prefixes. It serves no purpose. We have GiB, KiB, MiB now and should use them if that's what is meant.
Ok?
Disagreeing is not missing the point.
I'm not serious when I suggest an 8.59 bit byte, but I am serious when I say you shouldn't care so much about the "mega" part of "megabyte" being precise when "byte" isn't precise.
> But assuming 8-bit bytes, at least they're honest when they use the metric prefixes.
They're not. Technical correctness is not honesty, and they're giving people an unrealistic expectation of drive size. It doesn't matter if those expectations are based on "wrong" information.
> It doesn't really matter which they use to measure, as long as they're consistent.
They are consistent. They're so consistent that they've been using "GB" since long before the term "gibibyte" even existed.
Gibibyte is not truly a separate unit, because until fairly recently it was spelled gigabyte whenever anyone talked about it.
> It's stupid to have our own make believe fairytale version of the metric prefixes. It serves no purpose. We have GiB, KiB, MiB now and should use them if that's what is meant.
The split is dumb but all words are made up and the ibi prefixes don't solve a real problem. If someone wants to be metric-accurate they should just use metric.
So your 1TB is definitely 1000GB. But it's 931 GiB.
Some claim it was easier for consumers to understand factors of 1000 rather than 1024. But conveniently it also makes the number look bigger for no extra cost, so eh. I'd put my money on the later.
This has the potential to noticeably reduce costs in many cases.
It was never worth it to go to the halfway points before. Slower progress in RAM (and a higher proportion of large system cost being RAM) makes it more worthwhile to fine tune this. I think it's interesting because it's yet another symptom that we're just not getting more density of memories-- now it's justified for memory controllers to be slightly fancier to deal with this.
I wish I could have more readily built a 96GB system instead of the 128GB one that I just did. I wanted overkill (more than 64GB), but I didn't need 2x overkill.
And we had triple channel memory before, which eats of most of the novelty.
> I wish I could have more readily built a 96GB system instead of the 128GB one that I just did.
Couldn't you have put one 32GB and one 16GB module in each channel?
If reaching peak performance requires stuffing all the memory channels, then you still have choices that vary by a factor of 2 choices.
> Couldn't you have put one 32GB and one 16GB module in each channel?
It's a mini-itx board, so only 1 DIMM per channel. I also generally just prefer to put one dimm per channel in machines, because more loading on the memory bus often equals having to tune for less performance.
Interestingly, GPUs don't have the power of 2 mindset. 6GB GPUs have been sold since 2016.
> Overall, the release of the non-binary DDR5 RAM is a major milestone in the tech industry and is expected to have a significant impact on the way that devices are designed and used. It is likely that we will see a wide range of devices adopting the new memory technology in the coming years, as businesses look to take advantage of its many benefits.
https://openai-openai-detector.hf.space/ rates the article as 99.98% fake; I wonder if it is in fact an AI-generated summary of the Register article it links to.
(Edit to add: the same tool rates the source Register article as 99.98% real.)
Downvoting avalanche in 3...2..
Gender pronouns for computer memory.