Kernel Timeslice

[Steve West]

>>> The ticks matter when the threads are competing for cpu, but it looks
>>> like in your case they'll mostly be waiting for socket calls (during
>>> which the schedular will hand off to another thread anyway), so
>>> increasing the timeslice frequency is probably not going to make a
>>> difference. Hard to know without testing of course.
>>>
>> Yes you are correct under "NORMAL" circumstances 100 ticks per second
>> would be ok. But if I design for worst case where all threads are running
>> I need 1000 ticks per second, or response will not be good. I did not 
>> want
>> to build a custom kernel, but it looks like I may have to to achieve the
>> design goal.
>
> Do you really expect all 1000 to be CPU bound? Most machines would give
> terrible response no matter the tick rate.
>
> As I recall, the tick rate only matters when the threads are, as Patrick
> said, _competing_ for CPU. Most TCP handlers will wake up, accept the
> connection, maybe send some data, and then _block_. Really fast. Well
> under 1/1000th of a second. The tick rate is how long a single thread
> can use the CPU flat out before a new scheduling decision is made.
> If, like most handlers, your threads wake up, do something, then block
> (including reading from disk) then it's not such an issue.
>
> Can you elaborate on your app; it is really going to try to run 1000 CPU
> bound threads? It will be prtetty unusual.

Maybe you are correct, I did not take into account that TCP would 
receive/send/block in under 1/1000th of a second. If that is the case then 
100 ticks per second would be ok. I will have to do some testing to evaluate 
this.

Steve