Ok, fine. But, in order to avoid misunderstanding, wouldn't it be better
to have a wrapper function (msleep ?) and use that where really
millisecond granularity is desired ? Otherwise sooner or later somebody
could use usleep where really microsecond granularity is desired, with
undesiderabile results on some platforms wher only millisecond
granularity is available (currently windows only, ok, but still... from
a "clean code" point of view...)

The --limit-rate seems to work correctly on windows with this patch,
except obviously when the general "sleep" approach is too far from
optimal, for example a fast connection and a very low rate.

What I mean is, while testing that I found (like expected) with a ~
30kb/sec connection to the server and a --limit-rate=100 wget would read
a whole buffer, sleep for several seconds, read another full buffer and
so on; Mean bandwidth used was correctly around 100 bytes/sec, but a
bandwidth monitor showed lots of high spikes separated by pauses. It
would be interesting experimenting with something like that while on the
same pipe some or several other high bandwidth transfers are occuring.

Wasn't there some time ago a bandwidth patch floating around which
played with window sizes instead of pausing ? Probably more correct but
less portable :(

Heiko

-- 
-- PREVINET S.p.A.            [EMAIL PROTECTED]
-- Via Ferretto, 1            ph  x39-041-5907073
-- I-31021 Mogliano V.to (TV) fax x39-041-5907087
-- ITALY



>-----Original Message-----
>From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 29, 2001 3:09 PM
>To: Wget List
>Subject: Re: windows patch and problem
>
>
>Herold Heiko <[EMAIL PROTECTED]> writes:
>
>>      *  cmpt.c: provided usleep somewhat-emulation
>
>Note that your emulation is perfectly fine not only because usleep()
>is currently called with multiples of thousand, but also because Wget
>doesn't *really* depend on microsecond granularity of usleep, because
>it's not there.
>
>A good test for your usleep() is to see whether --limit-rate works.
>
>Thanks for the patch; I'm about to apply it.
>

Reply via email to