From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 9 09:13:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FB03FDD for ; Sun, 9 Dec 2012 09:13:08 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id CD2D78FC1B for ; Sun, 9 Dec 2012 09:13:07 +0000 (UTC) Received: (qmail 19038 invoked by uid 0); 9 Dec 2012 09:13:07 -0000 Received: from 67.206.183.93 by rms-us016 with HTTP Content-Type: text/plain; charset="utf-8" Date: Sun, 09 Dec 2012 04:13:03 -0500 From: "Dieter BSD" Message-ID: <20121209091305.238100@gmx.com> MIME-Version: 1.0 Subject: Re: FreeBSD for serious performance? To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: djO2cGY83zOlNR3dAHAh1Cx+IGRvb8CF X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 09:13:08 -0000 Ronald writes: > the last Alpha to be produced was shipped way back in 2004... eight years > ago... with a top speed of 1.3 GHz.  I now have a cheap little media player > thingy sitting on my desk, and _each_ of its two cores runs faster than that. > In short, Alphas hardly constitute high-end hardware in this day and age. So clock rate is the only thing that matters in your world? In my world, high-end means high quality. It doesn't necessarily mean fast, or recent. Warren writes: > A. Use ahci(4): >    "The ada device driver takes full advantage of NCQ, when supported." Achi and siis support NCQ, but neither attach to the nforce4-ultra, which does support NCQ. I knew that NCQ would be required for acceptable performance and gave up other useful features to get it. Silly me, assuming that the performance orientated version of BSD would support such an essential performance feature on a very popular chipset. Linux has had NCQ on nforce4 since Oct 2006. Without NCQ, writes are slower than USB2, even with purely sequential writes (to the raw drive, no filesystem, so no seeking other then to the next track): device    r/s    w/s     kr/s     kw/s wait  svc_t  %b  controller   ad6 1726.5    0.0 217535.0      0.0    1    0.6  96  ata3-master   ad6    0.0  109.5      0.0  13794.8    1    9.1 100  ata3-master   da0  249.9    0.0  15741.4      0.0    1    6.0 100  umass-sim0 ad6 is ST3000DM001-9YN166 on nforce4-ultra chipset da0 is ST3000DM001-9YN166 USB3 disk on a USB2 port (from nforce) Sorry no write performance data for da0, I yanked the USB-to-SATA bridge off after doing some testing. The bridges they're currently shipping are slightly less crappy than they used to be, but they are still crap. > B. Use GPT, which does not have the CHS baggage.  It is easier and more >    versatile.  My systems with GPT disks don't complain about track >    alignment.  Or maybe that's ahci(4)'s doing. I never found a way to boot from different partitions, much less different disks with GPT. So I use NetBSD's MBR for disks I want to boot from. FreeBSD's and NetBSD's fdisk are both broken. Building MBRs by hand is such fun. Non-boot disks with multiple partitions use GPT. Big data disks get newfs-ed directly, no partitioning. The useless CHS baggage hangs around for decades, but useful hardware loses all support 5 nanoseconds after the last machine is sold. Other useful hardware waits years hoping to get support.