On Fri, 2 Dec 2011, Daniel Stenberg wrote:
I may be wrong, but I thought that to get significant benefit large windows
had to be enabled on every router between the source and destination, which
I did not think was the case on the public Internet.
Not exactly, but in firewalls and NATs or
On Thu, 1 Dec 2011, Andrew Daviel wrote:
First off, this early conclusion is incorrect. RTT has basically no impact
on an ongoing TCP transfer these days since they introduced large windows
for like a decade ago.
I may be wrong, but I thought that to get significant benefit large windows
On Wed, 30 Nov 2011, Daniel Stenberg wrote:
On Wed, 30 Nov 2011, Fernando Cassia wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
First off, this early
another command line option possibly?
Paul
2011/11/30 Andrew Daviel ad...@triumf.ca:
On Sat, 26 Nov 2011, Ángel González wrote:
On 10/11/11 03:24, Andrew Daviel wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is
2011/11/29 Andrew Daviel ad...@triumf.ca:
but I became recently aware of download accelerators designed primarily to
thwart bandwidth allocation/throttling. Interestingly Wget is listed on the
Wikipedia page as a download manager, implying it can already do this.
On Wed, Nov 9, 2011 at 23:24, Andrew Daviel ad...@triumf.ca wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
Which is why large files should be stored on FTP
unfortunately there are now a lot of services offered where ftp access
is not provided, or not available, or even blocked. About 90% of the
servers I mirror fit into this category
On Thu, Dec 1, 2011 at 6:43 AM, Fernando Cassia fcas...@gmail.com wrote:
On Wed, Nov 9, 2011 at 23:24, Andrew Daviel
On Wed, 30 Nov 2011, Fernando Cassia wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
First off, this early conclusion is incorrect. RTT has basically no
On Sat, 26 Nov 2011, Ángel González wrote:
On 10/11/11 03:24, Andrew Daviel wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
Using the range header in
On 10/11/11 03:24, Andrew Daviel wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
In the past tools such as bbftp have mitigated this effect by using
multiple
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
In the past tools such as bbftp have mitigated this effect by using
multiple streams, but required both a special
11 matches
Mail list logo
