Wandering Thoughts


Networks form through usage and must be maintained through it

I recently read The network's the thing (via, itself probably via). One of the things this article is about is how for many companies, the network created by your users is the important piece, not the product itself; you can change the product but retain the network and win, despite the yelling of aggravated users. My impression is that this is a popular view of companies, especially companies with social networks.

(Purely social networks are not the only sort of networks there are. Consider Github; part of its value is from the network of associations among users and repositories. This is 'social' in the sense that it involves humans talking to each other, but it is not 'social' in the sense that Twitter, Facebook, and many other places are.)

On the one hand, this "networks matter but products don't" view is basically true. On the other hand, I think that this is a view that misses an important detail. You see, users do not form (social) networks on services out of the goodness of their hearts. Instead, those social networks form and remain because they are useful to people. More than that, they don't form in isolation; instead they're created as a side effect of the usefulness of the service itself to people, and this usefulness depends on how the service works (and on how people use it). People create the network by using the product, and the network forms only to the extent and in the manner that the product is useful to them.

As a corollary, if the product changes enough, the network by itself will not necessarily keep people present. What actually matters to people is not the network as an abstract thing, it's the use they get out of the network. If that use dries up because the product is no longer useful to them, well, there you go. For example, if people are drawn to Twitter to have conversations and someday Twitter breaks that by changing how tweets are displayed and threaded together so that you stop being able to see and get into conversations, people will drift away. Twitter's deep social network remains in theory, but it is not useful to you any more so it might as well not exist in practice.

In this sense, your network is not and cannot be separated from your core product (or products). It exists only because people use those products and they do that (in general) because the products help them or meet some need they feel. If people stop finding your product useful, the network will wither. If different people find your product useful in different ways, the shape of your (active) network will shift.

(For example, Twitter's network graph will probably look quite different if it becomes a place where most people passively follow a small number of 'star' accounts and never interact with most other people on Twitter.)

At the same time, changes in the product don't necessarily really change the network because they don't necessarily drastically change the use people get out of the service. To pick on Twitter again, the length of tweets or whether or not their length counts people mentioned in them are not crucial to the use most people get out of Twitter, for all that I know I heard yelling about both.

NetworksMustBeUseful written at 00:44:17; Add Comment


The superficial versus deep appeal of ZFS

Red Hat recently announced Stratis (for a suitable value of 'recently'). In their articles introducing it, Red Hat says explicitly that they looked at ZFS, among other similar things, and implies that they did their best to take the appealing bits from ZFS. So what are Stratis's priorities? Let's quote:

Stratis aims to make three things easier: initial configuration of storage; making later changes; and using advanced storage features like snapshots, thin provisioning, and even tiering.

If you look at ZFS, it's clear where Stratis draws inspiration from both ZFS features and ZFS limitations. But it's also clear what the Stratis people see as ZFS's appeals (especially in their part 2); I would summarize these as flexible storage management (where you have a pool of storage that can be flexibly used by filesystems) and good command line tools.

These are good appeals of ZFS, make no mistake. I like them myself, and chafe when I wind up dealing with less flexible and more cumbersome storage management via LVM. But as someone who's used ZFS for years, it's also my opinion that they are superficial appeals of ZFS. They're the obvious things that you notice right away when you start using ZFS, and for good reason; it's very liberating to not have to pre-assign space to filesystems and so on.

(Casually making a snapshot before some potentially breaking change like switching Firefox versions and then being able to retrieve files from the snapshot in order to revert is also a cool trick.)

However, the longer I've used it the more I've come to see the deep appeal of ZFS as its checksums and how these are deeply integrated into its RAID layer to enable things like self-healing (such deep integration is required for this). You generally can't see this appeal right away, when you just set up and use ZFS. Instead you have to use ZFS for a while, through scrubs, disks that develop problems, and perhaps ZFS noticing and repairing damage to your pool without losing any data. This reassurance that your data is intact and repairable is something I've come to really treasure in ZFS and why I don't want to use anything without checksums any more.

On the whole, Stratis (or at least the articles about it) provides an interesting mirror on how people see ZFS and how that's different from my view of ZFS. Probably there are lessons for how people view many technologies, and certainly I've experienced this sort of split in other contexts.

ZFSAppealLevels written at 23:11:51; Add Comment


Intel versus AMD for me (in 2018)

I don't particularly like Intel for all sorts of reasons (eg), and as a result I want to like AMD (who I think have been very good for x86 in general when they've been competitive). I'm now in the unusual position (for me) of having essentially comparable machines built with a top end CPU from each; my work machine with a Ryzen 1800X, and my home machine with an i7-8700K. This has given me about the best Intel versus AMD comparison for what I want that I could ask for, and unfortunately it's not close.

