Hi
New to the list.
Wrote a patch that Works For Me to limit to a "percent of measured
bandwidth". This is useful, like --limit-rate, in cases where an
upstream switch is poorly made and interactive users get locked out
when a single box does a wget, but limit-pct is more "automatic" in
the sens
On 10/8/07, A. P. Godshall <[EMAIL PROTECTED]> wrote:
> Anyhow, does this seem like something others of you could use? Should
> I submit the patch to the submit list or should I post it here for
> people to hash out any parameterization niceties etc first?
Go ahead and send it on here so we can c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A. P. Godshall wrote:
> Hi
>
> New to the list.
Welcome!
> Wrote a patch that Works For Me to limit to a "percent of measured
> bandwidth". This is useful, like --limit-rate, in cases where an
> upstream switch is poorly made and interactive user
And here's another post that apparently got sent with an erroneous
signature. I think I may have figured out what was wrong; I specifically
remember that I was still holding shift down when I typed one of the
spaces in my passphrase... maybe that results in some screwiness...
--
Micah J. Cowan
Pr
On Mon, 8 Oct 2007, Micah Cowan wrote:
> As to whether or not it will be included in mainline Wget, that depends
> on the answer to your question, "does this seem like something others of
> you could use?" I, personally, wouldn't find it very useful (I rarely
> use even --limit-rate), so I'd be in
On 10/9/07, Jim Wright <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Oct 2007, Micah Cowan wrote:
>
> > As to whether or not it will be included in mainline Wget, that depends
> > on the answer to your question, "does this seem like something others of
> > you could use?" I, personally, wouldn't find it v
> Go ahead and send it on here so we can comment on the code :-)
...
I sent it to wget-patches; if you are not subscribed to that, you can
find it at...
http://permalink.gmane.org/gmane.comp.web.wget.patches/2190
Discussion here or there, I don't care
--
Best Regards.
Please keep in touch.
Jim Wright <[EMAIL PROTECTED]> writes:
>> - --limit-rate will find your version handy, but I want to hear from
>> them. :)
>
> I would appreciate and have use for such an option. We often access
> instruments in remote locations (think a tiny island in the Aleutians)
> where we share bandwidth wi
I think there is still a case for attempting percent limiting. I agree
with your point that we can not discover the full bandwidth of the
link and adjust to that. The approach discovers the current available
bandwidth and adjusts to that. The usefullness is in trying to be
unobtrusive to other u
> > >> - --limit-rate will find your version handy, but I want to hear from
> > >> them. :)
> > > I would appreciate and have use for such an option. We often access
> > > instruments in remote locations (think a tiny island in the Aleutians)
> > > where we share bandwidth with other organization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim Wright wrote:
> I think there is still a case for attempting percent limiting. I agree
> with your point that we can not discover the full bandwidth of the
> link and adjust to that. The approach discovers the current available
> bandwidth and
> ... I worry that that might be more harmful to those sharing channel in cases
> like Hvroje's ...
Sorry, Hvroje, Jim, I meant Jim's case.
Tony
> Jim Wright wrote:
> > I think there is still a case for attempting percent limiting. I agree
> > with your point that we can not discover the full bandwidth of the
> > link and adjust to that. The approach discovers the current available
> > bandwidth and adjusts to that. The usefullness is in
Jim Wright <[EMAIL PROTECTED]> writes:
> I think there is still a case for attempting percent limiting. I
> agree with your point that we can not discover the full bandwidth of
> the link and adjust to that. The approach discovers the current
> available bandwidth and adjusts to that. The usefu
Hrvoje Niksic wrote:
> Measuring initial bandwidth is simply insufficient to decide what
> bandwidth is really appropriate for Wget; only the user can know
> that, and that's what --limit-rate does.
The user might be able to make a reasonable guess as to the download rate if
wget reported its ave
On 10/10/07, Tony Lewis <[EMAIL PROTECTED]> wrote:
> Hrvoje Niksic wrote:
>
> > Measuring initial bandwidth is simply insufficient to decide what
> > bandwidth is really appropriate for Wget; only the user can know
> > that, and that's what --limit-rate does.
>
> The user might be able to make a re
Indeed.
On 10/10/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Jim Wright <[EMAIL PROTECTED]> writes:
>
> > I think there is still a case for attempting percent limiting. I
> > agree with your point that we can not discover the full bandwidth of
> > the link and adjust to that. The approach disc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
> Jim Wright <[EMAIL PROTECTED]> writes:
>
>> I think there is still a case for attempting percent limiting. I
>> agree with your point that we can not discover the full bandwidth of
>> the link and adjust to that. The approac
> >> I think there is still a case for attempting percent limiting. I
> >> agree with your point that we can not discover the full bandwidth of
> >> the link and adjust to that. The approach discovers the current
> >> available bandwidth and adjusts to that. The usefullness is in
> >> trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> The scenario I was picturing was where you'd want to make sure some
> bandwidth was left available so that unfair routers wouldn't screw
> your net-neighbors. I really don't see this as an attempt to "be
> unobtrusive" at all.
On 10/10/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Tony Godshall wrote:
> > The scenario I was picturing was where you'd want to make sure some
> > bandwidth was left available so that unfair routers wouldn't screw
> > your net-neighbors. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> On 10/10/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
>> My current impression is that this is a useful addition for some limited
>> scenarios, but not particularly more useful than --limit-rate already
>> is. That's part of what
"Tony Godshall" <[EMAIL PROTECTED]> writes:
>> > available bandwidth and adjusts to that. The usefullness is in
>> > trying to be unobtrusive to other users.
>>
>> The problem is that Wget simply doesn't have enough information to be
>> unobtrusive. Currently available bandwidth can and does cha
On 10/12/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> Again, I do not claim to be unobtrusive. Merely to reduce
> obtrusiveness. I do not and cannot claim to be making wget *nice*,
> just nicER.
>
> You can't deny that dialing back is nicer than not.
Personally, I think this is a great idea. B
On 10/12/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> "Tony Godshall" <[EMAIL PROTECTED]> writes:
>
> >> > available bandwidth and adjusts to that. The usefullness is in
> >> > trying to be unobtrusive to other users.
> >>
> >> The problem is that Wget simply doesn't have enough information to b
On 10/12/07, Josh Williams <[EMAIL PROTECTED]> wrote:
> On 10/12/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> > Again, I do not claim to be unobtrusive. Merely to reduce
> > obtrusiveness. I do not and cannot claim to be making wget *nice*,
> > just nicER.
> >
> > You can't deny that dialing ba
"Tony Godshall" <[EMAIL PROTECTED]> writes:
>> My point remains that the maximum initial rate (however you define
>> "initial" in a protocol as unreliable as TCP/IP) can and will be
>> wrong in a large number of cases, especially on shared connections.
>
> Again, would an algorithm where the rate
On 10/12/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Personally I don't see the value in attempting to find out the
> available bandwidth automatically. It seems too error prone, no
> matter how much heuristics you add into it. --limit-rate works
> because reading the data more slowly causes i
On 10/12/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> "Tony Godshall" <[EMAIL PROTECTED]> writes:
>
> >> My point remains that the maximum initial rate (however you define
> >> "initial" in a protocol as unreliable as TCP/IP) can and will be
> >> wrong in a large number of cases, especially on sh
OK, so let's go back to basics for a moment.
wget's default behavior is to use all available bandwidth.
Is this the right thing to do?
Or is it better to back off a little after a bit?
Tony
On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> OK, so let's go back to basics for a moment.
>
> wget's default behavior is to use all available bandwidth.
>
> Is this the right thing to do?
>
> Or is it better to back off a little after a bit?
>
> Tony
IMO, this should be handled by the o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
>> OK, so let's go back to basics for a moment.
>>
>> wget's default behavior is to use all available bandwidth.
>>
>> Is this the right thing to do?
>>
>> Or is it better to back off a little
On 10/13/07, Josh Williams <[EMAIL PROTECTED]> wrote:
> On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> > OK, so let's go back to basics for a moment.
> >
> > wget's default behavior is to use all available bandwidth.
> >
> > Is this the right thing to do?
> >
> > Or is it better to back of
On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> Well, you may have such problems but you are very much reaching in
> thinking that my --linux-percent has anything to do with any failing
> in linux.
>
> It's about dealing with unfair upstream switches, which, I'm quite
> sure, were not runni
On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> > On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> >> OK, so let's go back to basics for a moment.
> >>
> >> wget's default behavior is to use all available bandwidth.
> >>
> >> Is t
On 10/13/07, Josh Williams <[EMAIL PROTECTED]> wrote:
> On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> > Well, you may have such problems but you are very much reaching in
> > thinking that my --linux-percent has anything to do with any failing
> > in linux.
> >
> > It's about dealing with
On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> > On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> >> OK, so let's go back to basics for a moment.
> >>
> >> wget's default behavior is to use all available bandwidth.
> >>
> >> Is t
Tony Godshall wrote:
> If it was me, I'd have it default to backing off to 95% by default and
> have options for more aggressive behavior, like the multiple
> connections, etc.
I don't like a default back-off rule. I often encounter downloads with
often changing download speeds. The idea that the
On 10/17/07, Matthias Vill <[EMAIL PROTECTED]> wrote:
> Tony Godshall wrote:
> > If it was me, I'd have it default to backing off to 95% by default and
> > have options for more aggressive behavior, like the multiple
> > connections, etc.
>
> I don't like a default back-off rule. I often encounter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
(Accidentally sent private reply).
Tony Godshall wrote:
> On 10/17/07, Matthias Vill <[EMAIL PROTECTED]> wrote:
>> Tony Godshall wrote:
>>> If it was me, I'd have it default to backing off to 95% by default and
>>> have options for more aggressive b
On 10/11/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Tony Godshall wrote:
> > On 10/10/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> >> My current impression is that this is a useful addition for some limited
> >> scenarios, but not particularly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> On 10/11/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Tony Godshall wrote:
>>> On 10/10/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
My current impression is that thi
...
> I have, yes. And yes, it's a very small patch. The issue isn't so much
> about the extra code or code maintenance; it's more about extra
> documentation, and avoiding too much clutter of documentation and lists
> of options/rc-commands. I'm not very picky about adding little
> improvements to
On 10/11/07, Tony Godshall <[EMAIL PROTECTED]> wrote:
> ...
> > I have, yes. And yes, it's a very small patch. The issue isn't so much
> > about the extra code or code maintenance; it's more about extra
> > documentation, and avoiding too much clutter of documentation and lists
> > of options/rc-co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> ...
>> I have, yes. And yes, it's a very small patch. The issue isn't so much
>> about the extra code or code maintenance; it's more about extra
>> documentation, and avoiding too much clutter of documentation and lists
>> of o
On Thu, 11 Oct 2007, Micah Cowan wrote:
> It's not really about this option, it's about a class of options. I'm in
> the unenviable position of having to determine whether small patches
> that add options are sufficiently useful to justify the addition of the
> option. Adding one new option/rc com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim Wright wrote:
> On Thu, 11 Oct 2007, Micah Cowan wrote:
>
>> It's not really about this option, it's about a class of options. I'm in
>> the unenviable position of having to determine whether small patches
>> that add options are sufficiently us
I don't want this to spiral down to Micah bashing. He has brought a lot
of good energy to the project, and gotten things moving forward nicely.
Thanks.
I know of instances where this option would be useful for me, and others
have chipped in. I think we all agree it isn't perfect and there is
no
...
> > I guess I'd like to see compile-time options so people could make a
> > tiny version for their embedded system, with most options and all
> > documentation stripped out, and a huge kitchen-sink all-the-bells
> > version and complete documentation for the power user version. I
> > don't thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tony Godshall wrote:
> [Jim]
>> Well, we need the plugin architecture anyway. There are some planned
>> features (JavaScript and MetaLink support being the main ones) that have
>> no business in Wget proper, as far as I'm concerned, but are inarguabl
50 matches
Mail list logo