Hello,
Perhaps we should think at the algorithm level. Here it is for your eyes
only: ;)
I want to throttle bandwidth of my reverse proxy which uses THttpConnection
and inside it an associated THttpCli.
Bandwidth and consumed bandwidth is per domain and protected by critical
sections.
There is a serverThread for the listener of THttpServer and there are the
worker threads.
This is the algorithm:
In the worker thread:
-once a data is sent or received, inc the countOfDataForLast100ms
-every 100ms, a message is passed from the serverThread so that the value of
countofDataForLast100ms is added to consumedBW
In the server thread:
-if msecs % 800 == 0
resetConsumedAmount();
resume all paused connections();
-else
for each connection
if it's not paused
if the consumed bandwidth has exceeded the total bandwidth in a total
period of 8 secs
pause();
Do you see a problem with this algorithm? I cannot but it does not work. It
has the following problems:
- TryToSend in WSocket consumes 100% CPU
- Bandwidth is not limited much (my test kBps is 100 but it downloads at
4.2MBps!
Best Regards,
SZ
----- Original Message -----
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing" <twsocket@elists.org>
Sent: Sunday, January 29, 2006 2:02 PM
Subject: Re: [twsocket] THttpConnection throttling problem with timer
>>> Not really. Each time I see a TTimer triggered every 100 mSec (or any
>>> very
>>> short time period), I know this will cause CPU problem. And bandwidth
>>> limitation defenitely doesn't require a so short period of time. What is
>>> useful, regarding bandwidth limitation - is to have bandwidth limited on
>>> a
>>> reasonable time period (a few second IMO).
>>
>>
>> Francois,
>>
>> I disagree with this ,
>>
>> When a user has a very high bandwidth (100 Mbs), sampling every second is
>> way too slow.
>> I you use 1000 msec sampling period, the throttle does not work work at
>> all.
>> Most likely, all data has been sent before the the throttle becomes
>> active.
>
> Indeed. But nothing will be sent before the pause period has elapsed. The
> net effect is the actual bandwidth being limited to the programmed level.
> Of
> course the instantaneous speed is _always_ the line speed. You can't slow
> down a packet, it is always sent at wire speed. But you can slow down the
> mean bandwidth computed on a given time interval. I pretend this time
> interval should be at least a few seconds. Making this time interval
> shorter
> would impose a high CPU load without significant advantage.
>
> If you don't use persistant connection, then you should probably also
> delay
> the new connection while still in pause period (I'm not sure about the
> pause
> effect when connection is closed. I think it is simply ignored).
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
