Subject: Re: a very slow 2.2Ghz amd64
To: None <firstname.lastname@example.org>
From: George Georgalis <email@example.com>
Date: 10/05/2007 10:15:19
On Thu, Oct 04, 2007 at 11:06:09PM +0200, Adam Hamsik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Oct 4, 2007, at 8:56 PM, George Georgalis wrote:
>> On Thu, Oct 04, 2007 at 05:13:53PM +0000, Christos Zoulas wrote:
>>> In article <20071004154314.GB21817@run.galis.org>,
>>> George Georgalis <firstname.lastname@example.org> wrote:
>>>> I've got an odd problem, a 2.2Ghz amd64 is compiling etc about 1/4
>>>> the speed I'd have expected. eg autoconf tests are taking between
>>>> 1 and 2 seconds each. all compile processes are pretty slow.
>>>> The dmesg is below, there are a lot of not configured lines,
>>>> is one of them causing the slowdown? Is there something I can
>>>> disable in bios? (BTW this is a Sun X2100)
>>>> // George
>>> run 'systat vm' and see if any of the interrupt numbers is growing
>>> too fast.
>> The only thing that seems odd is sys time taking 99% of cpu when
>> starting spamd (spamassassin) from pkgsrc, which took nearly a
>> minute to start...
>> 99.1% Sy 0.9% Us 0.0% Ni 0.0% In 0.0% Id pages
>> | | | | | | | | | | |
>> could this have something to do with acpi speedstep (this is rc1)?
>> how can I check the actual clock rate the system is running at?
> sysctl machdep.speedstep :) or something similar.
root@rock:/root sysctl -a | grep speed
hw.fwmem.speed = 2
hw.sbp.max_speed = -1
root@rock:/root sysctl -a | grep mach
hw.machine = amd64
hw.machine_arch = x86_64
machdep.booted_kernel = netbsd
machdep.diskinfo: 80:156301488(1023/255/63),2 81:156301488(1023/255/63),2 wd0:80,81 wd1:80,81
machdep.sleep_state = 0
machdep.powernow.frequency.target = 2200
machdep.powernow.frequency.current = 2200
machdep.powernow.frequency.available = 1000 1800 2000 2200
seems to be at full speed, not much google on
hw.sbp.max_speed or hw.sbp.
>> viaide0 at pci0 dev 6 function 0
>> viaide0: NVIDIA nForce4 IDE Controller (rev. 0xf2)
>> viaide0: bus-master DMA support present
>> viaide0: primary channel configured to compatibility mode
>> viaide0: primary channel interrupting at ioapic0 pin 14 (irq 14)
>> atabus0 at viaide0 channel 0
>> viaide0: secondary channel configured to compatibility mode
>> viaide0: secondary channel interrupting at ioapic0 pin 15 (irq 15)
>> wd0 at atabus2 drive 0: <ST380013AS>
>> wd0: drive supports 16-sector PIO transfers, LBA48 addressing
>> wd0: 76319 MB, 155061 cyl, 16 head, 63 sec, 512 bytes/sect x 156301488
>> wd0: 32-bit data port
>> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
>> wd0(viaide1:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using
>> I thought since I had Ultra/133, I was okay. Is "compatibility
>> mode" my problem? Do I need sata controler to fix?
> I don't think so, because non io operations took to much time ,too. If I
> understand you correctly.
well it seems sync is queueing a lot of stuff and
tieing up the cpu getting it to the drive.
George Georgalis, information system scientist <IXOYE><