Which Is Faster: Debian Linux or FreeBSD?

[phoronix]

Phoronix: Which Is Faster: Debian Linux or FreeBSD?

Back in January, we published the first benchmarks of Debian GNU/kFreeBSD: the spin of Debian that replaces the Linux kernel with the FreeBSD kernel while retaining most of the same GNU user-land and it uses the GNU C library. With those original tests comparing Debian GNU/Linux to Debian GNU/kFreeBSD, the Linux version ended up winning in 18 of the 27 tests. However, over the past six months, the Debian GNU/kFreeBSD port has matured and it's also moved to using the FreeBSD 7.3 kernel by default (compared to 7.2 back in January) and the FreeBSD 8.0 kernel is also emerging as a viable option that can be obtained using Debian's package management system. Today we have updated test numbers looking at the performance of Debian with the FreeBSD kernel using two different notebooks where we ran the latest Debian GNU/kFreeBSD packages with both the FreeBSD 7.3 and 8.0 kernels, Debian GNU/Linux with the Linux 2.6.32 kernel, and then finally we tested the pure FreeBSD 7.3 and FreeBSD 8.0 operating systems.

http://www.phoronix.com/vr.php?view=15137

[kraftman]

@
Trash, are you satisfied? I guess you're rather disappointed. ;> Very nice comparison, good to see numbers using exact GCC version. Thanks.

[mav@]

It would be nice if in future I/O-related FreeBSD tests you've compared new CAM-based ATA infrastructure. It first appeared in FreeBSD 8.0 and becoming mature enough now in 8.1. Due to added NCQ support, there could be up to double performance difference in random I/O.

All that needed to use it is: enable AHCI SATA mode in BIOS, load ahci, siis and mvs kernel modules via /boot/loader.conf and update device names in /etc/fstab from adX to respective adaY (usually ada0). Ask me if you have any questions.

Thanks.

[FarJumper]

With the "major performance penalty" of John The Ripper: it looks more like the data preparation or visualization bug than real result (the graph bars have barely visible negative values).

[Michael]

With the "major performance penalty" of John The Ripper: it looks more like the data preparation or visualization bug than real result (the graph bars have barely visible negative values).

It has valid results, but they are too small.

[Michael]

It would be nice if in future I/O-related FreeBSD tests you've compared new CAM-based ATA infrastructure. It first appeared in FreeBSD 8.0 and becoming mature enough now in 8.1. Due to added NCQ support, there could be up to double performance difference in random I/O.

All that needed to use it is: enable AHCI SATA mode in BIOS, load ahci, siis and mvs kernel modules via /boot/loader.conf and update device names in /etc/fstab from adX to respective adaY (usually ada0). Ask me if you have any questions.

Thanks.

CAM-ATA results are already planned for tomorrow.

[DragonSA]

CAM-ATA results are already planned for tomorrow.

Could you also give gsched a try (its in 8.1 AFAIK)? It is not specific to CAM-ATA. Try:

# gsched insert ada0

to get the IO scheduler to work on ada0. See man 8 gsched for details.

Thanks for the article.

[FarJumper]

It has valid results, but they are too small.

and negative? Hmm. Ok then, I thought that was integer overflow or something like this.

[Michael]

and negative? Hmm. Ok then, I thought that was integer overflow or something like this.

The results aren't negative, but considering how small they were in comparison, it may just be a rounding error in pts_Graph when displaying them.

[locovaca]

The results aren't negative, but considering how small they were in comparison, it may just be a rounding error in pts_Graph when displaying them.

You're not rendering those results on an old Pentium 60 I hope...