[CLARIFIED] RAM identification method used by inxi 3.0.32 is a bit strange

[antikythera]

I replaced an old 8GB kit of Corsair Vengeance LP DDR3-1600 today with the 16GB of Patriot Viper 3 Black Mamba DDR3-1600 I ordered last week. I was running the Corsair in XMP profile and the board happily ran with it stably at 1600MHz, dmidecode saw as 1600 MT/s too. However inxi on the otherhand only saw it as 1333 MT/s which is the normal non-XMP mode frequency.

The new RAM is identified by both utilities properly at 1600 MT/s. I'm not sure why inxi differs and where it extracts this information from because clearly it's not the same source as dmidecode.

If the inxi developer sees this post the modules concerned are below. It's really not a major problem, just an observation. So with that in mind I don't really want to take the new RAM out again to test any newer version of inxi for this behaviour.

Corsair - CML8GX3M2A1600C9 ver. 4.21
Patriot - PV316G160C9K

[karlchen]

Try the current inxi version, which is 3.1.0.9. Or try the most recent beta even.

[antikythera]

I see the backports version is 3.1.0.9, the output for that seems identical to 3.0.32 for module information with the Patriots installed. dmidecode isn't much better at identifying the brand or part number of these new modules, I guess that's on Patriot which is not a brand I've used before.

Do you happen to know why there's a specific debbie build as opposed to the stable buster version which is the same 3.0.32 build number?

Adding the 5cm² case sticker that came with the modules will obviously make the PC faster

I'm not putting the affected Corsair Vengeance back in though. I've promised them to a friend and have actually just packaged them for posting to her.

Code: Select all

System:
  Kernel: 4.19.0-13-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
  Desktop: Cinnamon 4.6.7 tk: GTK 3.24.5 wm: Muffin 4.6.3 dm: LightDM 1.26.0 
  Distro: LMDE 4 Debbie base: Debian 10.2 buster 
Machine:
  Type: Desktop Mobo: Gigabyte model: AM1M-S2H v: x.x serial: N/A 
  UEFI: American Megatrends v: F2 date: 06/20/2014 
Memory:
  RAM: total: 15.61 GiB used: 1.84 GiB (11.8%) 
  Array-1: capacity: 16 GiB slots: 2 EC: None max module size: 8 GiB 
  note: est. 
  Device-1: DIMM 0 size: 8 GiB speed: 1600 MT/s type: DDR3 
  detail: synchronous unbuffered (unregistered) bus width: 64 bits 
  total: 64 bits manufacturer: N/A part-no: 1600 CL9 Series serial: N/A 
  Device-2: DIMM 1 size: 8 GiB speed: 1600 MT/s type: DDR3 
  detail: synchronous unbuffered (unregistered) bus width: 64 bits 
  total: 64 bits manufacturer: N/A part-no: 1600 CL9 Series serial: N/A 
CPU:
  Info: Quad Core model: AMD Athlon 5350 APU with Radeon R3 bits: 64 
  type: MCP arch: Jaguar rev: 1 L1 cache: 256 KiB L2 cache: 2048 KiB 
  flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm 
  bogomips: 16369 
  Speed: 799 MHz min/max: 800/2050 MHz volts: 1.3 V ext-clock: 100 MHz 
  Core speeds (MHz): 1: 799 2: 799 3: 798 4: 799 
Graphics:
  Device-1: NVIDIA GM206 [GeForce GTX 960] vendor: ASUSTeK driver: nvidia 
  v: 450.66 bus ID: 01:00.0 chip ID: 10de:1401 
  Display: server: X.Org 1.20.4 driver: nvidia resolution: 1280x1024 
  s-dpi: 96 
  OpenGL: renderer: GeForce GTX 960/PCIe/SSE2 v: 4.6.0 NVIDIA 450.66 
  direct render: Yes 
Audio:
  Device-1: AMD FCH Azalia vendor: Gigabyte driver: snd_hda_intel v: kernel 
  bus ID: 00:14.2 chip ID: 1022:780d 
  Device-2: NVIDIA GM206 High Definition Audio vendor: ASUSTeK 
  driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 10de:0fba 
  Sound Server: ALSA v: k4.19.0-13-amd64 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Gigabyte driver: r8168 v: 8.048.03-NAPI port: d000 bus ID: 02:00.0 
  chip ID: 10ec:8168 
  IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:
  Local Storage: total: 465.76 GiB used: 77.67 GiB (16.7%) 
  ID-1: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB 
  speed: 6.0 Gb/s serial: <filter> rev: 023 temp: 36 C scheme: GPT 
Partition:
  ID-1: / size: 449.74 GiB used: 77.67 GiB (17.3%) fs: ext4 dev: /dev/sda2 
Swap:
  ID-1: swap-1 type: partition size: 7.73 GiB used: 0 KiB (0.0%) 
  priority: -2 dev: /dev/sda3 
Sensors:
  System Temperatures: cpu: 37.0 C mobo: 35.0 C gpu: nvidia temp: 50 C 
  Fan Speeds (RPM): cpu: 0 fan-2: 760 fan-3: 0 fan-4: 0 fan-5: 0 gpu: nvidia 
  fan: 19% 
  Power: 12v: N/A 5v: N/A 3.3v: N/A vbat: 2.74 
Info:
  Processes: 187 Uptime: 2h 35m wakeups: 0 Init: systemd v: 241 runlevel: 5 
  Compilers: gcc: 8.3.0 alt: 8 Packages: apt: 2269 Shell: Bash (sudo) 
  v: 5.0.3 running in: gnome-terminal inxi: 3.1.09 

dmidecode

Code: Select all

Handle 0x002C, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 16 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x002D, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 16 GB
	Physical Array Handle: 0x002C
	Partition Width: 255

Handle 0x002E, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM 0
	Bank Locator: CHANNEL A
	Type: DDR3
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 1600 MT/s
	Manufacturer: <BAD INDEX>
	Serial Number: 00000000
	Asset Tag: A1_AssetTagNum0
	Part Number: 1600 CL9 Series
	Rank: 2
	Configured Memory Speed: 1600 MT/s

Handle 0x002F, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM 1
	Bank Locator: CHANNEL A
	Type: DDR3
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 1600 MT/s
	Manufacturer: <BAD INDEX>
	Serial Number: 00000000
	Asset Tag: A1_AssetTagNum1
	Part Number: 1600 CL9 Series
	Rank: 2
	Configured Memory Speed: 1600 MT/s

Handle 0x0030, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Device Handle: 0x002E
	Memory Array Mapped Address Handle: 0x002D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x0031, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00200000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 8 GB
	Physical Device Handle: 0x002F
	Memory Array Mapped Address Handle: 0x002D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

[h2-1]

inxi doesn't make up this data, it's from dmidecode, so your assumption that inxi changed something is wrong. dmidecode told it whatever speed inxi reported, inxi doesn't touch that particular part of ram data. There has been some speculation on my part whether the speeds reported by dmidecode reflect speed changes or if they are hardcoded static values, stuff OEMs type into a dmi table field. Your post seems to suggest that the former is the case, all else being correct, which is a big assumption.

However, I'm confused by the data you posted, dmidecode and inxi say it's 1600 MT/S, same value, so I don't understand even what the question is.

But those speeds are dmidecode, so I believe this is a case where inxi showed you something that is different from what you believed to be the case about something, which is frequently interpreted for some reason as inxi being wrong, lol... now with this said, I wouldn't bet much on the value of dmi ram data, the per stick stuff is decent, though I've never gotten feedback if ram is overclocked if the speed in dmidecode changes, that is, is that speed hardcoded or is it the actual speed the mobo is running the ram at? If you pause to think about it, inxi showed you dmidecode per stick ram speeds, so if you think that's different from dmidecode ram speeds somehow, well, that's something that would be a puzzle in logic, that is saying a is not a, although I think maybe sometimes you think a is a, but it's actually b, and that's what inxi told you, no, it's not a, it's b.

All hardcoded values in dmidecode, without exception, as far as I know, should be trusted no further than you can take your house and throw it across the street. There are two kinds of values, stuff provided by the actual hardware, and stuff typed in, or usually, not typed, copied pasted, or even more common, not entered at all, by some hapless overworked stressed our low level junior engineer, or maybe just the secretary, or someone who walked in at random one day.

