IMHO ECC should be standard equipment for all computing, especially if accuracy is important. ECC does not necessarily guarantee HA, as most can only correct 1-bit error. Servers will likely crash if error bits are detected.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Mac Pro 2023 = Another Mac Pro 2013 crisis and failure.
- Thread starter sunny5
- Start date
- Sort by reaction score
Ofcourse, ECC RAM would be ideal to use in any case. If money is no object, sure why not use it?
Lots of comments...What makes you think Apple wouldn't incorporate ECC if they went to ≈1 TB? That's what NVIDIA did with the (up to) 960 GB LPDDR5x RAM in its Grace Hopper Superchip.
Indeed, Apple recently published a patent about the use of ECC in LPDDR RAM. While the patent makes a passing mention of on-die ECC, most of it focuses on their claims of improvements to link ECC:
[ https://patentscope.wipo.int/search/en/detail.jsf?docId=US403904970&_cid=P12-LLBQX0-80508-2 ]
Expanding on this:
AIUI, there are two broad types of ECC: (1) traditional "transmission" ECC (which corrects transmission errors between the RAM and the processor; when RAM is labelled "ECC", they're referring to this); and (2) on-die ECC, a new type of ECC that was introduced with DDR5 to address, as the name indicates, on-die memory errors that DDR5's higher memory density makes more prevalent.
Transmission ECC comes in two flavors: side-band (typically used in DDR RAM) and inline (used in LPDDR RAM). The variant of inline ECC that JDEC introduced for LPDDR5 is called link ECC (I don't know if inline ECC was available to earlier generations of LPDDR).
But that leaves me with these specific questions:
1) Are there differences in the robustness of error correction between the JDEC DDR5 standard's "transmission" ECC, and the JDEC LPDDR5 standard's link ECC?
2) How exactly does Apple's patent claim to improve upon link ECC? It would be nice if it came with a clear abstract that said: "This is how the patent improves upon relevant existing technologies and prior art: ..." It does say that existing ECC used in servers consumes too much power for many applications, but doesn't summarize how this is an improvement over the relevant existing tech, which is link ECC (and which, as it's designed for LPDDR RAM, likely consumes much less power).
And these more general ones:
1) On-die ECC helps with RAM manufacturing. But is it also used to address memory errors (e.g., on-die bit flips) that occur during use?
2) Does the JDEC standard for LPDDR5 specify on-die ECC?
3) Is there currently any LPDDR5 link ECC RAM on the market? I can't find any. Or is it the case that *all* LPDDR5 RAM comes with link ECC, but because its error correction is not as robust as that of standard DDR ECC, they decided not to label it as "ECC"? Note I'm referring to LPDDR5, not the LPDDR5x ECC RAM that NVIDIA uses.
For more info.:
ECC in DDR Memories | DesignWare IP | Synopsys
Technical Bulletin: Error Correction Code (ECC) in DDR Memorieswww.synopsys.com
LPDDR5 key features | DesignWare IP | Synopsys
Technical Bulletin: Key Features Designers Should Know About LPDDR5www.synopsys.com
1. Not too significant, but you're consistently missing an E in JEDEC there. (Joint Electron Device Engineering Council)
2. The extra 8 data bits on a DDR1-4 ECC DIMM memory channel are simply stored into extra memory capacity, and later get read back and returned to the memory controller. This makes it a full end-to-end check: it detects errors which occur during the write to the DRAM, errors which occur while the data is at rest in the DRAM, errors which occur during DRAM refresh events, and errors which occur during readback from the DRAM to the memory controller.
3. From the perspective of individual DDR1-4 DRAM chips, ECC doesn't exist. They have no idea whether it's in use, they're dumb storage devices with no internal ECC syndrome generators or checkers.
4. Full size DDR5 DIMMs still do this style of end-to-end ECC, but since DDR5 moved to dual 32-bit memory channels on one DIMM, and since SECDED (single error correct / dual error detect) ECC still needs lots of extra bits, ECC DDR5 DIMMs are now 2*40 = 80 bits wide.
5. The new stuff in LPDDR5 is:
5a. Link-level ECC to detect and correct single bit errors at the interface
5b. On-die ECC to detect and correct errors inside the DRAM storage array
So, LPDDR5 chips can now actively participate in ECC.
6. There are some downsides. As you mention, the motivating factor for the internal storage ECC is just permitting the memory array to be so dense that it starts to get a bit... lossy. Kind of akin to how high density flash memory is also lossy. This isn't necessarily where we want to be for main DRAM memory, but here we are I guess.
Furthermore, at least from what I've heard (I haven't read the standard yet), JEDEC didn't see fit to provide full reporting of these on-die storage ECC events on the memory controller interface, which makes it hard to implement traditional RAS (reliability, availability, and serviceability) functions on top of this form of ECC. LPDDR5's ECC functions are not a true substitute for the end-to-end ECC in a desktop/server ECC DIMM.
To my eyes, the Apple patent looks like they're playing tricks based on the letter of the LPDDR5 spec to get at least some of that back, but it's hard to tell because patents are written in a weird legalese.
I don’t know if I’m on board with this. My personal experience in software VT is that any sort of failsafe is important, and that includes ECC RAM.
That said, Macs aren’t on the table there since all the tools are Windows only (thus Dell workstations bought in bulk, yuck)
In the context of the Mac Pro and the wider Mac market, though I might agree. Since Apple seems like they target “prosumers” over enterprise.
Thanks! And thanks for letting me know it's "JEDEC"; I made that correction in my last post.
Let me try summarizing, and you can let me know what's right and wrong:
I. DDR. The online articles present on-die ECC (which corrects bit flips, etc.) as something that's new with DDR5, but it really isn't. All the functionality offered by on-die ECC in DDR5 (see https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-is-it-different-to-traditional-ecc ) was also available with DDR1–4 ECC RAM. The only thing that's new with DDR5 is that more memory has been allocated to store on-die errors, in recognition of the fact that DDR5, which is typically on higher-density processes, is more prone to on-die errors, and thus more storage is needed to catalog these so they can be corrected.
This added storage helps to reduce DDR5 manufacturing costs, since chips with cells whose 0/1 voltage difference would normally be too low to pass JEDEC standards (meaning they are too prone to bit flips) can now be sold, because on-die ECC in DDR5 has enough storage to capture and fix errors that may occur in these cells (see above link).
II. LPDDR. By contrast, ECC (both on-die and transmission) is new with LPDDR5. The transmission part, called Link ECC, is as robust as its DDR counterpart. However, the on-die part is not since, unlike the case with DDR, "JEDEC didn't see fit to provide full reporting of these on-die storage ECC events on the memory controller interface."
Also:
1) Do you agree with the other poster's contention that, when RAM sizes get into the 1 TB range, ECC is needed? And if so, why? Is it because, on the transmission side: More RAM -> higher average data rate between the RAM and CPU -> more errors per unit time? And for on-die, it's simply: More RAM -> more cells -> more errors per unit time?
2) Have you heard of anyone besides NVIDIA doing ECC with LPDDR5/5x? And do you think NVIDIA's LPDDR5x ECC is doing anything beyond what the JEDEC standard specifies (to address the limitation you mentioned)?
3) Given that Apple uses the same basic chip design in all its Macs, could Apple offer ECC LPDDR5x in, say, the M3 Mac Pro, while staying with non-ECC LPDDR5x in its other M3 machines? Or would it need to be either all-ECC or all non-ECC across the board? I.e., does switching to ECC require a significant change in the chip architecture?
And if they wanted to go ECC across the board, how much would that add (qualitatively) to the retail cost of, say, an entry-level MBA—would it be marginal or significant?
4) Implementing ECC would somewhat decrease the memory capacities and bandwidths, and increase the latency, right? Not sure about the effect on power consumption....
Last edited:
No, as far as I know the spec for on-die ECC was created for the DDR5/LPDDR5 generation and nothing like it was ever done in DDR4 memories. (I suppose in principle you could've implemented something like it in DDR4 RAM without violating the interface spec, but I doubt anyone ever did.)
It depends on what you want ECC for. There's a number of different things it provides you.
For example, some want it to protect against hardware failures, and reliably report them to the OS. This is very important in high-RAS systems such as big multi-socket servers.
At the extremes, the desire for RAS features can lead to much stronger ECC than mere SECDED. IBM's mainframe products are available with what they market as "Chipkill" ECC RAM, meaning the memory is much like a RAID-5 array in that it can tolerate losing entire chips. IBM big iron also has all kinds of expensive tech allowing hotswap of broken memory and CPUs to fix components in a big machine without rebooting.
And yes, the reason to want ECC with 1TB is the increased chance of errors. All DRAM cells (and SRAM cells for that matter) can suffer from random SEUs - Single Event Upsets - in which a single ionizing radiation particle strikes a memory cell and flips it from one value to the other. Adding more DRAM to a single computer is like spreading a wider net to catch more cosmic rays, so there's an argument that the more memory you have, the more you need ECC to protect against random 1-bit errors. (You hope that they're 1-bit, anyways.)
Oddly enough, with modern logic and DRAM process nodes, the SEU rate for SRAM cells in your microprocessor is typically much worse than DRAM cells. It's almost required to protect key CPU SRAM arrays (any moderately large cache, for example) with ECC now.
You can always implement ECC with any kind of memory if you design the memory controller, it's just a question of where you store the extra bits. NVidia's doing inline ECC, meaning that for every N words of data written the memory controller writes an extra word at the next address containing the ECC syndrome for the previous N words. This scheme eats into the addressable storage and has bandwidth overhead.
If they want to, they can do it. It's merely a question of whether the tradeoffs are acceptable to them. For example, say they do sideband ECC, where you're storing the syndromes by adding extra memory bus width. The tradeoff they'd have to accept for consumer products using the same SoC die is a bit of dark silicon - unused I/O pad structures and memory controller circuitry.
I'd say significant-ish. At the price of a MBA, Apple could easily offer ECC at no extra cost to the user without hurting margins too much. Would they want to? No, because they do like their margins and also ECC would almost certainly reduce battery life.
This depends. If it's an NVidia-like inline ECC system, then yes, you accept less capacity and bandwidth and worse latency. Sideband ECC (the kind found in conventional ECC DIMMs) doesn't hurt nominal memory capacity or bandwidth, but requires the DIMM to have 1.125x as much DRAM (as in, an 8GB ECC DIMM really has 9GB worth of DRAM chips on it) and costs more power - usually there's an entire extra DRAM chip, after all.
It seem that you confuses a desk with a computer with a "workstation computer". “Workstation computer“ is a definition just like a “gaming rig” but I agree, the lines are blurring regarding performance. Both can be used for work.
I cannot place M2 Ultra computers in either category and rather say it is a computer for work.
Thanks again! You said this about DDR1–4, and I interpreted the bolded part to be the same functionality provided by on-die ECC: Detecting errors that occur within the DRAM die. That's why I wrote "All the functionality offered by on-die ECC in DDR5 ... was also available with DDR1–4 ECC RAM."
It sounds like they could incorporate ECC circuitry into the Max chip only, but leave it dark in the Max MBP's, enabling them to offer ECC in the Max and Ultra Studios, and the Ultra MP, w/o compromising battery life for the MBP's.
Interesting! I didn't know they used ECC in CPU cache.
This article's introduction provides a brief summary for anyone who's interested: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9697281/
My gaming machine is a repurposed xeon workstation with a significantly upgraded GPU, to further confuse the issue
The Mac Pro has PCIe slots. No you can not use hose slots for GPU cards. The intended use for the PCI slots is for some esoteric networking cards that are used in video production. The PCI cards are needed for connectivity to the media storage.
"Enthusiasts" are mad because they have to pay Apple's full asking price for RAM. In the past, they could buy the base RAM and then use cheap 3rd party RAM. This is really why they dislike the new Mac Pro.
VERY few people who own a Mac Pro are saying they are not able to get their work done in time because the computer is too slow. You never hear that from real users.
The other big issue is that you can no longer run Windows on the Mac Pro, and so much professional software requires Windows.
Last edited:
My phone should have ECC. I'd like devices that do online banking to have reliable memory. And I'd like all my devices to give me an indication when the memory is starting to fail. Without ECC we have no idea which recent random crash was due to a memory problem.
On the Mac Pro only, the primary internal storage is user-replaceable and upgradeable.
But the main difference is connectivity. See screenshots from from Apple's website below. In top screenshot, Studio on left, Mac Pro on right. The Mac Pro's PCIe slots can be used for audio and video cards, and also adding fast internal storage, and high-speed connections to external networks.
And most importantly: Wheels are not available for the Studio.
The MacPro also has these:
Last edited:
How well does that work in practice, though? If someone wants to run a Windows app, it's probably x86. So first it has to go through an emulator to get it to work on Windows for ARM, and then that has to be run through a VM. I've no experience with this, but it sounds like that would work well for light software only. Plus it seems like those extra layers mean more complications and more chance of something not working
It's gotten better over time. For example, VS has been ARM-native for a year or so.
But even running VS through x86 is usable. It's not zippy, but you can absolutely do it.
For things like low-level hardware access, for sure.
Oftentimes, the "I need some random Windows-only app" scenarios aren't apps that require a lot of resources.
"Emulator" is a bit of a stretch. Windows , like Apple's Rosetta 2, recompiles the application into Arm code.
"... The WOW64 layer of Windows allows x86 code to run on the Arm64 version of Windows. x86 emulation works by compiling blocks of x86 instructions into Arm64 instructions with optimizations to improve performance. A service caches these translated blocks of code to reduce the overhead of instruction translation and allow for optimization when the code runs again. The caches are produced for each module so that other apps can make use of them on first launch. ...."
So the longer and 'harder' (more breath over possible linked libraries and modules) you run an app the more it is already Arm binary code when your usage asks for code to be run.
There are old , odd-ball apps with self modifying code and Windows apss that themselves are dubious old school emulators that are plodding line-by-line interpreting code. But modern modern , well optimized x86-64 Windows apps. Shouldn't be a huge overhead. ( there is some semantic matching 'extra' code injected into the Arm binary ).
If the objective is to run old-as-dirt DOS and ancient 32-bit "Windows 95" era apps then bigger problems.
Rosetta 2 has a few shortcuts. Apple recompiles the whole app at lauch and stores a complete duplicate app on the file system ( technically, MS cache and not storing permanently is a historically 'safer' legal option. ) . Apple has a few tricks specific to just there superset of the Arm standard to tap-dance around some of the need for semantic-matching 'extra' code injection.
The userspace code a modern VM really isn't going to incur that much overhead at all.
If the app spends lots of time in the kernel level ( e.g., vast majority of the time making low level GPU driver calls ) that is more of an issue more so than 'the application' itself.
If the app is really a lightweight wrapper around highly proprietary Nvidia GPU calls then there not being a Nvidia GPU is bigger primary issue.
Also get into trouble because can't do layered/nested virtualization on Arm much. So if have x86 code stack that was a x86 vritual machine on top of another virtual machine ( e.g, some DOS container or Linux-on-Windows or VMware Workstation running images, etc. )
Heavyweight Excel calculations that result in a 2D chart/graph would work fine. All long as hammering hard on a narrow fixed set of userspace code , it should work relatively very well since it is all just recompiled Arm code .
If it is 'heavyweight' because have pushed the vast majority of the computation off of x86 and onto specific GPU cores not covered ... again a different issue. Apple is definitely missing a mechanism to attach GPUs they don't want to deal with at all to Guest OS instances that are willing to do the job. It is more so that Apple's VM is too immature than a VM can't do a better job.
It's what Microsoft calls it
Unfortunately, XTA continues the poor design of Windows x64 of duplicating portions of the file system, redirecting the registry, etc., instead of unifying the paths. And it does so even more stupidly than x64 did.
On an ARM64 system, you get Program Files, Program Files (Arm) and Program Files (x86). So x64 — i.e., not native — is now the one without a suffix, and ARM64 and x86 have a suffix.
Likewise, the registry now has "WOW6432Node" and "WowAA32Node". Wow indeed.
But have either of you actually tried doing this (running x86 software on AS)? For example, according to this Reddit thread, running Solidworks 3D on Apple Silicon can be a major headache. Plus you lose performance, and you get no technical support from Solidworks. This is what I meant when I wrote "it sounds like that [running x86 software on AS] would work well for light software only."
As another example, some of the administrators at my university use a Windows-only Excel Add-In through which they access a program that in turn connects with one of the university's servers. That's not a heavy program, but with all those connections (Excel->Add-In->Server) (plus the two-factor authentication step), it seems like something that is just waiting to be a headache if you try running it through both a VM and an emulator.
Last edited:
I haven't read the thread, but I'll share my thoughts based on the OP.
Once the trash can pro was announced and subsequently released I knew that as far as pro desktops were concerned Apple no longer considered this line as something that would receive frequently scheduled releases.
Considering the absurdly high entry cost compared to the mac studio suggests that this is part response to the pro market and also demand on how to pivot moving forward. A pro desktop in a full chassis without a removable CPU or RAM is absurd to me, but I don't think apple was too thrilled with how long those 2006-2013 Mac Pro models were able to be modified by consumers to run modern versions of macOS.
As far as this being a 'crisis' for Apple? I don't think so and there are 3 reasons that quickly come to mind for me.
1 - Apple has complete control of how these systems are designed now. The challenges that Apple had when dealing with Intel was hoping that server, desktop and laptop class CPUs would keep up with the design ambitions from Apple. The 12" MacBook and the trash can pro were prime examples showing apple that it was time to move forward without Intel as far back as a decade ago.
2 - While many pro consumers complained about the trash cans and the limited upgrade path of the internal parts I think the biggest concerns over the years was the actual performance of the machines themselves as they aged out. The performance concerns should no longer be a problem so my guess is that the difference between the Studio and the Full ATX style Mac Pro would be just how important are future upgrade options to the buyer. I expect the absurd premium to remain for the privilege to upgrade your internal storage and hopefully RAM in the future updates along with options to support the best nvidia/amd graphics as things such as AI take advantage of those parts. An upgrade-able CPU will be highly unlikely.
3 - Apple is not the same company it was when the first Mac Pro in 2006 was released nor is it even the same company when the 2013 trash can was released. They are very strong in the mobile space now and have quickly made services a huge part of their overall business. So with those facts I fail to see how being viewed as a failure in a niche market is going to affect them all that much these days. My hope is that they still care about the super power users. I would actually be interested in seeing a 3TB-4TB RAM Mac Pro for certain applications as long as GPU support ever comes to modern macs. I assume they will given how large that market is, but it might take some time and I think it's something Apple is perfectly fine with considering how successful the transition away from Intel has been.
Once the trash can pro was announced and subsequently released I knew that as far as pro desktops were concerned Apple no longer considered this line as something that would receive frequently scheduled releases.
Considering the absurdly high entry cost compared to the mac studio suggests that this is part response to the pro market and also demand on how to pivot moving forward. A pro desktop in a full chassis without a removable CPU or RAM is absurd to me, but I don't think apple was too thrilled with how long those 2006-2013 Mac Pro models were able to be modified by consumers to run modern versions of macOS.
As far as this being a 'crisis' for Apple? I don't think so and there are 3 reasons that quickly come to mind for me.
1 - Apple has complete control of how these systems are designed now. The challenges that Apple had when dealing with Intel was hoping that server, desktop and laptop class CPUs would keep up with the design ambitions from Apple. The 12" MacBook and the trash can pro were prime examples showing apple that it was time to move forward without Intel as far back as a decade ago.
2 - While many pro consumers complained about the trash cans and the limited upgrade path of the internal parts I think the biggest concerns over the years was the actual performance of the machines themselves as they aged out. The performance concerns should no longer be a problem so my guess is that the difference between the Studio and the Full ATX style Mac Pro would be just how important are future upgrade options to the buyer. I expect the absurd premium to remain for the privilege to upgrade your internal storage and hopefully RAM in the future updates along with options to support the best nvidia/amd graphics as things such as AI take advantage of those parts. An upgrade-able CPU will be highly unlikely.
3 - Apple is not the same company it was when the first Mac Pro in 2006 was released nor is it even the same company when the 2013 trash can was released. They are very strong in the mobile space now and have quickly made services a huge part of their overall business. So with those facts I fail to see how being viewed as a failure in a niche market is going to affect them all that much these days. My hope is that they still care about the super power users. I would actually be interested in seeing a 3TB-4TB RAM Mac Pro for certain applications as long as GPU support ever comes to modern macs. I assume they will given how large that market is, but it might take some time and I think it's something Apple is perfectly fine with considering how successful the transition away from Intel has been.
Last edited:
Note they did bring in a "Pro Workflow Team" to design the 2019 MP, indicating they still do take that market seriously (or at least did while that team was active; not sure if it still is).
Plus I suspect the reason we don't have an Extreme MP isn't because Apple wasn't interested in offering one, but rather because they decided it was too hard to build.
IMO, what should really distinguish the MP now, given that customers are paying for that very expensive box, is that the entire logic board (which could simply be slid out on the 2019 MP; suspect that's still the case for the AS MP) should be replaceable as new generations of AS come along, for less than the cost of buying the equivalently-equipped Ultra Studio.
E.g., if you've bought an M2 MP, and want to upgrade it to an M5 (assuming the case design is still the same at that time), you should be able to buy a complete M5 board for less than the cost of an equivalently-spec'd (RAM & SSD) M5 Ultra.
I can happily give an option. I’m a motion designer for broadcast and film. I use c4d and after effects daily. I moved from the 2019 Mac Pro to the studio m2 ultra. Quite honestly I wish I hadn’t, I have such poor performance and constant memory issues. Slow performance and just generally meh from the m2 ultra. I can’t for the life of me fathom why and how Apple justify the 192gb or ram limitation. I had 512gb in the 16 core. That was a choice for best overall when I purchased.
I was a Mac Pro customer, have been for 15 years. But this time, it was unjustifiable. Wouldn’t have hesitated if I could have used the short lived mpx module. Or upgrade ram. But no way not ever that pro tax for a box with a few extra pci slots. Apple is forcing its pro customers to PC. As it pains me to write. The performance isn’t there. Sure apps load quick, sure there are some pros, but my daily efficiency has dropped because I’m coming up against issues constantly. Marketing at its best with Apple. But in reality it’s just fluffy words and a pretty box.
Thank you for your input Dave, what I find interesting is someone else posted that the M2 Ultra was running AE twice as fast as their old 2019 Mac Pro. I guess it depends on what you are doing in AE. Since you use C4D quite a bit, I suspect that is why the M2 is falling short (what GPU did you have in your 2019 MP?) All things considered anything CPU bound the M2 *should* be faster than the 2019 Xeon.
Maybe the optimization just isn't there yet for Apple Silicon and Adobe. Hell in my opinion Adobe just is not there yet overall when it comes to modern Mac computers. Although the last update to AE it seems to be running very well on my 2019 Mac Pro. It does like to slurp up RAM though...lol.
It is somewhat applicable because they are taking pains to avoid persistently writing the recompiled code out to disk and they are to work around some substantive semantic gaps on ordering. But most folks thoughts about 'emulators' are not as compilers. And this is mostly just a compiler.
Chuckle. Rosetta 2 creates a duplicate file tree of apps too. Apple just shovels it into the file system so it doesn't show up in the Finder.
All that registry hocus pocus , hoo-haw ... that is just Windows being Windows. That is probably never going away. That Windows went down the rabbit hole with boot feet on Arm 32 is coupled to the foray into "Windows for Phones" , "RT" , and fixation on commitment to oldest possible 90's vintage windows code they can dig up. All of which has blundered Windows on Arm for more than a decade.
Apple just tells folks to throw their 32-bit code in the trash can and keeps on stepping into the future. Both approaches are dual edged.
The descriptor '3D' above highly indicates that you really didn't read what I wrote. That really isn't about 'arm' vs 'x86' .
P.S. on your problem Redit thread ....
Third entry
" ...
My Solidworks is working buttery smooth....
1.Install Parallels
..."
There is a windows installer problem for parts of the Solidworks state far, far, far ,far more so than something on the Apple side of the VM or the Windows x86 re-compiler.
Last edited: