









|
[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[NMLUG] speaking of Comcast... saturated upload kills connection
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| I have been looking into this problem for some time now and have tested
| it using about 5 different modems+connections+configurations. When you
| upload some place with higher download than you, 75-99% of packets are
| lost to or from any other connections. Same thing happens, of course,
| when someone downloads from you with a higher speed than your upload. I
| have used ftp, ssh and http to transfer files. Im using ping from a
| third host to verify the packet loss. Example: If a friend is
| downloading files from my computer I have to kill their transfer to get
| back on irc, check mail etc. If I am away I have to wait, for however
| long, to ssh in. Its that bad and its not just me.
|
| Comcast has sent people out 3 times. They test signal strength and the
| modem and make a bunch of calls and tells me its my internal networks
| fault. In other words they are not responsible for anything but the
| modem... so naturally. No one has a clue:-( They put me in contact with
| the manager and he had to clue what I was even saying, so he asked if I
| would write up some details. I haven't heard back. I think it must be an
| inherent problem, being a shared network. They insist this is not the
| case and they have NEVER seen it before. Has anyone else seen this
| problem? If you have cable give it a try and let me and, more
| importantly, comcast know what you find.
|
| Jason
|
| _______________________________________________
| NMLUG mailing list
| NMLUG@nmlug.org
| http://www.nmlug.org/mailman/listinfo/nmlug
I'm not a Comcast customer nor am I an admin over there, but I think you
guys are just seeing something thats designed. IIRC, Comcast ratelimits
peoples' upstream to far lower than their downstream connectivity. Is
this the case? I'm pretty sure Cox does that too.
Depending on what solution they use to do this ratelimiting, the packet
loss may be a symptom of that. You mentioned that you used ping to test
for packet loss, but bear in mind that ping is icmp, not tcp, and they
may not have a very high priority on icmp...That's just a thought.
If you are interested in learning how to saturate your link and still be
able to use interactive (ssh, etc.) traffic...Or saturate your link and
still play games over it, then look into traffic shaping. IOW, if you
want to bulk download and have low latency, then look into this stuff.
lartc.org is the place to start, but be forewarned...It's complicated.
There's a script on there called the wondershaper that pretty much does
everything for you and is good enough for most people. You'll need to
patch and recompile your kernel, and probably patch iptables, and
probably patch your iproute2 package, but it's worth it.
All I know is, trafficshaping works. I can saturate a 3mbit wireless
link and get ~30ms of ping across that link with the correct settings.
Without, that latency jumps to however big the smallest queue is (mine
or the ISP), which ends up being about 300ms.
- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAw486nURHNoE9YE4RAn+gAJ9JKmFx4wMExhq6yLXwKb01+bndugCfXDIH
ckgxlEtKsppuxibq94HQkwY=
=p/0y
-----END PGP SIGNATURE-----
|
|