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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
