Define this network behavior

I might be pushing it by asking you all to do this again, yet tonight I've actually got a problem with my connection and I would like to learn how to diagnose it. I've got terrible internet performance right now. My download speeds are testing okay, yet my upload speeds are practically non existent.

Here:



+XXXX:~ XXXX$ netstat -an+
+Active Internet connections (including servers)+
+Proto Recv-Q Send-Q Local Address Foreign Address (state)+
+tcp4 0 0 192.168.1.140.49682 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49681 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49669 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49668 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49667 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49666 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49665 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49645 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49634 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49633 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49632 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49631 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49630 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49629 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49624 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49623 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49622 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49621 209.123.109.176.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49620 209.123.109.175.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49619 64.17.248.2.9091 LAST_ACK+
+tcp4 0 0 192.168.1.140.49616 69.17.117.207.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49615 72.21.81.132.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49614 69.17.117.207.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49613 69.17.117.207.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49612 69.17.117.207.80 LAST_ACK+
+tcp4 0 0 192.168.1.140.49611 69.17.117.207.80 LAST_ACK+
+tcp4 0 0 127.0.0.1.8118 . LISTEN+
+tcp4 0 0 127.0.0.1.631 . LISTEN+
+tcp6 0 0 ::1.631 . LISTEN+
+udp4 0 0 192.168.1.140.123 .+
+udp6 0 0 fe80::21b:63ff:f.123 .+
+udp4 0 0 . .+
+udp4 0 0 *.62566 .+
+udp4 0 0 *.62116 .+
+udp4 0 0 *.55130 .+
+udp4 0 0 *.51734 .+
+udp4 0 0 *.55745 .+
+udp4 0 0 *.52275 .+
+udp6 0 0 ::1.123 .+
+udp4 0 0 127.0.0.1.123 .+
+udp6 0 0 fe80::1%lo0.123 .+
+udp6 0 0 *.123 .+
+udp4 0 0 *.123 .+
+udp6 0 0 *.5353 .+
+udp4 0 0 *.5353 .+
+udp4 0 0 . .+
+udp4 0 0 . .+
+icm6 0 0 . .+
+Active LOCAL (UNIX) domain sockets+
+Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr+
+72c7908 stream 0 0 0 72c76e8 0 0 /var/run/asl_input+
+72c76e8 stream 0 0 0 72c7908 0 0+
+6def550 stream 0 0 0 6def5d8 0 0+
+6def5d8 stream 0 0 0 6def550 0 0+
+72c75d8 stream 0 0 0 72c7550 0 0+
+72c7550 stream 0 0 0 72c75d8 0 0+
+72e8660 stream 0 0 0 72e86e8 0 0 /var/run/mDNSResponder+
+72e86e8 stream 0 0 0 72e8660 0 0+
+72e8b28 stream 0 0 0 72e8d48 0 0+
+72e8d48 stream 0 0 0 72e8b28 0 0+
+72e8a18 stream 0 0 0 72e8880 0 0+
+72e8880 stream 0 0 0 72e8a18 0 0+
+72e8bb0 stream 0 0 0 72e8990 0 0+
+72e8990 stream 0 0 0 72e8bb0 0 0+
+6def4c8 stream 0 0 797c3b0 0 0 0 /tmp/launch-13cXyc/:0+
+72c7a18 stream 0 0 797c4d0 0 0 0 /tmp/launch-I2RYDv/Listeners+
+72c7aa0 stream 0 0 797c5f0 0 0 0 /tmp/launch-xD2Ort/Render+
+72c7990 stream 0 0 797c710 0 0 0 /private/tmp/com.hp.launchport+
+6def3b8 stream 0 0 797c9e0 0 0 0 /tmp/launchd-98.MDzO8S/sock+
+72b0088 stream 0 0 0 0 0 0+
+72c7d48 stream 0 0 0 72c7198 0 0+
+72c7198 stream 0 0 0 72c7d48 0 0+
+72e8dd0 stream 0 0 0 72c72a8 0 0+
+72c72a8 stream 0 0 0 72e8dd0 0 0+
+72c7330 stream 0 0 750d290 0 0 0 /var/run/pppconfd+
+72c7220 stream 0 0 0 72c7ee0 0 0+
+72c7ee0 stream 0 0 0 72c7220 0 0+
+72c7000 stream 0 0 0 72c7cc0 0 0+
+72c7cc0 stream 0 0 0 72c7000 0 0+
+72c7440 stream 0 0 0 72b0660 0 0+
+72b0660 stream 0 0 0 72c7440 0 0+
+72c7770 stream 0 0 0 72c77f8 0 0+
+72c77f8 stream 0 0 0 72c7770 0 0+
+72c7bb0 stream 0 0 0 72c7c38 0 0+
+72c7c38 stream 0 0 0 72c7bb0 0 0+
+72c7dd0 stream 0 0 0 72c7e58 0 0+
+72c7e58 stream 0 0 0 72c7dd0 0 0+
+72b0330 stream 0 0 0 72b03b8 0 0+
+72b03b8 stream 0 0 0 72b0330 0 0+
+72b0550 stream 0 0 0 72b05d8 0 0+
+72b05d8 stream 0 0 0 72b0550 0 0+
+72b0aa0 stream 0 0 0 72b0b28 0 0+
+72b0b28 stream 0 0 0 72b0aa0 0 0+
+72b0ee0 stream 0 0 0 72b0f68 0 0+
+72b0f68 stream 0 0 0 72b0ee0 0 0+
+6def7f8 stream 0 0 0 6def770 0 0+
+6def770 stream 0 0 0 6def7f8 0 0+
+6def880 stream 0 0 0 6def990 0 0+
+6def990 stream 0 0 0 6def880 0 0+
+6defa18 stream 0 0 0 6defaa0 0 0+
+6defaa0 stream 0 0 0 6defa18 0 0+
+6defc38 stream 0 0 6eef9a0 0 0 0 /var/tmp/launchd/sock+
+6defcc0 stream 0 0 6eefac0 0 0 0 /private/var/run/cupsd+
+6defd48 stream 0 0 6eefbe0 0 0 0 /var/run/usbmuxd+
+6defe58 stream 0 0 6eefd00 0 0 0 /var/run/asl_input+
+6deff68 stream 0 0 6eefd90 0 0 0 /var/run/portmap.socket+
+6defee0 stream 0 0 6eefe20 0 0 0 /var/run/mDNSResponder+
+72b0990 dgram 0 0 0 6def440 6def440 0+
+6def440 dgram 0 0 0 72b0990 72b0990 0+
+6def088 dgram 0 0 0 6defdd0 0 72e8908+
+72e8330 dgram 0 0 0 72e83b8 72e83b8 0+
+72e83b8 dgram 0 0 0 72e8330 72e8330 0+
+72e8770 dgram 0 0 0 72e8c38 72e8c38 0+
+72e8c38 dgram 0 0 0 72e8770 72e8770 0+
+72e8908 dgram 0 0 0 6defdd0 0 6def2a8+
+6def2a8 dgram 0 0 0 6defdd0 0 72b0cc0+
+72b0cc0 dgram 0 0 0 6defdd0 0 72b07f8+
+72b07f8 dgram 0 0 0 6defdd0 0 72c7b28+
+6def330 dgram 0 0 0 72b0dd0 72b0dd0 0+
+72b0dd0 dgram 0 0 0 6def330 6def330 0+
+72c73b8 dgram 0 0 0 72b0000 72b0000 0+
+72b0000 dgram 0 0 0 72c73b8 72c73b8 0+
+72c7b28 dgram 0 0 0 6defdd0 0 72c7110+
+72e8e58 dgram 0 0 0 72c7880 72c7880 0+
+72c7880 dgram 0 0 0 72e8e58 72e8e58 0+
+72c7110 dgram 0 0 0 6defdd0 0 72b0220+
+72b0220 dgram 0 0 0 6defdd0 0 72c7660+
+72c7660 dgram 0 0 0 6defdd0 0 6def908+
+6def000 dgram 0 0 0 72b0770 72b0770 0+
+72b0770 dgram 0 0 0 6def000 6def000 0+
+6def908 dgram 0 0 0 6defdd0 0 0+
+6defdd0 dgram 0 0 6eefc70 0 6def088 0 /var/run/syslog+




+traceroute to google.com (74.125.67.100), 64 hops max, 40 byte packets+
+1 192.168.1.1 (192.168.1.1) 1.214 ms 0.645 ms 0.644 ms+
+2 cpe-XXXX.socal.res.rr.com (XXXX) 12.398 ms 12.340 ms 13.567 ms+
+3 24.24.193.145 (24.24.193.145) 12.081 ms 13.484 ms 13.352 ms+
+4 ae5-chswca1-rtr2.socal.rr.com (66.75.145.28) 12.910 ms 12.663 ms 12.516 ms+
+5 ge-4-3-0.tustca1-rtr1.socal.rr.com (66.75.145.13) 15.811 ms 16.032 ms 15.716 ms+
+6 ae-5-0.cr0.lax30.tbone.rr.com (66.109.6.64) 17.547 ms 21.262 ms 18.942 ms+
+7 ae-1-0.pr0.lax10.tbone.rr.com (66.109.6.131) 17.613 ms 18.363 ms 16.087 ms+
+8 * 72.14.198.73 (72.14.198.73) 17.566 ms 17.487 ms+
+9 216.239.46.180 (216.239.46.180) 16.054 ms 19.095 ms 18.926 ms+
+10 216.239.43.125 (216.239.43.125) 129.653 ms 87.414 ms 89.570 ms+
+11 72.14.239.131 (72.14.239.131) 89.523 ms * 72.14.239.127 (72.14.239.127) 89.661 ms+
+12 209.85.255.194 (209.85.255.194) 99.546 ms 88.207 ms 89.630 ms+
+13 * * *+
+14 * * *+

