I have a client app that runs a high number of threads and pumps tcp/ip
requests to a server at high intensity.  To slow down the app, I've
tried to introduce nanosleep, but have found that it doesn't result in
predictable delays.  Is there another method to use on the threads that
would be more predictable?

Thanks.

morty3e@gmail.com schrieb:
> I have a client app that runs a high number of threads and pumps tcp/ip
> requests to a server at high intensity.  To slow down the app, I've
> tried to introduce nanosleep, but have found that it doesn't result in
> predictable delays.  Is there another method to use on the threads that
> would be more predictable?
> 
> Thanks.
> 

I suppose that you are using Linux due to your problem with the nanosleep().
The timer of the vanilla Kernel depends on the system speed and is thus
not quite precise. You could:
1. tune the system frequence high (1000 Hz max. since 2.6.12)
2. apply the Preemption-Realtime patch of Ingo Molnar.
http://people.redhat.com/mingo/realtime-preempt/
The timer usage of nanosleep is directly mapped to the ktimer of the
patch. It's a high resolution realtime clock and will hopefully meat
your requirement.

Good luck
Cheers
Luotao Fu

morty3e@gmail.com wrote On 10/27/05 10:13,:
> I have a client app that runs a high number of threads and pumps tcp/ip
> requests to a server at high intensity.  To slow down the app, I've
> tried to introduce nanosleep, but have found that it doesn't result in
> predictable delays.  Is there another method to use on the threads that
> would be more predictable?

    For high accuracy you need a real-time system.  (What
"high accuracy" means is application-dependent.)

    To get a rate that's fairly good (another application-
dependent term), you could create a "governor" thread.  It
would check the current time with a high-resolution timer
(e.g., gethrtime() on Solaris), then sleep for a nominal
interval, then use the high-resolution timer to get the
actual time upon awakening.  From the actual elapsed time
and the desired message rate it would calculate the number
of messages that are now "due," and increment a semaphore
that many times.  Pseudocode:

	quota = 0;
	start = gethrtime();
	while (running) {
	    sleep_a_while();
	    goal = (gethrtime() - start) * message_rate;
	    increment_semaphore(goal - quota);
	    quota = goal;
	}

    Meanwhile, the message-generating threads spew requests
as fast as they can, but decrement the semaphore before each
transmission.  They'll wait until the governor says it's time
for more requests, and they will never exceed the quota.

    The overall effect will be a bit bursty: You'll have a
few moments of silence until the governor calls for more
traffic, then a flurry of requests as all the requestors
burn through the quota, then another interval of silence,
and so on.  If the governor's sleep intervals are brief
enough this may be acceptable.  You could also slow down the
requestors a bit by introducing sleeps as you've already done,
but with the governor throttling the overall rate of progress
you're no longer so dependent on the accuracy of the sleep
intervals.  You could even "tune" the requestors' nominal
sleep times by keeping track of how long a requestor thread
waits for the semaphore: if it always winds up waiting then
it's probably sleeping for too short a time, but if it never
waits it's probably sleeping too long.

    Whether any of this is tenable depends on just how tightly
you need to control the request generation rate.  As I said at
the beginning, for extremely tight control you'll need features
that go beyond what a general-purpose O/S is designed to deliver.

-- 
Eric.Sosman@sun.com

morty3e@gmail.com wrote:
> I have a client app that runs a high number of threads and pumps tcp/ip
> requests to a server at high intensity.  To slow down the app, I've
> tried to introduce nanosleep, but have found that it doesn't result in
> predictable delays.  Is there another method to use on the threads that
> would be more predictable?
> 
> Thanks.

You could try to count the requests you sent.
(maybe in the last n seconds)

HTH,
AvK

I've been thinking of doing that, but using nanosleep() after reaching
that (one second) limit would still rely on nanosleep() and its
unpredictable results.

Here are some numbers I got when doing a quick test.

Delay,Write,Read,Puts,Threads,Read TPS
0,2,16,100,1,6250
1,100,109,100,1,917
10,102,111,100,1,901
100,138,150,100,1,667
1000,982,983,100,1,102
10000,994,995,100,1,101
10000,992,993,100,1,101
100000,993,994,100,1,101
1000000,1835,1836,100,1,54
10000000,10946,10947,100,1,9

0,12,55,1000,1,18182
1,993,994,1000,1,1006
10,1067,1076,1000,1,929
100,1034,1044,1000,1,958
1000,9927,9928,1000,1,101
10000,9991,9992,1000,1,100
10000,9996,9997,1000,1,100
100000,9993,9994,1000,1,100
1000000,19102,19103,1000,1,52
10000000,109707,109708,1000,1,9

0,13,34,100,10,29412
1,75,83,100,10,12048
10,80,88,100,10,11364
100,107,125,100,10,8000
1000,990,991,100,10,1009
10000,993,994,100,10,1006
10000,994,995,100,10,1005
100000,1001,1002,100,10,998
1000000,1711,1719,100,10,582
10000000,10942,10943,100,10,91

0,77,277,1000,10,36101
1,1337,1340,1000,10,7463
10,1270,1278,1000,10,7825
100,1221,1229,1000,10,8137
1000,9977,9978,1000,10,1002
10000,9993,9994,1000,10,1001
10000,9997,9998,1000,10,1000
100000,9996,9997,1000,10,1000
1000000,19066,19067,1000,10,524
10000000,109808,109809,1000,10,91

<morty3e@gmail.com> wrote in message 
news:1130422431.532259.144650@g49g2000cwa.googlegroups.com...

>I have a client app that runs a high number of threads and pumps tcp/ip
> requests to a server at high intensity.  To slow down the app, I've
> tried to introduce nanosleep, but have found that it doesn't result in
> predictable delays.  Is there another method to use on the threads that
> would be more predictable?

    Why do you need to slow down the app? TCP/IP has its own pacing, you 
should be able to read/write data to the TCP/IP connections at full speed 
without any problem.

    DS

On 2005-11-03, David Schwartz <davids@webmaster.com> wrote:
[...]
>     Why do you need to slow down the app? TCP/IP has its own pacing, you 
> should be able to read/write data to the TCP/IP connections at full speed 
> without any problem.

Sometimes, there're some "funny" requirements saying that this
particular code must not process input faster than this and this :) 
For example we have multiple links, one link pushes lots of data, thus
pulling on itself CPU, bandwith etc. We want to slow it down. Another
example, our peer server is buggy, and if we feed the data too fast, then
that server hits some race condition and crashes. They can't fix the
server (commercial product), so instead we have to push data slower.

I guess there are lots of examples in real world that put the
requirement to slow down TCP stream. Fortunately, so far I didn't hit
the requirement to do it with nanosecond accuracy :)

-- 
Minds, like parachutes, function best when open