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