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 downloads
-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 behavior,
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 this the right thing to
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 unfair
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 operating
-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 after a bit?
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 shared connections.
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 off a little after a
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 running
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 this the right thing to
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 change as new
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. But I
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 be
unobtrusive.
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 back is nicer
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 think you
-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 inarguably
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 is
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 it to
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 really
-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 makes
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 more useful
-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 this is a useful
...
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-commands.
-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
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
-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 useful to
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 with other
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
- --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 organizations.
A
-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 trying
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
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
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 reasonable
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 discovers the
-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 approach
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
-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 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
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 very useful
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.
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 sense
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
-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 users get
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
50 matches
Mail list logo
