Wandering Thoughts


In a university, people want to use our IPs even for external traffic

Suppose that your organization has a VPN server that people use to access internal resources that you don't expose to the Internet. One of the traditional decisions you had to make when you were setting up such a VPN server was whether you would funnel all traffic over the VPN, no matter where it was to, or whether you'd funnel only internal traffic and let external traffic go over people's regular Internet connections. In many environments the answer is that the VPN server is only really for internal traffic; it's either discouraged or impossible to use it for external traffic.

Universities are not one of those places. In universities, quite often you'll find that people actively need to use your VPN server for all of their traffic, or otherwise things will break in subtle ways. One culprit is the world of academic publishing, or more exactly online electronic access to academic publications. These days, many of these online publications are provided to you directly by the publisher's website. This website decides if you are allowed to access things by seeing if your institution has purchased access, and it often figures out your institution by looking at your IP address. As a result, if a researcher is working from home but wants to read things, their traffic had better be coming from your IP address space.

(There are other access authentication schemes possible, but this one is easy for everyone to set up and understand, and it doesn't reveal very much to publishers. Universities rarely change their IP address space, and in the before times you could assume that most researchers were working from on-campus most of the time.)

In an ideal world, academic publishers (and other people restricting access to things to your institution) could tell you what IP addresses they would be using, so you could add them to your VPN configuration as a special exemption (ie, as part of the IP address space that should be sent through the VPN). In the real world, there are clouds, frontend services, and many other things that mean the answer is large, indeterminate, and possibly changing at arbitrary times, sometimes out of the website operator's direct control. Also, the visible web site that you see may be composited (in the browser) from multiple sources, with some sub-resources quietly hosted in some cloud. For sensible reasons, the website engineering team does not want to have to tell the customer relations team every time they want to change the setup and then possibly wait for a while as customers get onboard (or don't).

Our VPNs default to sending all of people's traffic through us. At one point we considered narrowing this down (for reasons); feedback from people around here soon educated us that this was not feasible, at least not while keeping our VPN really useful to them. When you're a university, people want your IPs, and for good reasons.

UniversityPeopleWantOurIPs written at 23:21:38; Add Comment


The CPU architectural question of what is a (reserved) NOP

I recently wrote about an instruction oddity in the PowerPC 64-bit architecture, where a number of or instructions with no effects were reused to signal hardware thread priority to the CPU. This came up when Go accidentally used one of those instructions for its own purposes and accidentally lowered the priority of the hardware thread. One of the reactions I've seen has been a suggestion that people should consider all unofficial NOPs (ie, NOPs other than the officially documented ones) to be reserved by the architecture. However, this raises a practical philosophical question, namely what's considered a NOP.

