The problem I see is 100 mS.
Just for fun, try with 2000 mS and evaluate the mean bandwidth on a 10 sec 
period.
When it works, you may lower the numbers.
--
[EMAIL PROTECTED]
http://www.overbyte.be

----- Original Message ----- 
From: "Fastream Technologies" <[EMAIL PROTECTED]>
To: "ICS support mailing" <twsocket@elists.org>
Sent: Sunday, January 29, 2006 1:37 PM
Subject: Re: [twsocket] THttpConnection throttling problem with timer


> 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 

-- 
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

Reply via email to