mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Hardware (https://www.mersenneforum.org/forumdisplay.php?f=9)
-   -   Phenom X4 system not very fast (https://www.mersenneforum.org/showthread.php?t=10626)

fivemack 2008-09-09 15:42

Phenom X4 system not very fast
 
I have built a Phenom X4 2.5GHz system on an Asus M3A78EMH HDMI motherboard, with 8GB of DDR2/6400 memory, running ubuntu-8.04 from a USB stick.

Running four copies of gnfs-lasieve4I15e on it, sieving 5^421-1, I'm getting times around 0.9 - 1.1 seconds per relation - an Opteron 2.4GHz next door gets 0.6 seconds per relation.

/proc/cpuinfo says that all the CPUs are running at the full 2.5GHz.

akruppa 2008-09-09 15:59

Is that a Phenom with the TLB bug? If the BIOS or the OS switched off the TLB, I would not be surprised that memory intensive applications like sieving take a huge hit.

Alex

ET_ 2008-09-09 16:05

[QUOTE=akruppa;141558]Is that a Phenom with the TLB bug? If the BIOS or the OS switched off the TLB, I would not be surprised that memory intensive applications like sieving take a huge hit.

Alex[/QUOTE]

The X4 version should be bug-free, and coded as xx50 instead of xx00.
I'd check the BIOS: some newer BIOS have an automated phenom-bug correction that lessen performances up to 20%.

Try also to recompile the sources using AMD switches.

Luigi

fivemack 2008-09-10 09:16

It looks to me like either very nasty memory contention or some kind of thermal problem; when I run only one copy of the siever I get decent performance (0.48s per relation).

I'm trying to distinguish the two explanations, but I'm having trouble driving oprofile:

[code]
sudo opcontrol -e DATA_CACHE_REFILLS_FROM_SYSTEM:1000
nfsslave3@pig:/sys/devices/system$ sudo opcontrol --status
Daemon running: pid 7382
Event 0: DATA_CACHE_REFILLS_FROM_SYSTEM:1000:31:1:1
...
nfsslave3@pig:/sys/devices/system$ sudo opreport | head
CPU: AMD64 family10, speed 2500.99 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
[/code]

IE I have told it to watch data-cache refills, it says that it's watching data-cache refills, but the report indicates that it's counting ticks.

And I have an AMD document saying 'temperature is accessible through F3xA4' but not defining what this means. So presently I am at about as low a level as I'm comfortable with, and stalled.

fivemack 2008-09-10 11:32

OK, at least part of this is that I hadn't shut down and purged oprofile since the last use; for further reference,

[code]
sudo opcontrol --shutdown
sudo opcontrol --reset
sudo opcontrol --no-vmlinux -e DATA_CACHE_REFILLS_FROM_SYSTEM:1000 sudo opcontrol --start
sudo opreport | head
opannotate --assembly gnfs-lasieve4I15e
[/code]
does give a count of data-cache refills from system.

Across the quad, I'm getting 18.9 million of those each second, which seems like a fair number. On a box with an Athlon64 x2 of 2.2GHz I get 3.7 million per second running two copies of the job, so the phenom's cache is being much more missed.

fivemack 2008-09-11 13:52

I think it's probably heat. I have a process which uses no memory (it just adds up N*N for N=0..10^11); it runs in 80 seconds when I run one copy of it and, when I run four, each takes 150 seconds.

What tool do I need under Linux to tell if the Phenom is thermally throttling?

KriZp 2008-09-11 14:08

perhaps cat /proc/cpuinfo would work? I don't know if it would update after a throttle, or if the information is just generated at boot.

fivemack 2008-09-11 14:14

[QUOTE=KriZp;141962]perhaps cat /proc/cpuinfo would work? I don't know if it would update after a throttle, or if the information is just generated at boot.[/QUOTE]

The figure doesn't change while I'm running the heat-the-CPU job.

mdettweiler 2008-09-11 15:13

[quote=fivemack;141960]I think it's probably heat. I have a process which uses no memory (it just adds up N*N for N=0..10^11); it runs in 80 seconds when I run one copy of it and, when I run four, each takes 150 seconds.

What tool do I need under Linux to tell if the Phenom is thermally throttling?[/quote]
Assuming you're on a GNOME-based distribution, you can add little widgets called "CPU Frequency Scaling Monitors" to your taskbars--just right-click one of the taskbars, click Add to Panel, and drag four copies of the CPU Frequency Scaling Monitor to one of the taskbars. Then right-click on one, click Properties, and set it to CPU 0; the next one, set it to CPU 1; etc. :smile:

jasonp 2008-09-11 15:20

[QUOTE=fivemack;141960]I think it's probably heat. I have a process which uses no memory (it just adds up N*N for N=0..10^11); it runs in 80 seconds when I run one copy of it and, when I run four, each takes 150 seconds.

What tool do I need under Linux to tell if the Phenom is thermally throttling?[/QUOTE]
If the motherbopard has temp and fan speed control chips that allow it, the lmsensors package lets you read them. I also use a tiny GUI that reads the output files in /proc and displays things like temp, fan speed and voltages.

Note that lmsensors (as of 2004) was very painful to set up; if an online review of my motherboard hadn't provided a config file to use, I don't think I could have figured it out.

fivemack 2008-09-11 15:59

lmsensors seems to be quite well-packaged under debian; at least, I can just run 'sensors' and get a long list of voltages and temperatures. As the full-CPU job runs, the motherboard temperature goes from +37 to +47, and the claimed CPU temperature is steady at +37. 30s after the job finishes the temperature is back to +43.

In principal the phenom has temperature sensors on the CPU itself, but the documentation on the CPU (what I have is the 'BIOS Writer's Guide', which is insanely technical) doesn't make it at all clear how one reads the sensors, and the version of lmsensors that I have says

[code]
AMD K10 thermal sensors... Success!
(driver `to-be-written')
[/code]

which isn't all that helpful.


All times are UTC. The time now is 21:04.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.