In the old days, CPU architectures might define an explicit NOP instruction that was specially recognized by the CPU, such as the 6502's NOP. Modern CPUs generally don't have a specific NOP instruction in this way; instead, the architecture has a significant number of instructions that have no effects (for various reasons including of the regularity of instruction sets) and one or a few of those instructions is blessed as the official NOP and may be specially treated by CPUs. The PowerPC 64-bit official NOP is 'or r1, r1, 0', for example (which theoretically OR's register r1 with 0 and puts the result back into r1).

Update: I made a mistake here; the official NOP uses register r0, not r1, so 'or r0, r0, 0', sometimes written 'ori 0, 0, 0'.

So if you say that all unofficial NOPs are reserved and should be avoided, you have to define what exactly a 'NOP' is in your architecture. One aggressive definition you could adopt is that any instruction that always has no effects is a NOP; this would make quite a lot of instructions NOPs and thus unofficial NOPs. This gives the architecture maximum freedom for the future but also means that all code generation for your architecture needs to carefully avoid accidentally generating an instruction with no effects, even if it naturally falls out by accident through the structure of that program's code generation (which could be a simple JIT engine).

Alternately, you could say that (only) all variants of your standard NOP are reserved; for PowerPC 64-bit, this could be all or instructions that match the pattern of either 'or rX, rX, rX' or 'or rX, rX, 0' (let's assume the immediate is always the third argument). This leaves the future CPU designer with fewer no-effect operations they can use to signal things to the CPU, but makes the life of code generators simpler because there are fewer instructions they have to screen out as special exceptions. If you wanted to you could include some other related types of instructions as well, for example to say that 'xor rX, rX, 0' is also a reserved unofficial NOP.

A CPU architecture can pick whichever answer it wants to here, but I hope I've convinced my readers that there's more than one answer here (and that there are tradeoffs).

PS: Another way to put this is that when an architecture makes some number of otherwise valid instructions into 'unofficial NOPs' that you must avoid, it's reducing the regularity of the architecture in practice. We know that the less regular the architecture is, the more annoying it can be to generate code for.

WhatIsAModernNOP written at 22:23:44; Add Comment


An instruction oddity in the ppc64 (PowerPC 64-bit) architecture

Over on the Fediverse, I reported my discovery of a ppc64 oddity:

TIL that the ppc64 (PowerPC 64-bit) architecture overloads 'or r1,r1,r1' (and the same using all r6 or r2) to change the (hardware) priority of your thread. This came up in a Go code generation issue, and Raymond Chen mentioned it in passing in 2018.

<Go issue 57741>
<Raymond Chen 2018 article>
Also see the discussion in this PDF: <"Advanced POWER Virtualization ...">


As Raymond Chen notes, 'or rd, ra, ra' has the effect of 'move ra to rd'. Moving a register to itself is a NOP, but several Power versions (the Go code's comment says Power8, 9, and 10) overload this particular version of a NOP (and some others) to signal that the priority of your hardware thread should be changed by the CPU; in the specific case of 'or r1, r1, r1' it drops you to low priority. That leaves us with the mystery of why such an instruction would be used by a compiler, instead of the official NOP (per Raymond Chen, this is 'or r0, r0, 0').

The answer is kind of interesting and shows how intricate things can get in modern code. Go, like a lot of modern languages, wants to support stack tracebacks from right within its compiled code, without the aid of an external debugger. In order to do that, the Go runtime needs to be able to unwind the stack. Unwinding the stack is a very intricate thing on modern CPUs, and you can't necessarily do it past arbitrary code. Go has a special annotation for 'you can't unwind past here', which is automatically applied when the Go toolchain detects that some code (including assembly code) is manipulating the stack pointer in a way that it doesn't understand:

SPWRITE indicates a function that writes an arbitrary value to SP (any write other than adding or subtracting a constant amount).

As covered in the specific ppc64 diff in the change that introduced this issue, Go wanted to artificially mark a particular runtime function this way (see CL 425396 and Go issue #54332 for more). To do this it needed to touch the stack pointer in a harmless way, which would trigger the toolchain's weirdness detector. On ppc64, the stack pointer is in r1. So the obvious and natural thing to do is to move r1 to itself, which encodes as 'or r1, r1, r1', and which then triggers this special architectural behavior of lowering the priority of that hardware thread. Oops.

(The fix changes this to another operation that is apparently harmless due to how the Go ABI works on ppc64. Based on the ppc64 architecture section of the Go internal ABI, Go seems to define r0 as always zero.)

I don't know why PowerPC decided to make r1 (the stack pointer) the register used to signal lowering hardware thread priority, instead of some other register. It's possible r1 was chosen specifically because very few people were expected to write an or-NOP using the stack pointer instead of some other register.

(The whole issue is a useful reminder that modern architectures can have some odd corners and weird cases.)

PowerPCInstructionOddity written at 22:47:58; Add Comment


Some things on SSDs and their support for explicitly discarding blocks

Although things became complicated later, HDDs started out having a specific physical spot for each and every block (and even today most HDDs mostly have such a thing). You could in theory point at a very tiny spot on a HDD and correctly say 'this is block 5,321 and (almost) always will be'. Every time you wrote to block 5,321, that tiny spot would get new data, as an in-place update. SSDs famously don't work like this, because in general you can't immediately rewrite a chunk of flash memory that's been written to the way you can a HDD platter; instead, you need to write to newly erased flash memory. In order for SSDs to pretend that they were rewriting data in place, SSDs need both a data structure to map from logical block addresses to wherever the latest version of the block is in physical flash memory and a pool of ready to use erased flash blocks that the SSD can immediately write to.

In general the size of this erased blocks pool is a clear contributor to the long term write performance of SSDs. By now we're all aware that a fresh or newly erased SSD generally has better sustained write performance than one that's been written to for a while. The general assumption is that a large part of the difference is the size of the pool of immediately ready erased flash blocks keeps shrinking as more and more of the SSD is written to.

(SSDs are very complicated black boxes so we don't really know this for sure; there could be other contributing factors that the manufacturers don't want to tell us about.)

One way that SSDs maintain such a pool (even after they've been written to a lot) is through over-provisioning. If a SSD claims to be 500 GB but really has 512 GB of flash memory, it has an extra 12 GB of flash that it can use for its own purposes, including for a pool of pre-erased flash blocks. Such a pool won't hold up forever if you keep writing to the SSD without pause, but by now we expect that sustained write speed will drop on a SSD at some point. One of the many unpredictable variables in SSD performance is how fast a SSD will be able to refresh its pool given some amount of idle time.

The other way that SSDs can maintain such a pool is that you tell them that some logical blocks can be thrown away. One way to do this is erasing the drive, which has the drawback that it erases everything. The more modern way is for your filesystem or your block layer to use a SSD 'TRIM' command to tell the SSD that some blocks are unused and so can be entirely discarded (the actual specifics in SATA, SCSI/SAS, and NVMe are impressively varied). Obviously TRIM can be used to implement 'erase drive', although this may not be quite the same inside the SSD as a real erase; this use of TRIM for drive erase is what I believe Linux's blkdiscard does by default.

For obvious reasons, correctly implementing TRIM operations in your filesystem and block storage layers is critical. If there are any bugs that send TRIM commands for the wrong blocks (either to the wrong block addresses or mistaking which blocks are unused), you've just created data loss. People also used to worry about SSDs themselves having bugs in their TRIM implementations, since modern SSDs contain fearsome piles of code. By now, my impression is that TRIM has been around long enough and enough things are using it by default that the bugs have been weeded out (but then see the Debian wiki page).

(I believe that modern Linux systems default to TRIM being on for common filesystems. On the other side, OpenZFS still defaults automatic TRIM to off except on FreeBSD, although it's been long enough since my initial caution about TRIM on ZFS that I should try it.)

One of the interesting issues with TRIM is how it interacts with encrypted disks or filesystems, which are increasingly common on laptops and desktops. On the one hand, supporting TRIM is probably good for performance and maybe SSD lifetime; on the other hand, it raises challenges and potentially leaks information about how big the filesystem is and what blocks are actually used. I honestly don't know what various systems do here.

In many Linux environments, filesystems tend to sit on top of various underlying layers, such as LVM and software RAID (and disk encryption). In order for filesystem TRIM support to do any good it must be translated and passed through those various layers, which is something that hasn't always happened. According to the Arch Wiki SSD page, modern versions of LVM support passing TRIM through from the filesystem, and I believe that software RAID has for some time.

A further complicate in TRIM support is that if you're using SATA SSDs behind a SAS controller, apparently not all models of (SATA) SSDs will support TRIM in that setup. We have Crucial MX500 2 TB SSDs in some Ubuntu 22.04 LTS fileservers where 'lsblk -dD' says the SATA connected ones will do TRIM operations but the SAS connected ones won't. However, WD Blue 2 TB SSDs say they're happy to do TRIM even when connected to the SAS side of things.

(Also, I believe that TRIM may often not work if you're connecting a SATA SSD to your system through a USB drive dock. This is a pity because it's otherwise a quite convenient way to work through a bunch of SSDs to blank out and reset. I wouldn't be surprised if this depends on both the USB drive dock and the SATA SSD. Now that I've discovered 'lsblk -D' I'm going to do some experimentation.)

At one point I would have guessed that various SSDs might specially recognize writes of all-zero blocks or similar things and trigger TRIM-like functionality, where the write is just discarded and the logical block is marked as 'trim to <zero or whatever>' (I worried about this in the context of benchmarking). I can't rule out SSDs doing that today, but given widespread support for TRIM, recognizing all-zero writes seems like the kind of thing you'd quietly drop from your SSD firmware to simplify life.

SSDsAndBlockDiscardTrim written at 23:10:24; Add Comment


Let's Encrypt's complex authorization process and multi-name TLS certificates

One of the things that people don't like about Let's Encrypt's ACME protocol for getting TLS certificates is that it's complicated (even beyond using JSON Web Tokens (JWT)). Part of this complexity is that it famously requires you to create and register an account, and the actual authorization process to get a TLS certificate for a domain involves this account in a multi-step process. You can readily come up with simpler single-step processes (such as the one in Another look at the steps for issuing a cert), so you can ask why ACME requires its multi-step process. It recently occurred to me that one reason for this is that it probably makes the logic of issuing a TLS certificate for multiple names simpler.

(We think about multiple names in TLS certificates a lot; most of our TLS certificates have at least two names for what boils down to historical reasons.)

A single-step process for getting a TLS certificate for a domain would be to tell the Certificate Authority that you want a certificate (with a given private key), the CA challenges you to demonstrate control of that domain, and when you do it issues you with that certificate. However, extending this process to a TLS certificate for multiple names makes it somewhat more involved. You would have to send the CA the list of names you wanted in the certificate, it would have to challenge you separately to demonstrate control of each domain, and keep careful track of which domains you'd proven control of and which you hadn't. You'd want to carefully consider 'control of domain' timeouts in this process to decide how close together do you have to prove control of all domains; within a few minutes, or a few hours, or a few days? If you'd made a mistake in a domain name, you'd probably have to cancel or abandon the current request and start all over from scratch (re-proving control of all correct names in a second attempt).

The ACME protocol's two step process makes this simpler and more uniform. You create an account, prove that that account has control of one or more domains, and then have that account ask for a TLS certificate for some name or names that it's proven control of within a specific time period. If you ask for a TLS certificate that includes a name you haven't demonstrated control over, the request fails (more or less, it's a bit complicated). The protocol and the server can consider each 'prove control of' request separately and independently, without having to maintain state on how many domains you've proven control of (and how recently) and trigger issuing a TLS certificate when all of the boxes are ticked off.

(Instead it's the ACME client's job to request actual issuance of the certificate, which is when it submits the actual Certificate Signing Request (CSR). I admit I was a little bit surprised to find out that ACME actually uses real CSRs, since they're complicated objects and these days almost all of their contents get ignored by the CA, or maybe cause your request to be rejected.)

Using a keypair to identify the account instead of what would in effect be a (web) cookie means that any leak or interception of the traffic between you and Let's Encrypt doesn't give out information a potential attacker can use to impersonate you (and thus use your identity to get TLS certificates). This is important in a two-step protocol, but not in a one-step one where you tell the CA the keypair you're using for the TLS certificate before it starts authorizing you (all the CA has to do to stop attackers intercepting traffic is to bind all of the results to the future certificate's public key).

(The two-step process could make you pre-commit to a TLS keypair for your eventual certificate or certificates and use that as your identity, but then you'd have to decide in advance what names would be in the eventual TLS certificate.)

PS: The actual ACME protocol steps for getting a TLS certificate don't require you to start in a state where you've already proven control over all of the domains. Instead, the ACME server will tell you if you need to do some authorizations, and starting from a certificate request is the normal flow of establishing them. There's a separate 'Pre-authorization' process that ACME servers can implement that allows you to authorize accounts for names before you make a certificate request.

LetsEncryptAndMultipleNames written at 23:19:14; Add Comment


Sorting out PC chassis power switches for ATX power supplies

My problematic home desktop continues to be problematic, so recently over on the Fediverse I had a clever idea about 'replacing' the case front panel with just a stand-alone ATX chassis power switch tucked away somewhere, which @penguin42 suggested improving by relying on setting the BIOS to 'always power on when AC is restored' and not having a chassis power switch at all. This left me with a certain amount of curiosity about ATX chassis power switches and the matrix of possibilities for what you can do to your computer and how that interacts with BIOS 'AC loss' settings.

Famously, ATX power supplies are really controlled by the motherboard, not by any front panel case switches (although better PSUs will have a hard power switch so you don't have to yank the cord). The front panel case power switch is a soft switch that communicates with the BIOS or triggers power on, and your motherboard can have the PSU 'turn off' (which still leaves standby power flowing to the motherboard), which is what enabled modern PC Unixes to have commands like 'poweroff' and 'halt -p'. Physically, an ATX chassis power switch (the front panel switch) is normally a momentary-contact switch. It is normally off (no current flowing), but when pushed it connects the circuit for as long as you keep it pressed. Since the circuit is normally open, not having a chassis power switch connected is the same as not pressing it, so your system can still power up in this state under the appropriate conditions.

(I was reasonably certain of this but not completely sure, so I looked it up.)

BIOSes for ATX motherboards tend to have three options for what to do if AC power is lost and then return: they can stay powered off, they can always power on, or they can return to their last state (either powered off if you turned them off, or powered on if you'd turned them on). If you run 'poweroff' on your Linux system and your BIOS is set to either 'stay powered off' or 'return to last state', you will have to use the chassis power button to trigger the motherboard to power up (or possibly use the BMC on servers with it). If you run 'poweroff' on a system set to always power on when AC comes back, you can cut AC power and then turn it back on in order to get the motherboard to power back up.

(The downside of 'always power on when AC comes back' is that you need to make physical changes to make a system stay down after a power loss and restart, even if the changes are only flipping a switch.)

If you don't have a chassis power button, you can no longer power off the system from the front panel, either by triggering some sort of orderly shutdown or by holding the front panel power button down long enough that the BIOS does an immediate power off (and if you have no reset switch too, you can't trigger that either). Instead, your only option is an immediate hard power off by flipping the PSU switch. You can also no longer power the system on from the front panel; instead you need the BIOS to be set to 'always power on after AC loss' (and stay that way) and then switch AC power off and back on again, or you're going to have to open up the case to get the system back on. Some motherboards (including my home desktop) have an a motherboard push switch that you can use to trigger a power on; otherwise you'll have to reconnect the front panel (or connect a stand alone switch).

(Naturally, you want to make sure that your BIOS has a reliable 'always power on when AC power comes back' setting before you disconnect the chassis power switch from the motherboard. Otherwise you may wind up having an annoying time. This is definitely one of those changes that you want to make in the right order.)

ATXChassisPowerSwitchNotes written at 23:09:36; Add Comment


A practical issue with YAML: your schema is not actually documentation

These days, YAML is used as the configuration file format for an increasing amount of systems that I need to set up and operate for work. I have my issues with YAML in general (1, 2), but in the process of writing configuration files for programs that use YAML, I've found an entirely practical one, which I will summarize this way: a YAML schema description is not actually documentation for a system's configuration file.

It's entirely possible to write good documentation for a configuration system that happens to use YAML as its format. But while showing people the schema is often easy, it's not sufficient. Even a complete YAML schema merely tells the reader what values can go where in your configuration file's structure. It doesn't tell them what those values mean, what happens if they're left out, why you might want to set (or not set) certain values, or how settings interact with each other.

(And people don't even always do complete YAML schemas. I've seen more than one where the value of some field is simply documented as '<string>', when in fact only a few specific strings have meaning and others will cause problems.)

I don't know why just dumping out your YAML schema is so popular as a way to do configuration file 'documentation'. Perhaps it's because you have to do it as a first step, and once you've done that it's attractive to add a few additional notes and stop, especially if you think the names of things in your schema are already clear about what they're about and mean. Good documentation is time consuming and hard, after all.

I suspect that this approach of reporting the schema and stopping is used for YAML things other than configuration files, but I haven't encountered such things yet. (I've only really encountered YAML in the context of configuration files, where it's at least better than some of the alternatives I've had to deal with.)

(All of this assumes that your configuration file is as simple as a set of keys and simple values. Not all configuration files are so simple, but systems with more complex values tend to write better documentation. Possibly this is because a dump of the schema is obviously insufficient when the values can be complex.)

YamlPracticalDocumentationIssue written at 22:55:24; Add Comment


An enforced 'real names only' policy forces people to advertise things

One of the ever popular ideas for a 'better Internet' (or a better service of some sort) brought up by potentially well intentioned people is that you should have to use your real name instead of any pseudonym. There are many, many problems with this idea and you can find it thoroughly answered (and debunked) in various places. But recently on the Fediverse I had an additional thought about it:

One of the not 100% obvious problems of a genuinely enforced "real names only" policy is that it forces a number of types of people to immediately broadcast various changes of status by renaming themselves to their new 'proper name'.

In re this rundown of other issues and how it's a bad idea in general:

If a place has a true, enforced "real names only" policy, it follows that you must not only use your real name when you create your account but also promptly change the real name for your account if your normal or legal real name changes. Interested or nefarious parties can then watch for such changes in name to detect interesting (to them) changes in status. Did you get married and change your last name? Broadcast that. Did you get divorced and change your last name back? Broadcast that. Did you decide to legally cut ties with your abusive family and change your name in the process? Again, you get to broadcast that.

(Of course, there are additional and more sensitive reasons to change a name, reasons that the person doing it may well very much not want to broadcast.)

Of course, if you don't update your real name, in practice the place will not automatically know that your listed real name is now incorrect and you're out of compliance with its policies. But this makes life dangerous for you, because by being in violation of policies you're handing any enemies a means of attacking your account; if they know of your change in status through other means, all they have to do is file a complaint.

(This is of course related to the issue that login names do change, as kind of the flipside of it.)

RealNamesBroadcastProblem written at 21:05:57; Add Comment


Why being able to partially distrust a Certificate Authority is good

One of the arguments I've heard against supporting partial distrust of Certificate Authorities in places like Linux root certificate stores (which you currently can't really do) is that a bad CA can simply backdate TLS certificates to get around things like 'certificates issued from December 1st 2022 onward won't be trusted'. On the one hand, this is technically true (although these days either such a TLS certificate wouldn't be usable in the majority of web browsers or it would soon be detected through Certificate Transparency logs). On the other hand, there are a collection of reasons to think that it's a good thing that browser can do this sort of thing (and thus that more software should support it).

The original view of CA trust was that it was binary; either the CA was working perfectly fine and would in the future, or the CA was entirely bad and compromised, and should be distrusted immediately. While there have been some CA incidents like this, such as the DigiNotar compromise, in practice a significant number of the CA problems that have come up over the years have been less clear cut than this, such as the WoSign case (and the WoSign case was exceptionally bad in that WoSign actively issued bad TLS certificates). The recent case of TrustCor is illustrative; as far as was reported to Mozilla (and summarized by them), TrustCor never mis-issued any TLS certificates or committed any other clear violations of CA requirements. They were merely sketchy.

The problem with fully distrusting a CA is that you cause problems for people (and software) talking to legitimate sites making legitimate use of TLS certificates from the CA. Sometimes (as with DigiNotar) there is no real choice, but often there is a balance between the harm you would do now and the harm that you will prevent in the future (and perhaps now). A partial distrust is a way to shift the balance of harm, so that you do less harm to people today at an acceptable cost for potential future harm. By reducing the clear cost, you make people more likely to take action, which improves the situation even if it's not theoretically perfect.

(Distrusting a questionable CA a year in the future, or six months in the future, or a month in the future, or starting now, is better than continuing to trust it without limit.)

The second order effect of being able to partially distrust a CA is that it gives browsers more power compared to CAs. To copy the joke about owing a bank money, if you entirely distrust a popular CA today, that's your problem (people will blame you for the scary TLS messages), while if you distrust a CA starting in six months, that's much more the CA's problem. Being able to credibly threaten CAs with distrusting future TLS certificates without breaking current users is a powerful weapon, and browsers have repeatedly been able to use it to force changes in CA behavior.

(This includes somewhat more subtle issues like browsers limiting the trust interval (starting with future certificates) or requiring CT log attestations starting at a certain point. Both of those were 'partial distrust' issues in that they initially applied to future TLS certificates, not current ones.)

Today, Linux and more generally Unix software is out in the cold on these decisions and is stuck in the binary world, with the binary choices about how many people they harm today in exchange for harm reduction. Ubuntu entirely removing TrustCor's certificates is probably the right decision overall, but it does potentially harm people using Ubuntu who have previously been talking to hosts with TrustCor TLS certificates.

CAPartialDistrustWhyGood written at 23:44:08; Add Comment


The annoying question of Intel CPU support for XMP RAM profiles

I said something on the Fediverse:

Once again I must applaud Intel for making it as hard as possible to find out if XMP RAM profiles work on Intel desktop CPUs that can't be overlocked (non-K series, or whatever it is today). Will they give you a definite answer, even in their website's XMP FAQ? Of course not.

(And I genuinely don't know what the answer is, especially today.)

Here, 'XMP' is the common and official abbreviation for '(Intel) Extreme Memory Profile, which potentially allows you to run your DIMMs at higher speeds than the official JEDEC RAM timings. AMD has an equivalent version (cf Wikipedia), but apparently many AMD motherboards also support using XMP DIMM timing information. As covered in the WikiChip entry on XMP, XMP information comes from the DIMM(s) via SPD and as far as I know is then interpreted by the BIOS, if enabled.

The situation with XMP/EXPO support on AMD desktop Ryzen CPUs is straightforward; as far as I know, they all support it, leaving you only a question of whether the motherboard does. The situation with Intel CPUs is much less clear, and this is a deliberate choice on Intel's part. Having poked around, there seem to be two answers.

The practical answer is that it seems that non-overclockable Intel desktop CPUs have traditionally supported XMP; I've even seen assertions in online sources that faster XMP speeds mostly don't involve the CPU at all, so it's all up to the motherboard and its BIOS. It used to be that you had to use Intel's top end Z series chipsets to get XMP support, but these days apparently B series chipsets also support it. So it seems likely that if you buy a non K-series Core series desktop CPU and pair it with XMP capable DIMMs on a suitable motherboard, you will get faster RAM.

(How much of a difference faster RAM will make is an open question, but I've read some things that suggest it's especially helpful if you're using integrated graphics, as I am on my problematic home desktop.)

The Intel answer is that while Intel won't say that you have to have an overclockable K-series Core desktop CPU in order to use XMP, all of their examples of qualified DIMMs and systems with desktop CPUs use overclockable ones as far as I can see. Intel certainly wants you to buy a K-series Core i5/i7/i9 CPU if you want to use XMP and it will clearly do quite a lot to nudge you that way without actually saying anything untrue that could get it in trouble with authorities (such as 'on desktop CPUs, you must have a K-series overclockable CPU', which is likely false today since Intel isn't actually saying that).

Since Intel only officially qualifies K-series Core desktop CPUs, this lets Intel off the hook if XMP doesn't work with a non-K CPU in your configuration, even if it looks like everything should be fine. Will the uncertainty help push you toward spending a bit extra on a K-series CPU? Intel certainly hopes so. With that said, it does appear that the price difference between K-series and non K-series CPUs may have gotten fairly small (for the moment). Still, the whole thing is yet another irritation of dealing with Intel's desktop CPU market segmentation.

(I wrestled with DDR RAM speed questions a few years ago, with no answers then either.)

IntelCPUsAndXMPAnnoyance written at 21:39:29; Add Comment

(Previous 10 or go back to November 2022 at 2022/11/27)

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.