Date: Sat, 25 Sep 2004 13:06:08 -0400 From: Chuck Swiger <cswiger@mac.com> To: TM4525@aol.com Cc: mike@sentex.net Subject: Re: Device polling performance Message-ID: <4155A580.4000501@mac.com> In-Reply-To: <192.2ebbbb6e.2e86eb67@aol.com> References: <192.2ebbbb6e.2e86eb67@aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
TM4525@aol.com wrote: [ ... ] > Ah, so the capacity of a FreeBSD router is > 10 million packets per second, > since 200K pps only uses .1 % of system resources. Kudos to the FreeBSD team > for developing a stack that uses no resources. > > It seems beyond unreasonable that, with interrupts enabled, 55% of the system > is used, and with polling, ~ zero. "Inconceivable!" "Erm...I do not think that word means what you think it means." It's probably easier to claim device polling works by black magic, then to explain just how much useless overhead is added when the CPU has to service tens of thousands of interrupts per second at very high packet rates. If you only need to bridge packets from one NIC to another, modern NICs will do almost all of the work (busmastering DMA, checksum offloading, etc) without needing any CPU time at all. If you've got good hardware, device polling means that the system is usually constrained by PCI bus throughput and the actual network transmission speed of the NICs themselves, not by CPU overhead. If you attempt to use crappy hardware (try digging up some 10Mbs ISA NICs), then the CPU will have to do a lot more work, and device polling will take up more than nearly zero CPU time. If you do routing, have firewall rules (particularly using dynamic stateful rules), or NAT (particularly running userland natd), you'll probably see significant CPU being used there. > Since its clear you have no idea what you're talking about, perhaps if > someone who actually does would like to pipe in it would be useful. > > It seems obvious that the "system" resource is not accurately monitored with > polling enabled, which is what Im trying to get someone to admit, or to tell > me when it was or will be repaired. You've got the source code to look at. If you find a mistake in the way the statistics are monitored, great: feel free to fix it. Not only will you earn more karma by submitting a PR or email containing a diff which solves the problem then you get from whining like a petulant child, you might actually resemble a polite human being long enough to encourage other people to respond to your problems instead of ignoring you. Do you understand this point, or am I being too subtle? -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4155A580.4000501>