On Tue, 30 Dec 2003, Manuel Kasper wrote:

> Basically, it seems that when pushing data at maximum speed (Ethernet
> -> Ethernet) through a net45xx that runs FreeBSD (m0n0wall actually),
> the CPU gets so fed up with handling all the interrupts (and packet
> filtering/NAT too) that the watchdogd process doesn't get any CPU time
> to tickle the watchdog anymore. Raising the priority of the process
> doesn't help either.

Ok - so we have a situation where userland essentially does not get any
CPU for over 30 seconds ? Sounds like indeed you -must- use polling:

> Au contraire - polling mode actually "solved" the problem by leaving
> watchdogd enough CPU time even at max. throughput.

Good - as you want userland to get a few cycles at least every 5 seconds
to keep things like userland dhcp, ntp and named happy. If not you may be
better off detecting a 20-60 second no-userland-cycles and at the very
least log it (as to at least least give the user a chance to understand
where mbuf or accept() queues getting too large is coming from).

Dw