| 1 |
On 08/11/2011 10:35 AM, Pandu Poluan wrote: |
| 2 |
> On Thu, Aug 11, 2011 at 14:27, Nikos Chantziaras<realnc@×××××.de> wrote: |
| 3 |
>> On 08/11/2011 09:56 AM, Pandu Poluan wrote: |
| 4 |
>>> |
| 5 |
>>> Just wondering, is it possible to specify a custom timer frequency? |
| 6 |
>>> E.g., HZ=500 instead of one of the canned values (100, 250, 300, |
| 7 |
>>> 1000). |
| 8 |
>> |
| 9 |
>> It is possible, but it's a bad idea because non-standard values can result |
| 10 |
>> in driver breakage. Some code assumes specific timer granularities (100Hz = |
| 11 |
>> 10ms, 250Hz = 4ms, etc). This usually happens with values above 1000Hz, so |
| 12 |
>> it might be possible to experiment with non-standard sub-1000Hz values. |
| 13 |
>> |
| 14 |
>> But why do you want a custom value anyway? |
| 15 |
>> |
| 16 |
> |
| 17 |
> Well, for a firewall, I've calculated (gathered and extrapolated from |
| 18 |
> a lot of sources), the latency per-packet is usually less than 1 ms, |
| 19 |
> at worst still less than 2 ms. |
| 20 |
> |
| 21 |
> Thus, setting the timer freq to 100 Hz (as suggested for 'normal' |
| 22 |
> server load) means the timeslice is way too long (10 ms per time |
| 23 |
> slice). |
| 24 |
> |
| 25 |
> So, I speculate that better -- and uniform -- performance will be |
| 26 |
> achieved with a timer freq of 500 Hz. |
| 27 |
> |
| 28 |
> Of course, this is a wild speculation/guess from me. I never quite |
| 29 |
> understand netfilter/xtables' relation to the timeslices, so I may be |
| 30 |
> talking nonsense :-) |
| 31 |
|
| 32 |
This assumes that networking is dependent on the timer interrupt, which |
| 33 |
doesn't seem to be the case; going from 100Hz to 1000Hz will not result |
| 34 |
in network latencies dropping by 9ms. I know because I tried it on a |
| 35 |
server. |
| 36 |
|
| 37 |
The only case where network latency improved with a higher HZ was with a |
| 38 |
game server (Counter-Strike) and that's only because that game's server |
| 39 |
component is timer dependent when calculating the game world (to do 1000 |
| 40 |
updates per second it needs a HZ value of 1000). So that application |
| 41 |
has some real-time demands, meaning a high HZ value helps. Otherwise, |
| 42 |
you can stick to 100Hz on a server. Higher values won't change anything |
| 43 |
and will only reduce throughput (though not by much anyway, which is why |
| 44 |
some people set 1000Hz even on servers.) |
Archives