In the case of ram, most of the data about the primary array, it's capacity, max per stick size, that's all garbage, cannot be trusted at all, some vendors supply decent data, but you can never trust it, inxi there does a better job than dmidecode because it tells you when values are impossible and guesses as to the right or at least possible ones. The per stick, that's item 17, is much better, which leads me to suspect that it's data that the stick itself reports to dmitable, and for some reason, the sticks don't seem subject to that random garbage. I assume they also have little dmi tables that are filled out, or not filled out, by the oem, that's totally random, if such things are a big deal to you, you have to pay a vendor who actually is willing to pay some human to do that job right, and do it consistently, which is rare.

[antikythera]

I'm not saying inxi changed something and wouldn't dream of it. I know you are very diligent and remember your posts requesting testers from manjaro forum as well for inxi and pinxi.

I just wondered if inxi accessed the SPD chip independently of dmidecode but my wording may not have been perfect on that score. The output above is for the new RAM which is indeed reported the same speed in both utilities, not the sticks I noticed the difference with. I posted them off this morning so no longer have them and it was merely an observation. I just wish I'd bothered pasting that output too, hindsight and all that. I'll see if my friend can send the Corsair output to me at some point and I'll post it as and when they do. All they wanted out of the freebie I sent them was a bump from the silly 6GB supplied by the manufacturer of their PC to 8GB interleaved dual channel.

I wouldn't have posted this at all though if I couldn't recreate it before and certainly wasn't imagining it either.

All hardcoded values in dmidecode, without exception, as far as I know, should be trusted no further than you can take your house and throw it across the street. There are two kinds of values, stuff provided by the actual hardware, and stuff typed in, or usually, not typed, copied pasted, or even more common, not entered at all, by some hapless overworked stressed our low level junior engineer, or maybe just the secretary, or someone who walked in at random one day.

That would definitely be the likely cause here then, funky programming from Corsair. Thanks for responding and clarifying my suspicions about the Corsair modules. Have a good weekend and a virtual beer on me.

[h2-1]

Believe me, if I could get the data from anywhere else reliably, I would, in fact, the man page for -m includes a statement that I waited, and waited, and finally gave up and used dmidecode. I was hoping the kernel guys would put some of the ram data into /sys, but it never happened, at least not that I'm aware of.

However, don't suggest that this is a programming error, lol, this is probably as I suggested, a low paid drone, maybe someone in an outsourced part of the company doing work they don't care about, literally just filling in a table by copy and pasting values into it, then calling it done. That's the dmitable, I don't know exactly how that works, but from what I can see, often, you can see fields with values like: To be Filled By O.E.M. which means, there is a template for a new dmi entry, and they didn't bother filling the field in, they just left the placeholder text.

In terms of trusting the outcomes, I trust what inxi says about array totals, capacity, max module size more than dmidecode, which is not in any way a criticism of dmidecode, that tool just decodes and prints the dmi table, it doesn't try to interpret the data or see if it's logically impossible, Sadly, inxi does try to do that, that was a very painful feature to implement, maybe one of the most painful because the source data was so bad, but what I learned there was that the stick data was decent, it almost always is what it says it is, but I never really checked to see if certain stick fields could also be similarly fictitious, never noticed it, but I don't know, I just know the per stick stuff is generally pretty reliable, and the array stuff should be taken with a large grain of salt. That's why you'll see note: check, note: est. to let you know that it's not trustworthy data in those cases. When it doesn't say it, it doesn't mean it's right, it just means that nothing logically contradicted itself, no modules were larger than declared max module size, array capacity was not less than actually installed ram sticks, etc.

Another one to not trust, though that one was one of the easiest features ever, in fact, I did it as a one off during pinxi 2.9 development just to test how easy it would be to add a full new line item feature, --slots, while it is often pretty much right, it's not always right, that may be because what you or I think of as a mobo slot is not necessarily the same as what your mobo thinks of as a mobo slot. I believe for example that a pcie nvme is considered as a pcie slot, even though it's not really a slot, it is sort of, but not really what I would call a pcie slot. I believe with --slots however that when it says it's occupied or available, it means it is, but I think I've seen cases where the mobo had more slots than --slots reported, but that's a mobo thing, not an inxi thing.

