gigabit "benchmark"

[Klaus Heinz]

Hi,

while searching for something different I stumbled across this
comparison using, among others, NetBSD/i386 4.0RC3

http://www.bluelife.at/articles/98/

IMO you can ignore the German text, the table below "Hardware" speaks for
itself.

Can anyone repeat those results for NetBSD?
Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
NICs as the others do and at the same time needs 100% CPU?

ciao
Klaus

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Klaus Heinz
Hi,
while searching for something different I stumbled across this
comparison using, among others, NetBSD/i386 4.0RC3
http://www.bluelife.at/articles/98/
IMO you can ignore the German text, the table below "Hardware" speaks for
itself.
Can anyone repeat those results for NetBSD?
Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
NICs as the others do and at the same time needs 100% CPU?

Maybe em enables hardware checkums automatically, while on wm it needs to
be turned on explicitely ?

[Hubert Feyrer]

Post by Klaus Heinz
Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
NICs as the others do and at the same time needs 100% CPU?

TCP buffers too small, and other values not tuned, see [1]? Though IIRC
there was something about auto-tuning those buffers, but I don't know if
that's enabled by default (or how to enable it if not).

[1] http://proj.sunet.se/LSR2/


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Havard Eidnes]

Post by Hubert Feyrer
TCP buffers too small, and other values not tuned, see [1]?

It could also be differences in parameter settings for interrupt
coalescing.

Post by Hubert Feyrer
Though IIRC there was something about auto-tuning those buffers, but
I don't know if that's enabled by default (or how to enable it if
not).

On a sufficiently new kernel, you could put this in /etc/sysctl.conf

net.inet.tcp.sendbuf_auto=1
net.inet.tcp.recvbuf_auto=1

to enable TCP window auto-tuning. This functionality arrived in
NetBSD-current on August 7 this year, and will not be in 4.0.

Regards,

- Håvard

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Hubert Feyrer
TCP buffers too small, and other values not tuned, see [1]? Though IIRC
there was something about auto-tuning those buffers, but I don't know if
that's enabled by default (or how to enable it if not).

I don't think that code is in NetBSD 4.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Havard Eidnes]

Post by Havard Eidnes
On a sufficiently new kernel, you could put this in /etc/sysctl.conf
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.recvbuf_auto=1
to enable TCP window auto-tuning. This functionality arrived in
NetBSD-current on August 7 this year, and will not be in 4.0.

Err... August 2, but what's a small week between friends? :-)

- Håvard

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Klaus Heinz
IMO you can ignore the German text, the table below "Hardware" speaks for
itself.

Well, given that FreeBSD and OpenBSD are using the Intel driver, it
could simply be some missing optimising setting in wm(4). Exactly what
revisions are those cards? Beside the checksum settings, I would also
take a look at the interrupt rate.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pavel Cahyna]

Post by Klaus Heinz
Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
NICs as the others do and at the same time needs 100% CPU?

TCP buffers too small, and other values not tuned, see [1]? Though IIRC there
was something about auto-tuning those buffers, but I don't know if that's
enabled by default (or how to enable it if not).
[1] http://proj.sunet.se/LSR2/

The test is for routing and pf, so TCP buffers should not matter.

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Klaus Heinz]

Post by Joerg Sonnenberger
Well, given that FreeBSD and OpenBSD are using the Intel driver, it
could simply be some missing optimising setting in wm(4). Exactly what

It looks like the wm driver does not automatically enable supported
options like TCP segmentation and checksum computing. The author of the
comparison will probably take a look at that, although his main interest
lies with Free-/OpenBSD.

ciao
Klaus

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Klaus Heinz]

Post by Hubert Feyrer
TCP buffers too small, and other values not tuned, see [1]? Though IIRC
there was something about auto-tuning those buffers, but I don't know if
that's enabled by default (or how to enable it if not).

I would have expected NetBSD to achieve wirespeed with a single Gigabit
NIC out of the box, nowadays. The blog entry does not mention tuning any
of the other operating systems, so I suppose no tuning was done.

ciao
Klaus

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Klaus Heinz

Post by Hubert Feyrer
TCP buffers too small, and other values not tuned, see [1]? Though IIRC
there was something about auto-tuning those buffers, but I don't know if
that's enabled by default (or how to enable it if not).

I would have expected NetBSD to achieve wirespeed with a single Gigabit
NIC out of the box, nowadays. The blog entry does not mention tuning any
of the other operating systems, so I suppose no tuning was done.

Maybe we should have offload turned on by default. It looks like all other
OSes have it on by default these days ... at last it's easier to turn
off with NetBSD than with linux :)

[Pavel Cahyna]

Post by Manuel Bouyer

Post by Klaus Heinz

Post by Hubert Feyrer
TCP buffers too small, and other values not tuned, see [1]? Though IIRC
there was something about auto-tuning those buffers, but I don't know if
that's enabled by default (or how to enable it if not).

I would have expected NetBSD to achieve wirespeed with a single Gigabit
NIC out of the box, nowadays. The blog entry does not mention tuning any
of the other operating systems, so I suppose no tuning was done.

Maybe we should have offload turned on by default. It looks like all other
OSes have it on by default these days ... at last it's easier to turn
off with NetBSD than with linux :)

Does the "em" driver in Free/OpenBSD turn it on by default?

And is it likely to make a big difference since what matters here are only
IP header checksums (not TCP/UDP checksums as it is a test of forwarding,
not send/receive)?

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Pavel Cahyna
And is it likely to make a big difference since what matters here are only
IP header checksums (not TCP/UDP checksums as it is a test of forwarding,
not send/receive)?

I was more thinking about RX/TX interrupt moderation and that can make a
huge difference in terms of load/packet.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de