strangely poor speed on xp2000+ (palomino)? Your speeds, please

[mklasson]

My athlon xp2000+ (palomino), 133MHz FSB&mem seem to get strangely low speed rates, around 130K/sec. This is in contrast to my other xp1800+ (t-bred) overclocked to 1640 MHz (slightly lower than xp2000+) and 194MHz memory which gets about 190K/sec, and my old athlon 750Mhz at about 80K/sec.

I'm puzzled as to why the xp2000+ would only get about 60% higher rates than the athlon 750. In GIMPS, the xp2000+ is roughly 3 times faster than the 750.

Is there perhaps a problem with the cpu recognition? I can imagine disabling SSE and/or whatnot support would be Bad for speed.

Are there any benchmark numbers around?

Do any of you have similar systems? What speeds do you get?

[Mystwalker]

I can only confirm the speed of the Athlon 750.

When you've unlocked your 1800+, just change the settings so it has approx. the same speed, but FSB & mem-clock @ 133 MHz. Then we'll see what impact they have on overall performance.

Question:
Did you upgrade a PC with the 2000+ without reinstalling the OS and is it WinNT, 2k or XP?
That could lead to SSE support not showing...

[shauge]

I do also have a strange case of low speed rate. I run dual AMD MP1600 at 1400MHz w/fsb@100MHz at work and currently get around 2*120K cEMs/s. Then I aquired a dual MP2400 system running at 2000MHz with fsb@133MHz. That system produces only around 2*110K cEMs/s. They have both run together for a week and all this time the MP2400 system has had a 10% lower rate.

Both systems run a clean installed winXP. All latest chipset drivers installed. I have examinded settings and found nothing wrong. I have also run a benchmark program, PCMark2002, to compare the two systems and the MP2400 system strongly outperformed the MP1600 both in CPU tests and memory tests. The MP1600 system has a RAID, but I didn't think that SoB was HD intensive alt all.

If the SoB client SW has problem detecting that the new AMD processors supports Extented 3DNow or SSE intructions, it could explain the above observations. It could also be a dual processor issue, I have not examined that theory yet.

[mklasson]

WOW!

I read in an old thread on this forum that upgrading VIA's 4in1 drivers was a good idea. I couldn't concur more.

Now my xp2000+ churns out 170K/sec, up from 135K/sec. That's a 25% increase. Yes, wow...

I really, really suggest everyone running a VIA chipset upgrade their 4in1 drivers as well.

I'll be posting this in a new thread as well to make sure more people see it...

Download the drivers:
http://www.viaarena.com/?PageID=2

[shauge]

I examined the issue with my 2 duals today. When running in single cpu mode or only one client in dual mode, the rate is about 170K for the MP2400 machine and 140K for the MP1600. When running two clients in dual mode, the rate is 110K for the MP2400 and 120K for the MP1600. The MP2400 has 760MPX chipset with latest drivers, the MP1600 has 760MP chipset and std XP drivers.

A funny thing is that when the clients are restarted after running PCMark2002, the rate increases to 175K (single) and 130K (dual) for the MP2400.

I have no explaination for this. It only tells me that something is not at its optimum.

[Mystwalker]

Did you set CPU affinity?

[shauge]

I don't usually do that. I haved tried it and found it not to implove things. It looks like both processors always are fully used.

However, I will try it some more.

Thanks!

[Mystwalker]

Yes, they are both fully used, but as in this situation we have 2 clients, the software can't handle CPU affinity itself. So the scheduler hands a SB process to the CPU that's currently "free" - but this needn't be the one that client ran on the last time. That means that the context has to be restored - whereas it would likely be still in the cache when using affinity.
So the CPUs waste a certain amount of computing time to reload context data.

[shauge]

I see the point. The speed difference I observe can be explained by the operating system getting into a state where it switches the two clients a lot between the two CPUs.

Thanks again.

[TheOtherPhil]

The way the task scheduler works would mean that switching the clients between CPU's wouldn't happen when they are both running. Setting affinity is not necessary and could result in worse performance. I run 5 dual AMD systems and have never set affinity for anything.

[shauge]

I have set the affinity the last days without seeing a significant increase in the rate.

I can however imagine a situation where both SB clients for a short period are switched out of executing mode. When a processor again is ready to run a SB client, is it then guarrantied that it will not switch processors?
If it can switch and if that take extra CPU cycles, then those cycles are lost from the SB project since that project tries to use all free cycles.