figure 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.
>>
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
kern.polling.burst: 150
kern.polling.burst_max: 150
k
On Fri, 20 Nov 2009 14:35:22 -0700 (MST), Brett Glass
wrote:
> Everyone:
>
> I've been experimenting with using device polling on a router with six
> Ethernet
> interfaces that handles lots of traffic. I turned polling on, and set
> HZ=4000
> to minimize latency and ensure that enough time was al
Everyone:
I've been experimenting with using device polling on a router with six Ethernet
interfaces that handles lots of traffic. I turned polling on, and set HZ=4000
to minimize latency and ensure that enough time was allocated to handle all of
the incoming packets. But the sysctl variable kerne