There's a certain category of data sources, dmidecode in inxi occupies, use only if no other source is readily available and it seems unlikely the data will ever show up in /sys, or it's just too hard to dig out of /sys, or /proc. dmesg is a category that is: worthless, don't even bother, can fill with kernel oops and contain no data of value, that's why inxi doesn't use dmesg. /sys is good, but subject to the same OEM junk data issue, since many parts of it get their data the same way dmidecode does, I believe, since see the same junk values.

Note I don't usually post in stuff about inxi, but I'm working on next major inxi, so I'm paying more attention, 3.2, pinxi has hit its highest ever patch number, 3.1.09-102, and it's still got a bit of fine tuning to go, -L/--logical, for stuff like lvm, luks, bcache, and various others, and -R rewrite, which adds lvm raid, and totally cleaned it up. I just got two of the core engines of -L working exactly as hoped.

But ram data in inxi, that's always been a disappointment to me, I always expected the kernel guys to consider it important enough to put it in /sys, but as noted, it just never happened, not sure why.

[antikythera]

Note I don't usually post in stuff about inxi

Entirely understandable. The new features sound quite interesting for future hardware investments.

I will post the output anyway so you'll have it if you check back in to the thread, she's agreed to send it and has the RAM already so it will be later today or tomorrow most likely. You never know with the postal service at the moment how long it will take for a package to be delivered with COVID and Christmas impacting the service. I expected Monday or Tuesday at the earliest.

I have my suspicions now where the difference I noticed may be. There are two speed values in dmidecode, namely Speed and Configured Speed. It's entirely possible that Speed says 1333 M/T and Configured Speed says 1600 M/T for those corsair sticks, inxi shows Speed only.

[antikythera]

She did as promised as soon as turning the machine on with the RAM fitted so here are the results, the speed and configured speed are indeed different.I'll mark this [CLARIFIED] rather than solved because it wasn't a problem to solve in the first place.

Code: Select all

inxi -mxxx

Memory:    RAM: total: 7.73 GiB used: 763.6 MiB (9.6%) 
           Array-1: capacity: 8 GiB slots: 2 EC: None max module size: 4 GiB note: est. 
           Device-1: DIMM 0 size: 4 GiB speed: 1333 MT/s type: DDR3 detail: synchronous unbuffered (unregistered) 
           bus width: 64 bits total: 64 bits manufacturer: CORSAIR part-no: CML8GX3M2A1600C9 serial: N/A 
           Device-2: DIMM 1 size: 4 GiB speed: 1333 MT/s type: DDR3 detail: synchronous unbuffered (unregistered) 
           bus width: 64 bits total: 64 bits manufacturer: CORSAIR part-no: CML8GX3M2A1600C9 serial: N/A

dmidecode

Handle 0x002C, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 8 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x002D, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Array Handle: 0x002C
	Partition Width: 255

Handle 0x002E, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM 0
	Bank Locator: CHANNEL A
	Type: DDR3
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 1333 MT/s
	Manufacturer: CORSAIR        
	Serial Number: 00000000
	Asset Tag: A1_AssetTagNum0
	Part Number: CML8GX3M2A1600C9  
	Rank: 1
	Configured Memory Speed: 1600 MT/s

Handle 0x002F, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM 1
	Bank Locator: CHANNEL A
	Type: DDR3
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 1333 MT/s
	Manufacturer: CORSAIR        
	Serial Number: 00000000
	Asset Tag: A1_AssetTagNum1
	Part Number: CML8GX3M2A1600C9  
	Rank: 1
	Configured Memory Speed: 1600 MT/s

Handle 0x0030, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x002E
	Memory Array Mapped Address Handle: 0x002D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x0031, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x002F
	Memory Array Mapped Address Handle: 0x002D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

[h2-1]

ah, that explains it, a speed field name inxi does not know about, I was half wondering if that was the case. I don't know how to read those two field names however, to me, speed is the actual speed, and configured speed is the speed something set it to, but it sounds like configured speed could be something else.

That's the problem with this type of data, there's these random variations and suddenly you see a dataset you've never seen before, with field name values you've never seen. Or at least, never seen and actually noticed.

