Anyone have any ideas why my
"AuthenticAMD AMD Athlon(tm) 64 X2 Dual Core Processor 4200+..."
has turned into just "AuthenticAMD" with no description.
System= Linux 2.6.20, Boinc 5.8.17. ClientState.xml is correct, but Einstein isn't; therefore Boinc Stats is wrong. It's a little hard to deal with as I have 2 AMD machines, and have to do a double-take to tell them apart.
Copyright © 2024 Einstein@Home. All rights reserved.
Host Name lost CPU Type
)
Linux 5.8.17 is not reporting the full processor information.
Look at the list of top hosts and there are a bunch just being reported as 'AuthenticAMD' or 'GenunineIntel' without all the other capabilities.
BOINCin since 10-Apr-2004 (2.28) ~~~ Join team USA
Yep, I noticed the same under
)
Yep, I noticed the same under Linux, whereas Windows seems to report lots of detail about the CPU.
That bug is apparently
)
That bug is apparently triggered by a 254 Char limitation on the Client (for me, Linux 5.8.11, 5.8.15 and 5.8.17 are affected, triggered by length of CPU caps listing in the client_state.xml)
Ron acknowledged it and fixed it on a changelog as of 12 Mar, 5.8.17 unfortunately is dated 7 Mar.
My best guess is, that the Fix is found in 5.8.18, whenever it is released (maybe someone is willing to grab & compile a post-12 Mar Nightly Build tarball to check that out)
Since the CPU Caps are useful for BOINC itself but clutter up the Listings, from what I read they have also been moved into a separate Field in the client_state.xml and will not make it into the Computer Listings anymore in future.
RE: Linux 5.8.17 is not
)
This is what I get on BOINC 5.8.17, SuSE Linux 10.1:
GenuineIntel
Pentium II (Deschutes) [Family 6 Model 5 Stepping 1][fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr]
Tullio
> From what I have seen on a
)
> From what I have seen on a few other forums it is due to a "glibc" compile problem. The latest version has been compiled against 'glibc 2.4' when a lot of Linux distributions have 'glibc 2.3' hence don't show what they should.
It is mainly for Homongenous Redundancy (grouping computers that give same or similar results for the workunits processed), so the projects don't get heaps of results that aren't the same and so 'invalidate' against each other when in fact they are correct for their cpu/OS combination.
All seems ok for Windows but not Linux even up to 5.8.17 version, still waiting for the fix. Suse 10.1 has glibc 2.4 so that is why it reports correctly.
I use Fedora 3 and 6 and neither report the stepping and model information yet.
My Fedora Core 6 has the Kernel updated to 2.6.20, same as 'ohiomike', but still uses 'glibc 2.3'.