Not happy on Centrino

[delta_t]

I tried running the NFSNET client on a Centrino based laptop. It appeared to be running funny and kept popping up an error about knowing nothing about it's cache and so was making a guess. These processors have 1024K of L2 as opposed to the 512K of the regular P4s.

Has anyone else had this problem?

[Wacky]

It's quite possible that your newer CPU chip is not recognized. (Did Intel change the format of the cpuid data? They do that occasionally.)

Please send your previous message to nfsnet-developers@nfsnet.org and indicate that one of the Windows guys needs to help you extract the cpuid info so that we can update the code.

In the interim, keep sieving. The default cache size isn't optimal, but it only costs a few percent.

[delta_t]

I'm pretty sure they changed something with this CPU. This machine has been crunching for GIMPS and if you look at the below thread you will see that a Centrino processor runs slower than expected for some reason.

http://www.mersenneforum.org/showthr...=&threadid=500

[xilman]

Originally posted by delta_t
I tried running the NFSNET client on a Centrino based laptop. It appeared to be running funny and kept popping up an error about knowing nothing about it's cache and so was making a guess. These processors have 1024K of L2 as opposed to the 512K of the regular P4s.

Has anyone else had this problem?

That exact problem hasn't been reported before, but I did have to modify the cache-detection code for a Crusoe system that was reporting something similar.

As Wacky said, please mail the exact message that the linesiever is producing (the one that says unknown cpu type) and I'll see if I can find out from Intel how to interpret what the cpu is trying to tell us. In the meantime, please ignore the message. It is harmless and the default cache sizes in use are only very slightly sub-optimal.

Unfortunately, keeping track of all the different processors out there is a never ending task.


Paul

[delta_t]

Here's the CPUID information. Is there anything else that is needed?

CPU-Z version 1.20a
CPUID Output

Function eax ebx ecx edx
00000000 00000002 756e6547 6c65746e 49656e69
00000001 00000695 00000816 00000180 a7e9fbbf
00000002 02b3b001 00000000 00000000 2c043087
80000000 80000004 00000000 00000000 00000000
80000001 00000000 00000000 00000000 00000000
80000002 20202020 20202020 65746e49 2952286c
80000003 6e655020 6d756974 20295228 7270204d
80000004 7365636f 20726f73 30303031 007a484d

MSR registers
2A 00000000 42880000
17 00140000 D0008513
11E 00000000 0034072B
8B 00000005 00000000

[delta_t]

Here's some CPU-Z screenshots.

[delta_t]

Here's another CPU-Z shot

[xilman]

Originally posted by delta_t
I'm pretty sure they changed something with this CPU. This machine has been crunching for GIMPS and if you look at the below thread you will see that a Centrino processor runs slower than expected for some reason.

http://www.mersenneforum.org/showthr...=&threadid=500

Hi Delta_t.

I PMed you about this problem and a possible fix to it but haven't yet had a reply, so perhaps the mechanism broke down somehow. I don't have an email address for you and so can't contact you directly other than by PM.


Please get in contact, either with me or Richard (aka Wacky) at paul@nfsnet.org or richard@nfsnet.org. We want to ship the new code more generally but need to verify that it works on a Centrino system (or, at the very least, is harmless there!).

Paul

P.S. Anyone else running the nfsnetclient on a Centrino is also welcome to try testing our code.