This is by the way why I post in threads that may be exposing some new situation in inxi data, I can never know if it's nothing, something, or something new that I've never seen before. For example, a few weeks back I got a bug report on an ancient tyan server mobo, first generation dmi data, it was triggering many errors in inxi, it turned out, while that first generation data, which is different from the 16/17 variants you see on modern systems, was theoretically handled in inxi, but in fact had several bugs that made it totally unhandled, which triggered a small flood of null data errors from perl. And that's a board probably from 2000 or so...

https://unix.stackexchange.com/question ... speed-info

that confirms, configured speed is currently running speed, and speed is the theoretical highest, although as you can see in yours, that's not right, since the configured speed is higher, but I can tweak pinxi to handle that since it seems a simple override.

....

this gets funnier, inxi grabs configured clock speed, but it never used the data, I'd call that a bug. I think if configured is set, I will show speed and configured.

[h2-1]

Looking into this, as with all dmi data, it's not clear, not well documented, and possibly somewhat random. There can be I believe different causes for configured clock/memory speed being different, another example I found was because the person had two matching sticks, and got the 2x speed buost from matching in slots 1a and 2a. dual channel. In that case, 800 to 1600, so it looks like configured is the actual boot speed, configured is a super poorly chosen term, basically it means depending on how the system hardware is configured, that is, like paired for dual channel, overclocking, underclocking, etc, is the real speed. To avoid this weird use of the term configured, which to my ears suggests the exact opposite, the speed originally set by ram sticks, and speed suggests the speed it's actually running. So I will use the field name 'real:' I think, maybe something like: speed: listed: 1333 MT/S actual: 1600 MT/S

whew, I found the real answer, from a serious board maker:

https://supermicro.com/support/faqs/faq.cfm?faq=28430

Q: Under dmidecode, my 'Configured Clock Speed' is lower than my 'Speed'. What does each term mean and why are they not the same?

A: Under dmidecode, Speed is the expected speed of the memory (what is advertised on the memory spec sheet) and Configured Clock Speed is what the actual speed is now. The cause could be many things but the main possibilities are mismatching memory and using a CPU that doesn't support your expected memory clock speed.

Sometimes it's weird, this is a serious support person who actually knows what they are talking about, and they use the terms dmidecode should have used to avoid this confusion. I also learned that MHz on ddr is equal to 1/2 MT/S, and that MT/S was supposed to always be what showed, but ram companies changed it to MHz because they were afraid people would get confused.

[antikythera]

If you got something useful from this thread then I'm glad. inxi/pinxi being able to show both speed values would be nice if it doesn't screw up what you've already managed to get working.

Configured speed is indeed giving the speed the RAM is set at in UEFI and running at. The modules are using XMP Profile 1 and were in my machine too for 6 years. They never got hot so the heat spreader is maybe more aesthetic than useful on them if you don't overclock them beyond the rated 1600 M/T.

There's actually another dmidecode example here. In this case it's for a laptop where the person installed DDR4-3200 alongside soldered in DDR4-2667 and it's now running at 2400 M/T across both modules.

So inxi/pinxi showing this level of information may come in handy for laptop owners chasing up such issues.

[h2-1]

This is a very valuable fix, I didn't know this stuff, I'd grabbed the configured speed data but never did anything with it, probably because most data samples, my systems included, showed the same values, so I never looked into it.

Fortunately all the complicated logic is in the memory array part, so modifying the per stick report is easy, done already now. 3.2.00 inxi is going to be silly with how much stuff has changed in it.

pinxi now features this enhancement, this sample comes from that dmidecode snippet you posted link to injected into pinxi:

Code: Select all

Memory:
  RAM: total: 31.38 GiB used: 20.7 GiB (66.0%) 
  Array-1: capacity: N/A slots: 2 note: check EC: N/A 
  Device-1: DIMM 0 size: 8 GiB speed: spec: 3200 MT/S actual: 2400 MT/s 
  Device-2: DIMM 0 size: 8 GiB speed: spec: 2667 MT/S actual: 2400 MT/s

The spec: (specified) and actual: show when configured is present, and is different than speed:.

