Date: Mon, 07 Sep 2009 13:40:12 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Manish Vachharajani <manishv@lineratesystems.com> Cc: net@freebsd.org Subject: Re: UDP output performance Message-ID: <4AA4F11C.4060200@digiware.nl> In-Reply-To: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> References: <4AA14018.3010102@digiware.nl> <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Manish Vachharajani wrote:
> Hmm, what version of FreeBSD are you using? I don't know the solution
> but I wonder if it is related to a similar problem we are having with
> TCP connection scaling, both under 7.2 and 8.0 over a 10 Gb link.
> We've been trying to track it down, and if you see it for UDP as well
> that may give some clues.
>
> If you do a netstat -idh what is the output? Does the recieving
> interface show any Ierrs or drops? If so, you should be able to do a
> sysctl dev.em.<interface number>.stats=1 and then see some output via
> dmesg. Does this show any missed packets?
>
> Oh, also, what kind of machine are you running on?
Well this turns out to be a pilot error, in that I created such a complex
bandwidth evaluation that on buffer full the packet got tossed in the
application.
:(
Just stripping that out, and just do a
try send
while(not send) {
usleep(1 packet-time);
try again;
}
Reduced my packet loss to < 0.1% and I'm able to squeeze a nice > 900 Mbit/s
out of a single em(4) port. Still no packets begin dropped in netstat -i.
So now I'm off hunting for 'bugs' in snmp, cacti, mrtg to see why they don't
like the counters. Even when I'm using the 64bit counters I get really spiky
bandwidth results. Equal to those when using 32 bits counters, so
certainly things are not as I think they are.
Other thing is to see how Lin* is performing on this test.
So trying to install ubuntu 9.04.
--WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AA4F11C.4060200>