Date: Mon, 3 May 2010 15:39:48 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Bryce Edwards <bryce@bryce.net> Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE performance issues on Supermicro Core i7 Message-ID: <20100503223948.GA9134@icarus.home.lan> In-Reply-To: <p2j34da63c51005021940ja279a71cx8d59a2275354699f@mail.gmail.com> References: <m2j34da63c51005010810r21e40b23m76d9beccd5daaf8c@mail.gmail.com> <p2j34da63c51005021940ja279a71cx8d59a2275354699f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 02, 2010 at 09:40:13PM -0500, Bryce Edwards wrote: > I've got a new Supermicro X58 system with an Intel Core i7 930 with 6 > GB ram that is not performing nearly as fast as it should in many ways > (compiling, network transfers). To give an example, it has been > building the gcc44 port for about 10 hours now and at the same time > rsync'ing from a Linux box on the same Gigabit network is only getting > throughput of between 10-25 MB/sec. When I did a buildkernel for > 8-STABLE, it took 17 hours! My investigations have shown inhibited > performance on compute, network and storage activities. > ... > Thanks in advance for any ideas. Here's some system info and stats: > ... > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 Are you using powerd(8) on this machine? Does the behaviour change if you shut it off? > FreeBSD tahiti.bryce.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 28 10:53:37 CDT 2010 > ... > bryce@tahiti[~]>cat /etc/sysctl.conf > kern.timecounter.hardware=HPET Can you explain why you're overriding the OSes choice here? According to other parts of your dmesg, ACPI-fast or ACPI-safe is a better choice. The output from "sysctl -a kern.timecounter" would list off all your timecounter choices. Why I ask: I tend to leave HPET disabled on Supermicro systems since ACPI-fast/safe have always been reliable for me on such. On every Supermicro system I've used, HPET has defaulted to disabled. > Dmesg output: > ... > ACPI Warning: Incorrect checksum in table [OEMB] - 0x7B, should be 0x74 (20100331/tbutils-354) I don't know if this could possibly explain the problem or not; freebsd-acpi might have some ideas. > pci0: <base peripheral, interrupt controller> at device 20.0 (no driver attached) > pci0: <base peripheral, interrupt controller> at device 20.1 (no driver attached) > pci0: <base peripheral, interrupt controller> at device 20.2 (no driver attached) > pci0: <base peripheral, interrupt controller> at device 20.3 (no driver attached) > pci0: <base peripheral> at device 22.0 (no driver attached) > pci0: <base peripheral> at device 22.1 (no driver attached) > pci0: <base peripheral> at device 22.2 (no driver attached) > pci0: <base peripheral> at device 22.3 (no driver attached) > pci0: <base peripheral> at device 22.4 (no driver attached) > pci0: <base peripheral> at device 22.5 (no driver attached) > pci0: <base peripheral> at device 22.6 (no driver attached) > pci0: <base peripheral> at device 22.7 (no driver attached) I have no idea what to make of this, but I see "interrupt controller" and I get a bit concerned. The reason is, ahci0 on your system ties in to pci0: > ahci0: <Intel ICH10 AHCI SATA controller> port 0xa480-0xa487,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa81f mem 0xf9fda000-0xf9fda7ff irq 19 at device 31.2 on pci0 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100503223948.GA9134>