As a further small enhancement, since I was looking at ram data anyway, pinxi now shows, if ddr ram, and speed in MHz, say for the above sample:

Code: Select all

Memory:
  RAM: total: 31.38 GiB used: 20.7 GiB (66.0%) 
  Array-1: capacity: N/A slots: 2 note: check EC: N/A 
  Device-1: DIMM 0 size: 8 GiB speed: spec: 3200 MT/s (1600 MHz) actual: 2400 MT/s (1200 MHz)
  Device-2: DIMM 0 size: 8 GiB speed: spec: 2667 MT/s (1333 MHz) actual: 2400 MT/s (1200 MHz)

This also answers a long standing question I had about what speed: really was, I'd never checked or tested, I'd suggested a few times people do but they never did, but now I see, if for instance ram speed is overclocked, that should show in actual: speed, I think, or underclocked, or if the ram sticks aren't compatible as in the above example, or various other things that can make actual speed at boot be different from specified speed. I'm glad I ran into the supermicro support faq thing, that was hyper clear and explained it perfectly.

[antikythera]

Very nice

[h2-1]

My faith in stick speeds being valid was not justified, so I've further extended it to add note: check for clearly silly values, I'd seen the 1 MT/s glitch in another data set, but found this really good one:

Code: Select all

Memory:
  RAM: total: 31.38 GiB used: 20.65 GiB (65.8%) 
  Array-1: capacity: N/A slots: 4 note: check EC: N/A 
  Device-1: DIMM_A1 size: 8 GiB speed: 1600 MT/s (800 MHz) 
  Device-2: DIMM_A2 size: 8 GiB speed: spec: 1600 MT/s (800 MHz) 
  actual: 61910 MT/s (30955 MHz) note: check 
  Device-3: DIMM_B1 size: 8 GiB speed: 1600 MT/s (800 MHz) 
  Device-4: DIMM_B2 size: 8 GiB speed: spec: 1600 MT/s (800 MHz) 
  actual: 2 MT/s (1 MHz) note: check

which highlights a few of the new features, speed: spec actual: plus nonsensical values test, this person had a real bug in their system as you can see, so it was an excellent sample to expand handling of non valid illogical ram speed data.

So I have to take back what I said about about ram speeds in general being reliable, they only appeared reliable in comparison to the huge mess that is memory array capacity, max module size, etc. So I guess all the ram data is in a sense gibberish, though it's usually fine and accurate. The note: check is used in the array report, and a few other places in inxi where the data is clearly silly.

By the way, for complicated reports on a single feature, -y 1 is very useful

Code: Select all

pinxi -my1
Memory:
  RAM: 
    total: 31.38 GiB
    used: 20.41 GiB (65.1%)
  Array-1: 
    capacity: N/A
    slots: 4
      note: check
    EC: N/A
    Device-1: DIMM_A1
      size: 8 GiB
      speed: 1600 MT/s (800 MHz)
    Device-2: DIMM_A2
      size: 8 GiB
      speed: 
        spec: 1600 MT/s (800 MHz)
        actual: 61910 MT/s (30955 MHz)
          note: check
    Device-3: DIMM_B1
      size: 8 GiB
      speed: 1600 MT/s (800 MHz)
    Device-4: DIMM_B2
      size: 8 GiB
      speed: 
        spec: 1600 MT/s (800 MHz)
        actual: 2 MT/s (1 MHz)
          note: check

This is also helpful if you're not clear on the actual order of the data, what belongs to what that is.

[Pjotr]

Eagerly looking forward to inxi 3.2.

[h2-1]

inxi 3.2.00 went out yesterday, but in general, there's never any need to wait, just run pinxi and have all the latest as soon as it's committed, find any bugs, report them, and help contribute to active development.

pinxi is already ahead of inxi 3.2.00 because I continued the internal refactoring last night, which shouldn't ever impact what end users experience, unless it does due to a mistake in the refactor, but it's stuff I want consistent internally re how certain values are referenced.

I hope people like all the changes in 3.2.00, it's actually the most since 2.9 inxi Perl was debugged and developed. A lot of them will be quite subtle,like correctly showing a zero value instead of N/A, always having values and units handled the same, ideally, many of the changes would just seem to be 'right' and not evoke much notice.

