Re: xl(4) & polling
From: Subhro (subhro.kar_at_gmail.com)
Date: 05/11/05
- Previous message: Vladimir Botka: "Re: xl(4) & polling"
- In reply to: Rob: "Re: xl(4) & polling"
- Next in thread: Tuomo Latto: "Re: xl(4) & polling"
- Reply: Tuomo Latto: "Re: xl(4) & polling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 11 May 2005 10:56:08 +0530 To: Rob <spamrefuse@yahoo.com>
On 5/11/2005 10:40, Rob wrote:
>--- Subhro <subhro.kar@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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Vladimir Botka: "Re: xl(4) & polling"
- In reply to: Rob: "Re: xl(4) & polling"
- Next in thread: Tuomo Latto: "Re: xl(4) & polling"
- Reply: Tuomo Latto: "Re: xl(4) & polling"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