For everything I care about, my Intel machine pretty much smokes my AMD machine. It has lower practical power consumption, it appears to run cooler (although CPU power usage is unpredictable and variable between CPUs), it's widely recognized as having faster single-CPU performance, and my Intel machine even builds Firefox from source significantly faster than my AMD machine does despite the AMD machine's more CPUs. There are undoubtedly highly parallel tasks that my AMD machine would perform better on than my Intel does, but they're irrelevant to me because I don't do them (at least so far).

(It's possible that RAM speed is one factor in the difference in Firefox build times, but this is a practical comparison. I can get faster non-ECC RAM for the Intel machine than we could get ECC RAM for the AMD machine, and Ryzens have complicated memory speed issues.)

The next issue, of course, is that my Intel machine is quite stable and my Ryzen machine (still) requires magic. My Ryzen does appear to now be stable with its magic, but I'm doing peculiar things to get there that likely have their own side effects and I'm never entirely sure that my Ryzen is completely trustworthy. One of my co-workers has a Ryzen Pro based machine (with the same motherboard and so on), and it hangs in the same way. Perhaps the new 2xxx Ryzens don't have this problem, but who knows, and as far as I'm concerned the mere fact that mysterious problems exist (and haven't been acknowledged by AMD) is a black mark against all Ryzens in practice. They're just not CPUs that I can trust at this point.

In summary, I'm very happy that I wound up choosing Intel for the machine that I spent my own money on. I'm still not particularly happy about my work AMD machine, and I'd be even less happy if I'd spent my own money on it. My office AMD machine works and it's okay, but the Intel one is clearly better, makes me happier, and I trust it significantly more.

(I'm also glad that I talked myself into going all the way up to an Intel i7 8700K, but that involves some extra hand waving that I'm not going to do in this entry.)

In terms of cost, I believe that my Intel machine was cheaper in practice for me. This is not an apples to apples comparison since my AMD machine's Radeon RX 550 is clearly a better GPU than the onboard Intel graphics, but again it's a practical one. With the Intel machine I could completely rely on the motherboard, while the AMD machine required an extra and not entirely cheap component for my usage case (which is one where I still won't use nVidia cards because of lacking open source support).

MyIntelVsAMDView-2018 written at 00:17:09; Add Comment


An incomplete list of reasons why I force-quit iOS apps

As a result of having iOS devices, I've wound up reading a certain amount of things about using iOS and how you're supposed to do that. One of the things that keeps coming up periodically is people saying 'don't force-quit iOS apps, it's a bad idea'. What reading a number of these articles has shown me is that people seem to have somewhat different views about why you might want to force-quit iOS apps than I do, and often more narrow ones. So here is an incomplete list of reasons why I end up force-quitting iOS apps:

  • To remove the app from the carousel display of 'recently used' apps. In order to make this carousel usable (especially on my phone), I curate it down to only the apps that I'm actively using and I want to switch between on a regular basis. If I use an app only once in a while, I will typically eject it from the carousel after use.

    (I also eject apps that I consider sensitive, where I don't want their screen showing when I cycle through the apps.)

  • To force Termius to require a thumbprint to unlock, even if it's immediately used again. Termius's handling of SSH keys is a bit like sudo, and like sudo I want to get rid of any elevated privileges (such as unlocked keys) the moment that I know I don't need them again. Generally this overlaps with 'remove an unused app from the carousel', since if I'm forcing Termius to be explicitly unlocked again I'm not planning to use it in the near future.

  • To get the app back to its initial screen. I've read a proposal that this should be the only thing that a 'force-quit' does in a future iOS version.
  • To abort or discard something that an app is doing. Sometimes resetting an app back to its initial screen is the easiest way to get it out of some activity, because the app itself is quite insistent that you not have any easier way of outright cancelling things.

    (In the case that comes up for me, the app in question is trying to avoid data loss, but as it happens I want to lose the 'data' in question.)

  • To restart an app because it seems to have gotten itself into some bad or hung state.

  • To stop an app from talking to another device because I'm about to do something to the other device that I know the app will react badly to, for example restarting the device.

  • To hopefully stop an app being active in the background for whatever reason it thinks it has for doing that. There are some settings that probably control this, but it's not entirely clear and there are apps that I sometimes want to be (potentially) active in the background and sometimes definitely don't want active, for example because their purpose is over for the moment.

  • To force an app out when I don't entirely trust it in general and only want it to be doing anything when I'm actually running it. Sure, I may have set permissions and settings, but the iOS permissions stuff is somewhat intricate and I'm not always sure I've gotten everything. So out it goes as a fairly sure solution.

What strikes me about these different reasons I have for force-quitting apps is how they'd be hard to provide in distinct app UIs or system UIs. Some of them perhaps should be handled in the app (such as locking Termius), but there's only so much room for app controls and there's always more features to include. And it makes sense that an app doesn't want to provide a too-accessible way of doing something that causes data loss, and instead leaves it up to you to do something which you've probably been told over and over is exceptional and brutal.

The other UI advantage of force-quit as a way of resetting an app's state is that it's universal. You don't have to figure out how to exit some particular screen or state inside an app using whatever odd UI the app has; if you just want to go back to the start (more or less), you know how to do that for every app. My feeling is that this does a lot to lessen my frustrations with app UIs and somewhat encourages exploring app features. This is also an advantage for similar effects that I want to be universal, such as cutting off an app's ability to do things in the background.

(In general, if I feel that an app is misbehaving the last thing I want to have to do is trust it to stop misbehaving. I want some outside mechanism of forcing that.)

IOSAppsForceQuitWhy written at 23:13:11; Add Comment


Registering for things on the Internet is dangerous these days

Back in the old days (say up through the middle of the 00s), it was easily possible to view registering for websites, registering products on the Internet, and so on as a relatively harmless and even positive activity. Not infrequently, signing up was mostly there so you could customize your site experience and preferences, and maybe so that you could get to hear about important news. Unfortunately those days are long over. On today's Internet, registration is almost invariably dangerous.

The obvious problem is that handing over your email address often involves getting spam later, but this can be dealt with in various ways. The larger and more pernicious danger is that registering invariably requires agreeing to people's terms of service. In the old days, terms of service were not all that dangerous and often existed only to cover the legal rears of the service you were registering with. Today, this is very much not the case; most ToSes are full to the brim of obnoxious and dangerous things, and are very often not in your benefit in the least. At the very least, most ToSes will have you agreeing that the service can mine as much data from you as possible and sell it to whoever it wants. Beyond that, many ToSes contain additional nasty provisions like forced arbitration, perpetual broad copyright licensing for whatever you let them get their hands on (including eg your profile picture), and so on. Some but not all of these ToS provisions can be somewhat defanged by using the service as little as possible; on the other hand, sometimes the most noxious provisions cut to the heart of why you want to use the service at all.

(If you're in the EU and the website in question wants to do business there, the EU GDPR may give you some help here. Since I'm not in the EU, I'm on my own.)

Some Terms of Service are benign, but today ToSes are so long and intricate that you can't tell whether you have a benign or a dangerous one (and anyway, many ToSes are effectively self-upgrading). Even with potentially dangerous ToSes, some companies will never exercise the freedom that their ToS nominally gives them, for various reasons. But neither is the way to bet given an arbitrary company and an arbitrary ToS. Today the only safe assumption is that agreeing to someone's Terms of Service is at least a somewhat dangerous act that may bite you at some point.

The corollary to this is that you should assume that anyone who requires registration before giving you access to things when this is not actively required by how their service works is trying to exploit you. For example, 'register to see this report' should be at least a yellow and perhaps a red warning sign. My reaction is generally that I probably don't really need to read it after all.

(Other people react by simply giving up and agreeing to everything, taking solace in the generally relatively low chance that it will make a meaningful difference in their life one way or another. I have this reaction when I'm forced to agree to ToSes; since I can neither meaningfully read the terms nor do anything about them, what they are don't matter and I just blindly agree. I have to trust that I'll hear about it if the terms are so bad that I shouldn't agree under any circumstances. Of course this attitude of helplessness plays into the hands of these people.)

DangerousRegistration written at 00:20:59; Add Comment


Almost no one wants to run their own infrastructure

Every so often, people get really enthused about the idea of a less concentrated, more distributed Internet, one where most of our email isn't inside only a few places, our online chatting happens over federated systems instead of Twitter, there are flower gardens of personal websites and web servers, there are lots of different Git servers instead of mostly Github, and so on. There are many obstacles in the way of this, including that the current large providers don't want to let people go, but over time I have come to think that a large underappreciated one is simply that people don't want to run their own infrastructure. Not even if it's free to do so.

I'm a professional system administrator. I know how to run my own mail and IMAP server, and I know that I probably should and will have to some day. Do I actually run my own server? Of course not. It's a hassle. I have things on Github, and in theory I could publish them outside Github too, on a machine where I'm already running a web server. Have I done so? No, it's not worth the effort when the payoff I'd get is basically only feeling good.

Now, I've phrased this as if running your own infrastructure is easy and the only thing keeping people from doing so is the minor effort and expense involved. We shouldn't underestimate the effects of even minor extra effort and expense, but the reality is that doing a good job of your own infrastructure is emphatically not a minor effort. There is security, TLS certificates, (offsite) backups, choosing the software, managing configuration, long term maintenance and updates, and I'm assuming that someone else has already built the system and you just have to set up an instance of it.

(And merely setting up an instance of something is often fraught with annoyance and problems, especially for a non-specialist.)

If you use someone else's infrastructure and they're decently good at it, they're worrying about all of that and more things on top (like monitoring, dealing with load surges and DDOSes, and fixing things in the dead of night). Plus, they're on the right side of the issues universities have with running their own email; many such centralized places are paying entire teams of hard-working good people to improve their services (or at least the ones that they consider strategic). I like open source, but it's fairly rare that it can compete head to head with something that a significant company considers a strategic product.

Can these problems be somewhat solved? Sure, but until we get much better 'computing as a utility' (if we ever do), a really usable solution is a single-vendor solution, which just brings us back to the whole centralization issue again. Maybe life is a bit better if we're all hosting our federated chat systems and IMAP servers and Git repo websites in the AWS cloud using canned one-click images, but it's not quite the great dream of a truly decentralized and democratic Internet.

(Plus, it still involves somewhat more hassle than using Github and Twitter and Google Mail, and I think that hassle really does matter. Convinced people are willing to fight a certain amount of friction, but to work, the dream of a decentralized Internet needs to reach even the people who don't really care.)

All of this leads me to the conclusion that any decentralized Internet future that imagines lots of people running their own infrastructure is dead on arrival. It's much more likely that any decentralized future will involve a fair amount of concentration, with many people choosing to use someone else's infrastructure and a few groups running most of it. This matters because running such a big instance for a bunch of people generally requires real money and thus some way of providing it. If there is no real funding model, the whole system is vulnerable to a number of issues.

(See, for example, Mastodon, which is fairly centralized in practice with quite a number of large instances, per the instance statistics.)

NoPersonalInfrastructure written at 00:52:55; Add Comment


Modern CPU power usage varies unpredictably based on what you're doing

I have both an AMD machine and an Intel machine, both of them using comparable CPUs that are rated at 95 watts TDP (although that's misleading), and I gathered apples to apples power consumption numbers for them. In the process I discovered a number of anomalies in relative power usage between the two CPUs. As a result I've wound up with the obvious realization that modern CPUs have complicated and unpredictable power usage (in addition to all of the other complicated things about them).

In the old days, it was possible to have a relatively straightforward view of how CPU usage related to power draw, where all you really needed to care about was how many CPUs were in use and maybe whether it was integer or floating point code. Not only is that is clearly no longer the case, but what factors change the power usage vary from CPU model to CPU model. My power consumption numbers show one CPU to CPU anomaly right away, where an infinite loop in two shells has one shell using more power on a Ryzen 1800X and the other shell using more power on an i7-8700K. These two shells are running the same code on both CPUs and each shell's code is likely to be broadly similar to the other, but the CPUs are responding to it quite differently, especially when the code is running on all of the CPUs.

Beyond this anomaly, there is also that this simple 'infinite shell loop' power measurement showed a different (and higher) power usage than a simple integer loop in Go. I can make up theories for why, but it's clear that even if you restrict yourself to integer code, a simple artificial chunk of code may not have anywhere near the same power usage as more complex real code. The factors influencing this are unlikely to be simple, and they also clearly vary from CPU to CPU. 'Measure your real code' has always been good advice, but it clearly matters more than ever today if you care about power usage.

(The corollary of 'measure your real code' is probably that you have to measure real usage too; otherwise you may be running into something like my Bash versus rc effect. This may not be entirely easy, to put it one way.)

It's not news these days that floating point operations and especially the various SIMD instructions such as AVX and AVX-512 use more power than basic integer operations; that's why people reach for mprime as a heavy-duty CPU stress test, instead of just running integer code. MPrime's stress test itself is a series of different tests, and it will probably not surprise you to hear that which specific tests seemed to use the most power varied between my AMD Ryzen 1800X machine and my Intel i7-8700K machine. I don't know enough about MPrime's operation to know if the specific tests differ in what CPU operations they use or only in how much memory they use and how they stride through memory.

(One of the interesting differences was that on my i7-8700k, the test series that was said to use the most power seemed to use less power than the 'maximum heat and FPU stress' tests. But it's hard to say too much about this, since power usage could swing drastically from sub-test to sub-test. I saw swings of 20 to 30 watts from sub-test to sub-test, which does make reporting a 'mprime power consumption' number a bit misleading.)

Trying to monitor the specific power usage of MPrime sub-tests is about where I decided both that I'd run out of patience and that the specific details were unlikely to be interesting. It's clear that what uses more or less power varies significantly between the Ryzen 1800X system and the i7-8700K system, and really that's all I need to know. I suspect that it basically varies between every CPU micro-architecture, although I wouldn't be surprised if each company's CPUs are broadly similar to each other (on the basis that the micro-architectures and the design priorities are probably often similar to each other).

PS: Since I was measuring system power usage, it's possible that some of this comes from the BIOS deciding to vary CPU and system fan speeds, with faster fan speeds causing more power consumption. But I suspect that fan speed differences don't account for all of the power draw difference.

VaryingCPUPowerDraws written at 01:13:11; Add Comment


How I usually divide up NFS (operation) metrics

When you're trying to generate metrics for local disk IO, life is generally relatively simple. Everyone knows that you usually want to track reads separately from writes, especially these days when they may have significantly different performance characteristics on SSDs. While there are sometimes additional operations issued to physical disks, they're generally not important. If you have access to OS-level information it can be useful to split your reads and writes into synchronous versus asynchronous ones.

Life with NFS is not so simple. NFS has (data) read and write operations, like disks do, but it also has a large collection of additional protocol operations that do various things (although some of these protocol operations are strongly related to data writes, for example the COMMIT operation, and should probably be counted as data writes in some way). If you're generating NFS statistics, how do you want to break up or aggregate these other operations?

One surprisingly popular option is to ignore all of them on the grounds that they're obviously unimportant. My view is that this is a mistake in general, because these NFS operations can have an IO impact on the NFS server and create delays on the NFS clients if they're not satisfied fast enough. But if we want to say something about these and we don't want to go to the extreme of presenting per-operation statistics (which is probably too much information, and in any case can hide patterns in noise), we need some sort of breakdown.

The breakdown that I generally use is to split up NFS operations into four categories: data reads, data writes (including COMMIT), operations that cause metadata writes such as MKDIR and REMOVE, and all other operations (which are generally metadata reads, for example READDIRPLUS and GETATTR). This split is not perfect, partly because some metadata read operations are far more common (and are far more cached on the server) than other operations; specifically, GETATTR and ACCESS are often the backbone of a lot of NFS activity, and it's common to see GETATTR as by far the most common single operation.

(I'm also not entirely convinced that this is the right split; as with other metrics wrestling, it may just be a convenient one that feels logical.)

Sidebar: Why this comes up less with local filesystems and devices

If what you care about is the impact that IO load is having on the system (and how much IO load there is), you don't entirely care why an IO request was issued, you only care that it was. From the disk drive's perspective, a 16 KB read is a 16 KB read, and it takes as much work to satisfy a 16 KB file as it does a 16 KB directory or a free space map. This doesn't work for NFS because NFS is more abstracted, and both the amount of operations and the amount of bytes that flow over the wire don't necessarily give you a true picture of the impact on the server.

Of course, in these days of SSDs and complicated disk systems, just having IO read and write information may not be giving you a true picture either. With SSDs especially, we know that bursts of writes are different from sustained writes, that writing to a full disk is often different than writing to an empty one, and apparently giving drives some idle time to do background processing and literally cool down may change their performance. But many things are simplifications so we do the best we can.

(Actual read and write performance is a 'true picture' in one sense, in that it is giving you information about what results the OS is getting from the drive. But it doesn't necessarily help to tell you why, or what you can do to improve the situation.)

NFSMyMetricsSplit written at 01:44:01; Add Comment


My new 4K HiDPI display really does make a visible difference

As peculiar as it sounds, I had no idea if I'd see a clear visible difference from moving up to my new 4K HiDPI display before I got it. In fact I more or less expected it to not be a big change from my previous monitor (a 24" 16:10 Dell U2412M). I'd read people raving about the Retina displays on Mac laptops, but people have different standards for what they consider rave-worthy (and what they notice about displays). And it wasn't as if my existing display was clearly pixelated or low-resolution, the way old computer displays definitely were. I though that perhaps I already was in the zone of diminishing returns for increased display density.

A little bit to my surprise, it turns out that my new display does make a clearly visible difference. I didn't see this right away, when I first set it up, and even after I'd used it for an evening or two. What it took to make this really apparent was having my environment settle down and then going back and forth between work (where I'm using Dell U2412Ms) and home. I use the same fonts at almost the same physical size at home and work, and after things settled down it was clear that my home display was visibly crisper and clearer.

Interestingly, the really clear example for me was the / character in terminal windows (and thus in a monospaced font). At work on a 94 PPI screen, I could notice that it had a bit of 'staircase' pixelization; not glaring or obtrusive, but the kind of thing I could see if I was paying attention. At home, on a 163 PPI screen, there are no pixels even if I peer closely (far more closely than I normally am at); it's a smooth slanted line.

(Now that I've noticed this effect at work, I can't unsee it, which is a tiny bit annoying. Fortunately the monospaced / is the only character where I'm really conscious of the difference, although other characters are also better and crisper.)

Text isn't the only thing that looks better at the display's resolution, either. Many program icons are sharper and nicer to look at (although some of them may also be physically bigger, because of scaling issues). Pictures in things like web browsers are a somewhat more mixed bag, but a fair amount of the time it works well (sometimes they get a bit fuzzy, presumably because browser scaling can only do so much).

Following my standard views, I haven't attempted to use physically smaller fonts on the new display. Small(er) fonts might now be more readable than before because they're crisper and smoother, but I still feel no particular urge to find out or to squeeze more text into the available space.

PS: My new display may also be somewhat brighter, which may have its own effects on apparent crispness and readability. I haven't gotten around to even checking the brightness and contrast settings at work, much less planning out an experiment to give me some sort of light level value (although smartphone cameras and the right apps probably make it possible).

Sidebar: Why I bought a 4K HiDPI display despite uncertainties

I've been looking forward to high-DPI displays for some time for their advantages in crisp, high resolution display of text and other things. I've been around computers long enough that I've seen screen text go from being clearly low-resolution pixelated fonts to being much better, so I was all in favour of taking another step forward toward screens that would look as good as print does. That was my logic for persuading myself to get a high-DPI 4K display; I'd theoretically been looking forward to it for years and ones I considered reasonably affordable were finally available, so it was time to step up to the plate.

(I'm very good at sitting on my hands and not buying things, even things I'll enjoy. It's not logical, but people aren't logical.)

4KHiDPIIsVisible written at 01:08:05; Add Comment


A CPU's TDP is a misleading headline number

The AMD Ryzen 1800X in my work machine and the Intel Core i7-8700K in my home machine are both 95 watt TDP processors. Before I started measuring things with the actual hardware, I would have confidently guessed that they would have almost the same thermal load and power draw, and that the impact of a 95W TDP CPU over a 65W TDP CPU would be clearly obvious (you can see traces of this in my earlier entry on my hardware plans). Since it's commonly said that AMD CPUs run hotter than Intel ones, I'd expect the Ryzen to be somewhat higher than the Intel, but how much difference would I really expect from two CPUs with the same TDP?

Then I actually measured the power draws of the two machines, both at idle and under various different sorts of load. The result is not even close; the Intel is clearly using less power even after accounting for the 10 watts of extra power the AMD's Radeon RX 550 graphics card draws when it's lit up. It's ahead at idle, and it's also ahead under full load when the CPU should be at maximum power draw. Two processors that I would have expected to be fundamentally the same at full CPU usage are roughly 8% different in measured power draw; at idle they're even further apart on a proportional basis.

(Another way that TDP is misleading to the innocent is that it's not actually a measure of CPU power draw, it's a measure of CPU heat generation; see this informative reddit comment. Generally I'd expect the two to be strongly correlated (that heat has to come from somewhere), but it's possible that something that I don't understand is going on.)

Intellectually, I may have known that a processor's rated TDP was merely a measure of how much heat it could generate at maximum and didn't predict either its power draw when idle or its power draw under load. But in practice I thought that TDP was roughly TDP, and every 95 watt TDP (or 65 watt TDP) processor would be about the same as every other one. My experience with these two machines has usefully smacked me in the face with how this is very much not so. In practice, TDP apparently tells you how big a heatsink you need to be safe and that's it.

(There are all sorts of odd things about the relative power draws of the Ryzen and the Intel under various different sorts of CPU load, but that's going to be for another entry. My capsule summary is that modern CPUs are clearly weird and unpredictable beasts, and AMD and Intel must be designing their power-related internals fairly differently.)

PS: TDP also doesn't necessarily predict your actual observed CPU temperature under various conditions. Some of the difference will be due to BIOS decisions about fan control; for example, my Ryzen work machine appears to be more aggressive about speeding up the CPU fan, and possibly as a result it seems to report lower CPU temperatures under high load and power draw.

(Really, modern PCs are weird beasts. I'm not sure you can do more than putting in good cooling and hoping for the best.)

TDPMisleading written at 02:04:17; Add Comment

(Previous 10 or go back to April 2018 at 2018/04/13)

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.