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.Received on Wed May 11 2005 - 03:26:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC