Significant improvement in speed accuracy by moving the raw speed collector to right after the 0.3 second (tunable via setting or switch) sleep that is designed to let the CPU 'spin down' so the inxi speed report is much closer to the actual state of the cpu cores without running inxi. This is VERY noticeable on some types of cpus, particularly on cpus with 4 or less threads. But I see a significant general drop in average speeds as well.
For example, on a 2 cpu 32 core epyc, 1 thread using the new method spikes noticeably from base level, but 3-4 did using the previous pinxi method. On things like Intel Core cpus, it's dramatically improved. Ryzen maybe less so, but still noticeable.
These changes are in pinxi 3.3.09-21
It looks like raising the flag of surrender on trying to deduce with no way to know if cache is L1, L2, or L3 in fallback cpuinfo mode is correcting the legacy system cache output/handling bugs. Sometimes it's best to know when to give up on something that is clearly not working anyway, and is causing the bugs as often as fixing them.
One thing I'm not sure if /sys has for L1 is this one:
Level 1 cache size ? 12K micro-operations 8-way set associative execution trace cache
It has Data, Instruction, but haven't seen a trace cache in /sys data so far.
Really great stuff, thanks so much for the help and data and feedback so far!
There's a few other features that you will only see on something like Alder Lake, a report on how many single threads, and how many multi, the cpu has.
And dies, which almost nothing has apparently, that looks like this:
Code:
pinxi -Cay
CPU:
Info: 2x 16-Core (4-Die) model: AMD EPYC 7281 bits: 64 type: MT MCP MCM SMP
arch: Zen family: 17 (23) model-id: 1 stepping: 2 microcode: 8001250 cache:
L1: 2x 1.5 MiB (3 MiB) desc: d-16x32 KiB; i-16x64 KiB L2: 2x 8 MiB (16 MiB)
desc: 16x512 KiB L3: 2x 32 MiB (64 MiB) desc: 8x4 MiB
...
-----------------------------------------
Eeel, that's an interesting point, I wonder how much of this depends on the kernel. Based on what I see on cpu-world.com, it looks like the data pinxi is getting for caches from sys is using the same exact data source as the cpu-world.com data collector (they also rely, like me, lol, on user data for their cpuid stuff), which makes me think this comes from cpuid itself, mapped to /sys data structures.
I actually wish /sys would have the rest of the cpu data, the flags, model, family, stepping, etc, then I could totally skip cpuinfo for data.
Would be interesting to see if you see any differences with different kernel, that's a good idea.
-----------------------------------------
drumz, that's an interesting system, slightly annoying that inxi defaults to 1 decimal for MiB output, but this cpu has 3.25 MiB cache, which you can see in the (60.5 MiB), but I'll live with that slight inaccuracy since that size cache is very rare. But another good example to show what variations can happen in this data, up until this one I'd only seen L3 be even MiB numbers.
-----------------------------------------
avian, pentium 1 would be impressive, on that one I wouldn't mind seeing a full:
output just to see what happens. Quite a few oversight/'wrong assumption re data always being there' bugs have been caught so far from the various machines that have been posted, thi is making a real difference to the overall quality and robustness of inxi, not just the cpu stuff.
Intel Core2 Duo T8100 is a good example of the failure of the first try for this fix on inxi 3.3.09, the assumption of 1 L2 per core resulted in wrong results, even with the newer logic. That's why I dumped it all by the way, that also wasn't fixable. Though 3.3.09 was signnificantly better than 3.3.08, it just didn't have a real fix in it for these various issues. 3.3.09 was actually released mainly because there were a bunch of other bugs and issues handled in pinxi that had been waiting for a while to get to master branch inxi so I figured I'd do a quick 3.3.09 then do this real final one since I didn't know how long this would take to get done.
-----------------------------------------
fourtysixandtwo, thanks so much for firing up these old systems, that type of data is very useful to trap and locate areas where inxi is assuming data will always be one way (like stepping: being an integer, always). That's the first time I've seen 'unknown' in those fields, I'll have to add some filters there I think, I will go in and modify the global filtering tools since I've found a few variations already in this thread's samples that the tools did not handle.
Also reminds me to finalize the output for cache: when nothing is found at all, that should have said:
cache: N/A, not cache: L2: N/A
That's corrected in 3.3.09-21. Stepping: 0 should have been stepping: N/A, or just not showing, that's also fixed, I think.
AMD Athlon XP 1800+ looks good, arch: right, etc.
Intel Pentium 4, the fix for the Data L1 only cache working fine, that's good. Microarchitecture lookup table matches seem to be fairly solid now. Tweaked the arch: to show stepping 1, Netburst Prescott, I'd never found stepping data for the Netburst model Ids.
https://www.cpu-world.com/CPUs/Penti...6PE2800E).html
Celeron (Coppermine) looks like the cache data came from dmidecode, and the speed data probably came from cpuinfo, which means it's all working now in terms of the fallbacks clicking in to fill in missing data.
-----------------------------------------
