I know, not a SETI thing, but I figured someone might know. I have several AMD systems, and only one of them exhibits this, but the processor identification is missing a string now.

In 5.4.11:
AMD Athlon(tm) XP 3000+

In 5.8.15 (and .16):
AMD Athlon(tm) XP [x86 Family 6 Model 10 Stepping 0]

The other two show like this:
AMD Athlon(tm) 64 Processor 3000+ [x86 Family 15 Model 47 Stepping 2]
AMD Sempron(tm) Processor 3000+ [x86 Family 15 Model 44 Stepping 2]

All 3 systems are on Windows XP, using 5.8.16 now. Any idea why it's suddenly unable to figure out that it's a 3000+ and why there's no "Processor" string? It's not impacting anything, just bugs me is all hehe.

---

I know, not a SETI thing, but I figured someone might know. I have several AMD systems, and only one of them exhibits this, but the processor identification is missing a string now.

In 5.4.11:
AMD Athlon(tm) XP 3000+

In 5.8.15 (and .16):
AMD Athlon(tm) XP [x86 Family 6 Model 10 Stepping 0]

The other two show like this:
AMD Athlon(tm) 64 Processor 3000+ [x86 Family 15 Model 47 Stepping 2]
AMD Sempron(tm) Processor 3000+ [x86 Family 15 Model 44 Stepping 2]

All 3 systems are on Windows XP, using 5.8.16 now. Any idea why it's suddenly unable to figure out that it's a 3000+ and why there's no "Processor" string? It's not impacting anything, just bugs me is all hehe.

I personally find the new method annoying.

---

I personally find the new method annoying.

That's okay, it's not for you anyway. It's there to help project to use tools like "Homogenous Redundancy". Just ignore it.

Edit: In case folks want to know, different OS and/or CPU combinations can come up with different, but equally valid results. In order to compare results for validation, you need to be able to group similar OS and/or CPU combinations. So these new CPU ID tags help projects do that. More can be read here:

Homogeneous Redundancy

---

Dublin, California
Team: SETI.USA

I personally find the new method annoying.

That's okay, it's not for you anyway. It's there to help project to use tools like "Homogenous Redundancy". Just ignore it.

What if I don't like being blended with some of you? ;-)

Let me guess... I'll be assimilated sooner or later...

What if I don't like being blended with some of you? ;-)

That depends on whether you jump in with the other gremlins in the liquidiser!

Let me guess... I'll be assimilated sooner or later...

Keep off the GM foods!!


Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

I personally find the new method annoying.

That's okay, it's not for you anyway. It's there to help project to use tools like "Homogenous Redundancy". Just ignore it.

Edit: In case folks want to know, different OS and/or CPU combinations can come up with different, but equally valid results. In order to compare results for validation, you need to be able to group similar OS and/or CPU combinations. So these new CPU ID tags help projects do that. More can be read here:

Homogeneous Redundancy

I read the article and it makes sense to a certain point. All processors whether AMD or Intel should came back with the same result. In the most extreme simple example, shouldn't 1 + 1 equal 2 on all chips? Now if you aware of some bugs inisde certain chips this could be a way to help exclude them but is that the case?

---

... All processors whether AMD or Intel should came back with the same result. In the most extreme simple example, shouldn't 1 + 1 equal 2 on all chips? Now if you aware of some bugs inisde certain chips this could be a way to help exclude them but is that the case?

Not quite...

For integer arithmetic and logical operations, you will indeed get the exact same results for the same number of bits computed. However, there are different standards for how to round the fractional part of floating point numbers. Different processors also have different hardware that might maintain a different number of "guard bits" for reducing rounding errors. Further, there are many different ways for libraries to calculate scientific functions and for differing speeds and accuracies.

Just to add another small bit of variability, compilers can very slightly change the floating point calculations done by how they optimise the FPU instructions.

If the accuracy of the floating point used is far greater than that needed for the computation being done, then all is fine. The number of bits of precision available must always be considered to avoid losing all your number to rounding errors!


I'll agree that a good solid implementation should be just as robust and "give the same numbers" regardless of the hardware used. The question for s@h (and all Boinc projects) is whether the extra effort is worthwhile to ensure that. Part of that question is also whether the checks for that are made in the science application or on the server. Boinc offers an easy route and an easy check 'server-side' with the homogeneous checks if they are required.


In summary: The question is in how fine a measurement you make to decide what results are the same and what are not the same. Do you measure to within a km, a mm, or a femto-metre?... And does it really matter for the results?

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)