[Pjotr]

inxi 3.2.00 went out yesterday

That was quick! Thanks.

Code: Select all

System:    Kernel: 5.8.0-33-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 4.8.3 
           Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal 
Machine:   Type: Laptop System: LENOVO product: 81VS v: Lenovo IdeaPad Slim 1-14AST-05 serial: <filter> 
           Mobo: LENOVO model: LNVNB161216 v: SDK0R32802 WIN serial: <filter> UEFI: LENOVO v: CWCN19WW date: 05/18/2020 
Battery:   ID-1: BAT0 charge: 27.7 Wh condition: 28.3/35.0 Wh (81%) model: LGC L16L2PB3 status: Discharging 
Memory:    RAM: total: 3.67 GiB used: 1.45 GiB (39.6%) 
           RAM Report: permissions: Unable to run dmidecode. Root privileges required. 
CPU:       Info: Dual Core model: AMD A4-9120e RADEON R3 4 COMPUTE CORES 2C+2G bits: 64 type: MCP arch: Excavator rev: 0 
           L2 cache: 1024 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 5988 
           Speed: 1199 MHz min/max: 1100/1500 MHz boost: enabled Core speeds (MHz): 1: 1199 2: 1199 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] vendor: Lenovo driver: amdgpu 
           v: kernel bus ID: 00:01.0 
           Device-2: Acer type: USB driver: uvcvideo bus ID: 1-1.1:3 
           Display: x11 server: X.Org 1.20.8 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz 
           OpenGL: renderer: AMD STONEY (DRM 3.38.0 5.8.0-33-generic LLVM 10.0.0) v: 4.5 Mesa 20.0.8 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] vendor: Lenovo driver: snd_hda_intel v: kernel bus ID: 00:01.1 
           Device-2: Advanced Micro Devices [AMD] Family 15h Audio vendor: Lenovo driver: snd_hda_intel v: kernel 
           bus ID: 00:09.2 
           Sound Server: ALSA v: k5.8.0-33-generic 
Network:   Device-1: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter vendor: Lenovo driver: ath10k_pci v: kernel 
           port: 1100 bus ID: 02:00.0 
           IF: wlp2s0 state: up mac: <filter> 
           Device-2: Qualcomm Atheros type: USB driver: usb-network bus ID: 1-1.2:4 
Drives:    Local Storage: total: 58.24 GiB used: 17.16 GiB (29.5%) 
           ID-1: /dev/mmcblk0 model: MMC64G size: 58.24 GiB 
Partition: ID-1: / size: 56.58 GiB used: 17.15 GiB (30.3%) fs: ext4 dev: /dev/mmcblk0p2 
           ID-2: /boot/efi size: 511 MiB used: 7.8 MiB (1.5%) fs: vfat dev: /dev/mmcblk0p1 
Swap:      ID-1: swap-1 type: file size: 2 GiB used: 0 KiB (0.0%) file: /swapfile 
Sensors:   System Temperatures: cpu: 32.0 C mobo: 23.5 C gpu: amdgpu temp: 23.0 C 
           Fan Speeds (RPM): N/A 
Repos:     Packages: 2096 
           No active apt repos in: /etc/apt/sources.list 
           No active apt repos in: /etc/apt/sources.list.d/canonical-kernel-team-ppa-focal.list 
           Active apt repos in: /etc/apt/sources.list.d/google-chrome.list 
           1: deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/libreoffice-libreoffice-7-0-focal.list 
           1: deb http://ppa.launchpad.net/libreoffice/libreoffice-7-0/ubuntu focal main
           Active apt repos in: /etc/apt/sources.list.d/microsoft-edge-dev.list 
           1: deb [arch=amd64] http://packages.microsoft.com/repos/edge/ stable main
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http://packages.linuxmint.com ulyssa main upstream import backport #id:linuxmint_main
           2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse
           3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
           4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
           5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
           6: deb http://archive.canonical.com/ubuntu/ focal partner
Info:      Processes: 206 Uptime: 5m Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: Bash v: 5.0.17 inxi: 3.2.00 

[Larry78723]

Already up to 3.2.01.