🚀 go-pugleaf

In article <danpop.809098380@rscernix>, Dan Pop <Dan.Pop@mail.cern.ch> wrote:
>
>Try to run UnixWare and Solaris on the 486DX2-66 with 16M RAM and compare
>the performance with the one offered by Linux.  If you have a Pentium-133
>with 32M RAM, you can run pretty much anything, including big resource
>hogs, like NT or NeXTSTEP.  But most people don't, which explains Linux'
>popularity.
>
In the same fashion, I just ran a bunch of performance measuring benchmarks
on FreeBSD V2.1-stable and Linux 1.3.20 and found that in memory limited
conditions on a 20MB machine, FreeBSD wins out.  FreeBSD is signficantly
higher performance in general (except for the meta-data update/async
write filesystem thing) than Linux.  FreeBSD wins out (on an IDE based
machine) on IOZONE, memory faulting (and paging), and bonnie. (Excepting
the random I/O test.)  Actually on the same machine, FreeBSD compiled
lmbench faster than Linux also.  Networking UDP performance is about the
same between the two OSes, but TCP is at least 50% faster on FreeBSD
than Linux.  The performance results can be found on the freebsd-hackers
mailing list.  The numbers were uncooked and not even filtered in any way.

The suprising thing is how slow access to the buffer cache is using the
lmbench benchmarks, and how slow mmap files were on Linux.  It appears that
when the filesystem actually has to perform a read of the disk, the performance
drops further.  A case in point, actual read perf through the filesystem
using lmbench from disk on FreeBSD using MULTI-BLOCK I/O was approx
2.2-2.3MBytes/sec, while on Linux was about 1.6-1.8MBytes/sec -- a big
difference.  On cached reads, IOZONE measures about 12-13MByte/sec on
FreeBSD V2.1-stable, about 16-17MByte/sec on some experimental code
that might go into FreeBSD V2.2-current and only 8MB/sec or so on Linux!!!

During paging on the bw_mem_cp of two 8MByte segments, Linux thrashed taking
about 10x longer to run the benchmark than FreeBSD (same machine, and excess
of swap space.)  It appears that Linux hits a brick-wall when running out of
memory.

Note also that the results were roughly the same on Linux 1.3.20 and 1.2.8.
FreeBSD V2.2-current is faster yet than FreeBSD V2.1-stable.


Just FYI :-)
John
dyson@freebsd.org