Date: Sun, 29 Feb 2004 21:38:20 -0500 From: Don Bowman <don@sandvine.com> To: 'Mike Tancsa' <mike@sentex.net>, Don Bowman <don@sandvine.com> Cc: freebsd-hackers@freebsd.org Subject: RE: em0, polling performance, P4 2.8ghz FSB 800mhz Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337045D832C@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
From: Mike Tancsa [mailto:mike@sentex.net] > At 08:44 PM 29/02/2004, Don Bowman wrote: > >From: Mike Tancsa [mailto:mike@sentex.net] > > > > > > On Sat, 28 Feb 2004 23:17:44 -0500, in > sentex.lists.freebsd.hackers > > > > >If you want to spend more time in kernel, perhaps change > > > > > > > >I might have HZ @ 2500 as well. > > > > > > Hi, > > > Just curious as to the reasoning behind that ? > > > >@ high packet rates, you don't have enough DMA > >queues available to the em driver, and will drop. > >increasing the number of dma buffers will cause > >problems with cache occupancy. Increasing the HZ > >doesn't have a huge cost. > > But why that value ? Did you determine it by trial and error > or deduce it > based on some other factors ? Also, is this value optimal > for fxp based boxes. I picked 2500 as the best for my system. Its higher than allowed by rfc1323 and PAWS [kern/61404], but not by so much that i anticipate a problem. For my target packets per second rate, it means that i can use a reasonable number of dma descriptors. I found that bridging performance in particular needs the higher hz to avoid dropping packets, to improve its performance. I'm not sure what affect on fxp. fxp is inherently limited by something internal to it, which prevents achieving high packet rates. bge is the best chip, but doesn't have the best bsd support. The value of HZ needs to be based on your target packet rate, the maximum latency in your system, and the size of your buffers for all steps. more buffers == better ability to handle latency bursts, but worse for cache occupancy. Freebsd is not the best system for trying to guarantee latency through, you can find things like ahd, syncache, arp freeing that will suddenly wake up and munch all kinds of cpu time with spl? taken. freebsd-current is both better and worse: its better with the fine grained locking, but worse since those locks can end up costing you more than you would have spent just taking giant and being done with it: semaphores are expensive, particularly on SMP systems.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337045D832C>