This makes me think about the battery indicator on my electric bike.
The battery indicator underestimates how much capacity is remaining. It sounds like with CPU utilization, the issue is that it overestimates how much capacity is remaining.
How much capacity remains depends on how it is being used. Slope and pedal assist level are probably the two big things for e-bike batteries.
There seems to be a more general problem at play here, where some metric M is reported, what people actually care about is N, and M appears to be a better proxy for N than it actually is. I feel like in these situations what’d make sense would be to replace M with something less suggestive.
I also kinda feel like the concept of disguised queries applies here. With bleggs, it’s helpful to realize that you’re not really asking whether it’s a blegg, you’re asking whether it has vanadium. With batteries, you’re not really asking how much battery is remaining, you’re asking how many miles you could ride. And with CPU utilization, you’re not really asking what the raw number is, you’re asking how much more work you could do before you reach the limit. I might be misunderstanding or misapplying the concept of disguised queries though.
Yeah, I think the issue with batteries is actually even more similar to CPUs than you’d expect. Even on a “how much power is left” level, I think the software is trying to guess based on the voltage and some data about similar batteries. The actual amount of usable power is how much you can pull before the voltage drops to an unusable level, and that depends on things like manufacturing, age, temperature, the whims of chemical reactions, etc.
In the case of batteries, the software can make some reasonable assumptions and give you a helpfully-pessimistic estimate, but it’s hard to do that with CPUs since the possible range is so workload-dependent. In my matrix math / SIMD example, I’m doing 100% of the possible matrix math while using half the cores, but I could do some amount of other work using hyperthreads if it used the right resources. So the optimistic metric can overestimate by up to 100%, but that also means a pessimistic estimate would underestimate by up to 100%, and neither of those are particularly useful.
Even then, sometimes the assumption isn’t pessimistic enough and users will complain about e.g. their cell phone’s battery dropping immediately from 10% to 0% when they launch an app that causes the CPU to demand more current than the almost-dead battery can provide.
This makes me think about the battery indicator on my electric bike.
The battery indicator underestimates how much capacity is remaining. It sounds like with CPU utilization, the issue is that it overestimates how much capacity is remaining.
How much capacity remains depends on how it is being used. Slope and pedal assist level are probably the two big things for e-bike batteries.
There seems to be a more general problem at play here, where some metric M is reported, what people actually care about is N, and M appears to be a better proxy for N than it actually is. I feel like in these situations what’d make sense would be to replace M with something less suggestive.
I also kinda feel like the concept of disguised queries applies here. With bleggs, it’s helpful to realize that you’re not really asking whether it’s a blegg, you’re asking whether it has vanadium. With batteries, you’re not really asking how much battery is remaining, you’re asking how many miles you could ride. And with CPU utilization, you’re not really asking what the raw number is, you’re asking how much more work you could do before you reach the limit. I might be misunderstanding or misapplying the concept of disguised queries though.
Yeah, I think the issue with batteries is actually even more similar to CPUs than you’d expect. Even on a “how much power is left” level, I think the software is trying to guess based on the voltage and some data about similar batteries. The actual amount of usable power is how much you can pull before the voltage drops to an unusable level, and that depends on things like manufacturing, age, temperature, the whims of chemical reactions, etc.
In the case of batteries, the software can make some reasonable assumptions and give you a helpfully-pessimistic estimate, but it’s hard to do that with CPUs since the possible range is so workload-dependent. In my matrix math / SIMD example, I’m doing 100% of the possible matrix math while using half the cores, but I could do some amount of other work using hyperthreads if it used the right resources. So the optimistic metric can overestimate by up to 100%, but that also means a pessimistic estimate would underestimate by up to 100%, and neither of those are particularly useful.
Even then, sometimes the assumption isn’t pessimistic enough and users will complain about e.g. their cell phone’s battery dropping immediately from 10% to 0% when they launch an app that causes the CPU to demand more current than the almost-dead battery can provide.