xl(4) & polling

[Subhro]

On 5/11/2005 10:40, Rob wrote:

>--- Subhro <subhro.kar at gmail.com> wrote:
>
>  
>
>>On 5/11/2005 8:04, Rob wrote:
>>
>>    
>>
>>>All computers are running 5-Stable, as of May 10.
>>>All, but PC1 with fxp, use polling, with:
>>>  options DEVICE_POLLING
>>>  options HZ=1000
>>>      
>>>
>>1000 IMHO seems a bit too heavy. Try something
>>lower.
>>    
>>
>
>What is heavy and what is not?
>Does 100 sound better?
>
>How can I develop a feeling for the 'heaviness' of
>this HZ number? Is it related to the CPU speed?
>
>Thanks for clarifying!
>
>Rob.
>
>  
>
Before I answer this question, I would like to clarify a few things. 
Previously (when there was no concept of Device Polling) whenever a 
packet arrived at a network interface, the NIC generated an interrupt. 
An interrupt would cause the processor to stop whatever it was doing and 
make it look into the reason why the interrupt was generated. This 
concept had no problems except the fact that it could be used 
maliciously. For example, if someone wants to consume all processing 
power, he may create an interrupt storm by constanly sending packets to 
the NIC. the NIC would continue generating interrupts and the processor 
would be busy servicing them, thus wasting and depriving other processes 
from precious CPU cycles. This is one form of Denial of Service attack. 
Also for systems which handle really heavy loads, a legal series of 
interrupts may seem like a DOS. Thus the concept of Device Polling came 
into play

In Device Polled systems, the NIC does not generate any interrupt at 
all. Instead whenever the packets arrive at a Network interface, they 
are captured and put into a queue. The kernel scheduler checks the quese 
at regular intervals and processes the packets which are waiting. This 
interval is adjusted by the "options HZ=x" kernel option.

If the value of x is very high, there may eb two scenarios. In the first 
scenario, the queue may fill up and subsequent packets are dropped. In 
this case retransmission of the packets are required. In the second 
scenario, the packets would be held up for excessive long times which 
defeats the entire purpose of Device Polling. If the value of x is very 
low, the scheduler would check the queue frequently and would again 
defeat the entire idea of Device Polling.

The value of x is very much implementation and load specific. When I 
have to put up a new FreeBSD box, I start from 100 and start beefing up 
the number until I find a good balance. For your implementaion it seems 
to me as if the packets are waiting in the queue for a long time which 
are causing the SSH sessions to time out.

Regards
S.