For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
During the original benchmarks, using the newly-release 2.4.0, Linux was
largely hammered by FreeBSD, and exhibited all sorts of interactivity
problems under load, due to VM and other issues.
Well now, with the newer releases, we really seem to have caught up again.
The new VM, and the millions of other fixes since 2.4.0 have made all the
difference. FreeBSD is an impressive OS, and a worthy competitor with
a distinguished heritage - it's great to see Linux snapping at its
heels.
So congratulations to all kernel developers - 2.4.x has basically 'made
it' now, and months of hard work have produced a stable, high-performance
and cutting edge kernel. I'm looking forward to running the
cross-bred Linus / Alan 2.4.15 soon, and even more to 2.5.x - as Linux
heads onwards to new levels yet again.
Cheers
Alastair
_____________________________________________
Alastair Stevens
MRC Biostatistics Unit
Cambridge UK
---------------------------------------------
phone - 01223 330383
email - [email protected]
web - http://www.mrc-bsu.cam.ac.uk
On Tue, 13 Nov 2001, Alastair Stevens wrote:
> For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
> Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
>
> http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
is just as good as piping it to /dev/null. See RFC-1123.
In article <[email protected]> you wrote:
> On Tue, 13 Nov 2001, Alastair Stevens wrote:
>
>> For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
>> Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
>>
>> http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
>
> Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> is just as good as piping it to /dev/null. See RFC-1123.
After the last VM article no one expect any clue from him anayway 8)
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Matthias Andree <[email protected]> writes:
> On Tue, 13 Nov 2001, Alastair Stevens wrote:
>
> > For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
> > Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
> >
> > http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
>
> Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> is just as good as piping it to /dev/null. See RFC-1123.
Umm... He specifically stated that it was a Very Bad Idea for
production systems. He simply wanted to measure general throughput
rather than disk latency (which is a bottleneck with fsync()
enabled).
It's a benchmark, lighten up! ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
On Tue, 13 Nov 2001, Doug McNaught wrote:
> > Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> > is just as good as piping it to /dev/null. See RFC-1123.
>
> Umm... He specifically stated that it was a Very Bad Idea for
> production systems. He simply wanted to measure general throughput
> rather than disk latency (which is a bottleneck with fsync()
> enabled).
>
> It's a benchmark, lighten up! ;)
Well, he wanted to benchmark everyday use, and disk latency is also an
issue for everyday use, of course; so that's kind of pointless getting
rid of I/O and benchmarking the cache. fsync() efficiency comes into
play and wants to be benchmarked as well. How do you know if your
fsync() syncs what's needed, the whole partition, the partition's meta
data (softupdates!) or the world (all blocks)?
Matthias Andree <[email protected]> writes:
> On Tue, 13 Nov 2001, Doug McNaught wrote:
>
> > It's a benchmark, lighten up! ;)
>
> Well, he wanted to benchmark everyday use, and disk latency is also an
> issue for everyday use, of course;
But it's more a measure of your disk subsystem than your VM efficiency
(unless something is badly wrong).
> so that's kind of pointless getting
> rid of I/O and benchmarking the cache. fsync() efficiency comes into
> play and wants to be benchmarked as well. How do you know if your
> fsync() syncs what's needed, the whole partition, the partition's meta
> data (softupdates!) or the world (all blocks)?
A very good point that I hadn't considered.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
[email protected] (Matthias Andree) wrote on 13.11.01 in <[email protected]>:
> On Tue, 13 Nov 2001, Alastair Stevens wrote:
>
> > For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
> > Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
> >
> > http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
>
> Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> is just as good as piping it to /dev/null. See RFC-1123.
I rather think a non-fsync() system has a very much higher rate of
successful mail deliveries than a /dev/null one, and only slightly (if at
all) lower than a fsync() one.
Now, that slight difference *can* be rather important if you're a major
mail hub - or it can be below the noise level in an end user system. In
either case, however, *nobody* will accept /dev/null as an equivalent
substitute.
Well, nobody but you.
MfG Kai
Why is he using FreeBSD 4.3? Version 4.4 has been out for quite a
while....that seems like quite an oversight, unless 4.3 performs better than
4.4, which I doubt.
----- Original Message -----
From: "Kai Henningsen" <[email protected]>
To: <[email protected]>
Sent: Tuesday, November 13, 2001 10:05 AM
Subject: Re: 2.4.x has finally made it!
> [email protected] (Matthias Andree) wrote on 13.11.01
in <[email protected]>:
>
> > On Tue, 13 Nov 2001, Alastair Stevens wrote:
> >
> > > For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited
his
> > > Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
> > >
> > > http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
> >
> > Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> > is just as good as piping it to /dev/null. See RFC-1123.
>
> I rather think a non-fsync() system has a very much higher rate of
> successful mail deliveries than a /dev/null one, and only slightly (if at
> all) lower than a fsync() one.
>
> Now, that slight difference *can* be rather important if you're a major
> mail hub - or it can be below the noise level in an end user system. In
> either case, however, *nobody* will accept /dev/null as an equivalent
> substitute.
>
> Well, nobody but you.
>
> MfG Kai
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Matthias Andree writes:
> On Tue, 13 Nov 2001, Alastair Stevens wrote:
>> For those who haven't seen it yet, Moshe Bar at BYTE.com has revisited his
>> Linux 2.4 vs FreeBSD benchmarks, using 2.4.12 in this case:
>>
>> http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html
>
> Wow. That person is knowledgeable... NOT. Turning off fsync() for mail
> is just as good as piping it to /dev/null. See RFC-1123.
The same could be said of any mail server that isn't RAID at
the very least. Oh, let's demand an off-site backup before
returning an OK status to the sender, and one of those S/390
processors that runs two pipelines in lock-step to detect
errors in the CPU. Swat the very last kernel bug too BTW.
Really, this isn't a big deal. Maybe it wasn't the best choice.
The drive probably lies to the OS anyway, so get over it.
On Wed, 14 Nov 2001, Albert D. Cahalan wrote:
> Really, this isn't a big deal. Maybe it wasn't the best choice.
> The drive probably lies to the OS anyway, so get over it.
The drive lies to the OS exactly when a fast write cache is configured.
--
Matthias Andree
On Tue, 13 Nov 2001, Doug McNaught wrote:
> > Well, he wanted to benchmark everyday use, and disk latency is also an
> > issue for everyday use, of course;
>
> But it's more a measure of your disk subsystem than your VM efficiency
> (unless something is badly wrong).
The matters are:
- "everyday use" (go with fsync() for mail)
- how good does VM cope with - say - "priority write" actions like
fsync()?
--
Matthias Andree