I seem to recall a similar thing happening for my throttledwsocket. I think I fixed it by setting the option NoReceiveLoop (not sure of the name, but you know what I mean). Maybe your problem is related, worth a try.
Dan ----- Original Message ----- From: "Fastream Technologies" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Sunday, January 29, 2006 12: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
