Date: Wed, 10 Oct 2007 10:54:53 -0400 From: Ed Maste <emaste@phaedrus.sandvine.ca> To: Michael DeMan <michael@staff.openaccess.org> Cc: freebsd-net@freebsd.org, Cristian KLEIN <cristi@net.utcluj.ro>, lists@codeangels.com Subject: Re: FreeBSD as a gigabit router Message-ID: <20071010145453.GA54106@sandvine.com> In-Reply-To: <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 04, 2007 at 12:02:56PM -0700, Michael DeMan wrote: > Also, we've noticed at least on FBSD 6.x that there seem to be very > few advantages in using polling on network interfaces. We still run > it, so that we have responsive SSH/BGP/OSPF processes on the > machines, but my testing has shown that for sheer throughput, there > is basically no difference. I'd be curious if anybody knows the > scoop on this. The polling mechanism includes a feedback mechanism that attempts to keep a certain amount of CPU time available for userland. It works well at keeping the system usable under high load, but it doesn't perform so well if you want to dedicate most of the CPU time to polling in order to get near the maximum throughput. I have some prototype code that addresses this, and the the throughput with the new polling algorithm beat the non-polling kernel perf. by a small margin. This won't make it into RELENG_7, but I plan to bring it to HEAD at some point. -Ed
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071010145453.GA54106>