C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Choochoo Training Diary

Last 100 entries

Traffic Shaping by VTR

From: "andrew cooke" <andrew@...>

Date: Wed, 16 Jul 2008 19:48:10 -0400 (CLT)

I am trying to upload the patched NVidia CUDA SDK, but my connection is
running so slowly it may take all night.

There's information on VTR (my ISP) here - http://www.neutralidadsi.org

Here are some details, taken from an email I just sent to the (helpful)
guy that runs acooke.org:

----------

hi,

sorry to bother you, but wonder if you had any idea what might be
happening.  i am trying to upload a file to acooke.org and it is extremely
slow (around 10MB an hour).  it's been this way all day and i have noticed
a similar problem with other files the last few days.

looking at the "meter" in sftp there are bursts of normal (ie fast)
downloading, and then the transmissions "stalls".  looking at the tcp
packets, the connection seems to simply disappear - a burst of fast
packets go through, then the system freezes, then after what i assume is a
timeout period (a minute or two - it varies) there's a retransmission,
sometimes some duplicate acks and more retransmissions, and then things
pick up again.

so data get through for maybe 10 seconds, then there's a pause for a
minute or two, then the cycle repeats.  this is quite regular and the
connection never actually fails.

my isp (vtr chile) has a reputation for throttling connections, but there
are no reset packets.  i don't understand things well enough to say more
than that.

tracepath gives the following:
qp6c ~: tracepath acooke.org
 1:  190.160.224.58 (190.160.224.58)                        0.189ms pmtu 1500
 1:  no reply
 2:  no reply
 3:  no reply
 4:  Hurrican-Electric-LLC.TenGigabitEthernet1-4.ar2.SJC2.gblx.net
(64.214.174.246) asymm  7 145.798ms
 5:  10gigabitethernet1-2.core1.fmt2.he.net (72.52.81.177) asymm  8 148.771ms
 6:  acooke.org (72.52.113.196)                           asymm  9
159.615ms !H
     Resume: pmtu 1500

any idea?  has anyone else reported the same thing?  as far as i know i am
dealing with the only high speed internet service in town here, and the
service is terrible.  i will try contacting them tomorrow, but don't
expect to get anywhere.

------------

Andrew

More Evidence

From: "andrew cooke" <andrew@...>

Date: Thu, 17 Jul 2008 06:00:42 -0400 (CLT)

Last night I found that:

- Using sftp from home to acooke.org was slow
- Using sftp from acooke.org to home was fast

So I ssh'ed into acooke.org and pulled files across rather than trying to
send them.  The only differences I can see in the two are:

- The role of client and server are reversed
- acooke.org doesn't use the standard port (22) for ssh

My guess is that VTR decided to limit traffic on non-standard ports.

Also, this morning, thing seem to be working OK again.  While last night
they got progressively worse (by the end it was difficult to type commands
in ssh it was so slow).  My guess there is that this is progressive (as
part of re-doing this site I have been transferring more data than
normal).

In summary, I think that what is happening is that:

- VTR appear to be "traffic shaping"
- They may be leaving standard ports alone
- They appear to progressively degrade performance
- If necessary, using pulling files over FTP is a workaround
  (because either the port or client changes)

We pay for a good (expensive) connection....

I'm going to try looking for a different provider today, but changing
things here is a real hassle (and I think it's a monopoly - there's only
one cable company).

Andrew

Comment on this post