Urban Legends of FreeBSD

FreeBSD Project menu
Dual Processors

The "-j4" speed up on uniprocessor's myth

Usually urban legends are facts widely held to be true but in reality aren't verifyable. The first one I have dealt with is the urban legend of the "­j4" option on the long running buildworld's. I have "crystal" that is a P-200 Pentium that requires 5:25 to cvsup and rebuild everything and "topaz" that is a Athlon 900 that requires less than a hour. The buildworld times for topaz are documented in the table below. This option produced buildworld's that typically ran several % to 10% or more slower. The only way to document it is to include the runs in a table. The primary purpose of the tests was to document the effect of using Softupdates on a file system. The times for the buildworlds fell out of various configurations. All cases were run specifying "-pipe" in /etc/make.conf. The most noticeable affect was the time for no "-j" parameter and softupdates. It was almost 20 minutes faster than over specifying the "-j" parameter and not using softupdates.

It wasn't until I saw the really fast results that I really thought I could put a reasonably priced system together that would do a buildworld in 30 minutes. An elapsed time of 30 minutes is what I think someone responding to a "stable is broken" message in FreeBSD-Stable needs in order to verify if it is broken or we have a user error of some sort. A time much longer than that and we have people placing blame on a lack of responsiveness by the FreeBSD community. I think with a build time of 30 minutes, you can see the message, cvsup and do your builds, and reply. The critical time for the entire response process is an hour in my mind.

The notation 2-HD indicates that /usr/obj and /usr/src are on different HD's. Each HD used in the active part of the build is an ATA-100 on a Promise UDMA-66 I/O card. The 3rd HD is attached to the KT7 IDE controller but downgraded to PIO-4 because of UDMA errors when using FreeBSD. The build process has a tee to capture the build log and the 3-HD has the build log being saved on a 3rd HD. On the 2000+ system, all of the HDs at attached to individual ATA-133 controllers.

The hardware is a Abit KT7 mb with an AMD Athlon Thunderbird 900 Mhz. The system has 256 MB of memory. The 2000+ XP cpu is in a Gigabyte GA-7VAXP mb and has 256MB of 266MHz DDR memory. The 23 minute elapsed time has been seen since the system was upgraded to the 2000+ XP cpu.

Back to Top

Dual-processor Build times

The hardware for this test is an Abit VP6 with two P-III 866eb's on it. The system has 2-128MB SDRAM PC-133 memory sticks and a single Maxtor 30 GB ATA100 HD. The Maxtor is on IDE1, which is a UDMA-66 controller. The table is in the order of the tests. The VP6 has an HPT-370 Raid controller and that will be used in the tests at some point.

The first thing that I noticed was that using a dual processor system wasn't faster. In fact, it was slower than the single processor system with multiple HD's being used for intermediate compiler output. The interesting test, which can't be run right now, will be 2-30 GB drives that are striped using the raid controller. That was always blazingly fast on Cray X/MP benchmarks that I ran a long time ago. The raid-0 runs were fast but they did not produce the results that 3 drives on 3 controllers produced.

The FreeBSD 4.3 buildworlds were all made on a system with 3-30 GB ATA-100 Maxtor's on individual controllers. The build script logs to one HD, reads the source from a different HD and write an /usr/obj on the 3rd HD. All of the drives have softupdates turned on. The system was built for one reason and that was to do a buildworld as fast as I could for a reasonable price. The final times, which were around 29 minutes, were made after the write cache was turned back on. The effect was dramatic. I tried -j10 but -j8 was a little bit faster. Unless you sit on the computer and wait for it to finish, you will not see it. I think that I would need 2 or 3 Ultra-160 scsi HD's to improve on the current time.

Back to Top