DaddyPaycheck wrote:
Have you tried a new Ethernet cable?

Are you serious? What would changing out the cable do?

I recently had my house professionally wired for ethernet. Changing the cables would not be an easy task.

My apologies, I thought that you were trying to troubleshoot a problem. Often it is the simplest thing that causes the greatest concern.

I am trying to troubleshoot a problem. I was not being flippant in my response to your advise. If it actually might help me to isolate the issue, then it's worth it for me to run a temporary cable to check and see.

I didn't get the logic until now. Doh. Of course it makes since to run a test directly, maybe even taking the router out of the mix and running directly into the modem. And also running a test from other systems on the local network. I'll give it a try.

Have you had odd behavior since the rewire or is this newer than that?

I believe I've encountered upload related bandwidth problems before the rewire.

Message was edited by: pianoman1976

Could someone tell me what the two and sometimes three "ms" numbers are after each hop on the traceroute? I know these numbers represent the timing of the hop in milliseconds, yet I'm wondering why there is not just one ms measurement. Does the traceroute hit each hop multiple times and reflect a number for each hit?

Also, what is considered "normal" when it comes to these ms timing results? During times such as now when I'm encountering persistent upload bandwidth problems, but no download bandwidth problems - would this be reflected on a traceroute, or not?

I have found that every time I talk to the IT help desk at Road Runner they are always having me running traceroutes. I would like to know more about it so that I can do more of this type of diagnostic work on my own before having to call for help.

+traceroute to google.com (74.125.67.100), 64 hops max, 40 byte packets+
+1 192.168.1.1 (192.168.1.1) 1.696 ms 3.067 ms 0.681 ms+
+2 cpe-76-95-80-1.socal.res.rr.com (76.95.80.1) 14.739 ms 13.414 ms 11.610 ms+
+3 24.24.193.145 (24.24.193.145) 10.805 ms 12.279 ms 25.639 ms+
+4 ae5-chswca1-rtr2.socal.rr.com (66.75.145.28) 13.530 ms * 13.437 ms+
+5 ge-4-3-0.tustca1-rtr1.socal.rr.com (66.75.145.13) 15.420 ms * 14.944 ms+
+6 ae-5-0.cr0.lax30.tbone.rr.com (66.109.6.64) 15.826 ms 13.132 ms 16.781 ms+
+7 * ae-1-0.pr0.lax10.tbone.rr.com (66.109.6.131) 17.994 ms 17.375 ms+
+8 * 72.14.198.73 (72.14.198.73) 16.947 ms 17.989 ms+
+9 * 216.239.46.180 (216.239.46.180) 17.638 ms 16.526 ms+
+10 216.239.43.125 (216.239.43.125) 89.460 ms 89.369 ms *+
+11 72.14.239.131 (72.14.239.131) 87.910 ms 72.14.239.127 (72.14.239.127) 88.024 ms 86.270 ms+
+12 209.85.255.194 (209.85.255.194) 93.788 ms 98.438 ms 90.265 ms+
+13 * *+

Message was edited by: pianoman1976

DaddyPaycheck wrote:
Right. Always break things down to the most basic setup first, and if that works, go backwards from there.

I took my entire local network and disconnected it from my cable internet provider and hooked it up to my satellite internet provider and everything runs fine.

So the problem seems to be related to my cable provider. I took a Mac and connected it directly to the cable modem, and did the same with an XP system. In both instances I was still having the same upload bandwidth issue.

Have you contacted your isp?

Oh yes. It's been some time since I've had this problem, yet I've had it quite frequently.

I've spent countless hours on the phone with upper tier techs at Road Runner. We always run a bunch of traceroutes and there never seems to be any idea as to why and where I'm having a problem. They always verify that indeed there is a problem though.

The last time I spoke to them, I was told to bring my modem in for an exchange. To me this seemed to sound like a stab in the dark, yet it looks like I'll have to give it a try before I call back.

I thought maybe this time around I could learn a bit more about it myself. I guess netstat and traceroutes aren't as useful as I had thought when it comes to this kind of thing.

Message was edited by: pianoman1976