On 17Nov2008 15:19, Steve West <steve@xxxxxxxxxx> wrote: >> 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. Cheers, -- Cameron Simpson <cs@xxxxxxxxxx> DoD#743 http://www.cskk.ezoshosting.com/cs/ Ride with a llama and you never ride alone. - Jeff Earls, DoD #0530, <jearls@xxxxxxxxxxxxxxxxxx> -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
