At 06:25 PM 11/20/2009, Mel Flynn wrote:
So that means that you give the kernel .25 microseconds to poll and act on
any pending network IO. That's probably not enough.
I think that you mean ".25 milliseconds," not ".25 microseconds," above.
It is further explained by
comment in sys/kern/kern_poll.c:
* Hook from hardclock. Tries to schedule a netisr, but keeps track
* of lost ticks due to the previous handler taking too long.
* Normally, this should not happen, because polling handler should
* run for a short time. However, in some cases (e.g. when there are
* changes in link status etc.) the drivers take a very long time
* (even in the order of milliseconds) to reset and reconfigure the
* device, causing apparent lost polls.
* The first part of the code is just for debugging purposes, and tries
* to count how often hardclock ticks are shorter than they should,
* meaning either stray interrupts or delayed events.
Well, even at HZ=2000, kern.polling.lost_polls and
kern.polling.suspect are both incrementing, as is kern.polling.stalled:
stargate# sysctl -a | grep polling
But if I slow the clock down to 1000 Hz, it's unclear if the
machine will be able to keep up with traffic. I was already getting
more than 1,000 network interrupts per second before I tried
polling, and I'm not sure how many packets the interfaces (some
fxp, some em) can buffer up. I'm going to try it, but if it doesn't
work I will have to go back to interrupt-driven operation.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"