120701 Michael Mol wrote:
> It could be a connection duration limit.
> Either the web server or an intermediate proxy server
> may place a limit on how long a connection may be open.
> If you have a low-bandwidth pipe, you'd be more vulnerable
> to hitting that limit than someone with a high-bandwidth pipe.
> Possible sources off the top of my head:
> PHP scripts' script time limits, squid connection time limits.

Yes, the limit is one of time, not of number of bytes transmitted.
My earlier connection stayed open for 32 s & got 819 K ;
one of the other repliers -- thanks to all -- got 38 s & the whole file.

So 2 conclusions for me : (1) yes, servers do impose time-slices ;
(2) my basic problem remains the very low bandwidth I'm getting,
which I have to take up with my ISP once I've clarified other aspects.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Sun, Jul 1, 2012 at 8:26 PM, Philip Webb <purslow@ca.inter.net> wrote:
> 120701 Michael Mol wrote:
>> It could be a connection duration limit.
>> Either the web server or an intermediate proxy server
>> may place a limit on how long a connection may be open.
>> If you have a low-bandwidth pipe, you'd be more vulnerable
>> to hitting that limit than someone with a high-bandwidth pipe.
>> Possible sources off the top of my head:
>> PHP scripts' script time limits, squid connection time limits.
>
> Yes, the limit is one of time, not of number of bytes transmitted.
> My earlier connection stayed open for 32 s & got 819 K ;
> one of the other repliers -- thanks to all -- got 38 s & the whole file.
>
> So 2 conclusions for me : (1) yes, servers do impose time-slices ;
> (2) my basic problem remains the very low bandwidth I'm getting,
> which I have to take up with my ISP once I've clarified other aspects.

There's probably nothing your ISP can do about it, unless you're
talking about upgrading your service.

One thing you might be able to do is pay $5/mo or so for a Linux VM at
some VPS provider, install and configure Squid, and bounce your own
traffic off of it. Squid will pull down the file faster than you, and
won't impose a connection time limit on you. (Unless you configure it
to do so...)

If you do something like that, be sure to properly secure it.

--
:wq

> One thing you might be able to do is pay $5/mo or so for a Linux VM at
> some VPS provider, install and configure Squid, and bounce your own
> traffic off of it. Squid will pull down the file faster than you, and
> won't impose a connection time limit on you. (Unless you configure it
> to do so...)

And you could connect to that squid using an ssh tunnel with
compression enabled at its maximum level. Otherwise the gzip ecap
module https://code.google.com/p/squid-ecap-gzip/ may help a little
but IIRC it only compresses text eg plain, html etc.

120701 Michael Mol wrote:
> On Sun, Jul 1, 2012 at 8:26 PM, Philip Webb <purslow@ca.inter.net> wrote:
>> So 2 conclusions for me : (1) yes, servers do impose time-slices ;
>> (2) my basic problem remains the very low bandwidth I'm getting,
>> which I have to take up with my ISP once I've clarified other aspects.
> There's probably nothing your ISP can do about it,
> unless you're talking about upgrading your service.

The ISP doesn't own the physical wiring, recently upgraded to fibre.
A friend on the opposite side of town using the same ISP
gets 10 times the speed I get ( 5 Mb/s a/a 0,5 Mb/s ),
while the man next-door with the same wiring coming into the building
but using a different ISP gets 12 Mb/s .
My speed was cut in half c 12 mth ago for an unknown reason.
This is downtown Toronto, where I should get a good speed,
so I suspect either some accidental misconfiguration or dirty tricks.

> One thing you might be able to do is pay $5/mo or so
> for a Linux VM at some VPS provider, install and configure Squid
> and bounce your own traffic off of it.
> Squid will pull down the file faster than you
> and won't impose a connection time limit on you.
> If you do something like that, be sure to properly secure it.

Well, the simpler alternative in my case wb to use the UoT service.
I can 'ssh' into a CLI on the CHASS machine, which runs Irix,
then use 'wget' from there with a very fast connection.
Downloading a file from there to here would remain fairly slow,
but it wouldn't be subject to any throttling or slicing.
I tend to forget that resource, however (smile).

Thanks again for the advice & anyone's further thoughts.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

120701 Philip Webb wrote:
> Well, the simpler alternative in my case wb to use the UoT service.
> I can 'ssh' into a CLI on the CHASS machine, which runs Irix,
> then use 'wget' from there with a very fast connection.
> Downloading a file from there to here would remain fairly slow,
> but it wouldn't be subject to any throttling or slicing.

I just did just that. CHASS has a 5 Gb/s Internet connection,
so the whole file ( 25 MB ) arrived before the boom fell after c 39 s .
They don't have Wget (!), but Lynx does the job equally well.
Then I used Fuse to mount the remote dir locally
& downloaded the file to my machine at c 75 KB/s in c 5 min ;
I could have used Krusader instead & got a pretty progress box.

BTW the file is a book mentioned by Carla Schroeder yesterday.
I don't really need it, but it looked interesting.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On 2 July 2012 05:41, Philip Webb <purslow@ca.inter.net> wrote:
> 120701 Philip Webb wrote:
>> Well, the simpler alternative in my case wb to use the UoT service.
>> I can 'ssh' into a CLI on the CHASS machine, which runs Irix,
>> then use 'wget' from there with a very fast connection.
>> Downloading a file from there to here would remain fairly slow,
>> but it wouldn't be subject to any throttling or slicing.
>
> I just did just that. CHASS has a 5 Gb/s Internet connection,
> so the whole file ( 25 MB ) arrived before the boom fell after c 39 s .
> They don't have Wget (!), but Lynx does the job equally well.
> Then I used Fuse to mount the remote dir locally
> & downloaded the file to my machine at c 75 KB/s in c 5 min ;
> I could have used Krusader instead & got a pretty progress box.

Look at this:

$ wget --no-check-certificate -c
http://www.math.wisc.edu/~keisler/keislercalc-2-12.pdf
--2012-07-02 11:17:01-- http://www.math.wisc.edu/~keisler/keislercalc-2-12.pdf
Resolving www.math.wisc.edu... 144.92.166.196
Connecting to www.math.wisc.edu|144.92.166.196|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.math.wisc.edu/formMail/throttle.php?URL=/~keisler/keislercalc-2-12.pdf
[following]
--2012-07-02 11:17:01--
https://www.math.wisc.edu/formMail/throttle.php?URL=/~keisler/keislercalc-2-12.pdf
Connecting to www.math.wisc.edu|144.92.166.196|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 24184097 (23M) [application/pdf]
Saving to: `keislercalc-2-12.pdf'

100%[=====================================>] 24,184,097 130K/s in 2m 50s

2012-07-02 11:19:52 (139 KB/s) - `keislercalc-2-12.pdf' saved
[24184097/24184097]


I managed to download it using a slow connection over 2m 50s, while
the connection was completely uninterrupted. So the 38s threshold
does not seem true, unless ...

I downloaded this behind a corporate gateway, so I don't know if the
slowness of the connection is only up to my gateway, rather than
between the gateway and the Uni server.


If you prefer to use a proxy anyway, you could set up a SOCKS 5 proxy
connection via ssh to the proxy server in question like so:

ssh -ND 12500 user@proxy_server (you don't have to use port 12500,
this is just an example)

then either set up the SOCKS 5 proxy in a browser/ftp client and use
that, or use proxychains. Running:

proxychains kdeinit4

should allow you to run Krusader to download the file without even
having to restart the Krusader application or set up its proxy
configuration.
--
Regards,
Mick