Performance 4.x vs. 6.x

Martin Cracauer cracauer at
Fri Oct 27 21:34:26 UTC 2006

Wasn't Dragonfly split off to do exactly what some troll here wanted?
Use FreeBSD-4.x as a base for a *BSD.

I would be curious to know whether Dragonfly-current or whatever they
name it fix the performance problems assumed (but not proven).  Or
whether Dragonfly went into difficulties with thread libraries, API
details and new hardware idioticy, too.

Makes you wonder why none of the commerical vendors that did not
change to FreeBSD-6 didn't change to Dragonfly either.

BTW, if you want to see how professional SATA-II is just turn the
write cache on the drive off (as you theoretically must to ensure data
integrety) and try the same on SCSI.  I actually don't understand the
reason but under SCSI you lose 20% or somesuch write performance,
under SATA you lose 90+%.

> > > > I had no time to test it on a life webserver and probably can't do
> > > > it so soon but I tell you that a 10K Raptor is faster then a 15K
> > > > 320Mb SCSI when compiling world or untarring large files. Also NCQ
> > > > is not reserved to SCSI anymore so when you see the price then it is
> > > > becoming a valid option for small servers.

NCQ is not working for many common SATA controller drivers under Linux
or FreeBSD, most notably NForce (unless that changed recently).

The reason why the SCSI disk is so slow is most likely that your
controller has a FreeBSD driver which is giant-locked.

`make world` without "-j" doesn't really stress the harddrive's
seeking, which is where the faster SCSI disk would shine.  For just
linear accesses SCSI is actually very disappointing these days.

Martin Cracauer <cracauer at>
FreeBSD - where you want to go, today.

More information about the freebsd-performance mailing list