Slow internet speed with cable

I currently dual boot win98 and RedHat 7.1, and connect to my cable modem via a Linksys router. When I use a web browser like netscape, mozilla, or even lynx, pages download extremely slowly (less than 4 k/s) and often stall after loading half a page.

When in windows, web pages and download speeds are normal. Also, I can connect to an ftp server on my lan and download or upload at normal speeds, but not with ftp sites on the internet.

I have not altered my network configuration at all, and use connect to the router using DHCP.

I had a problem with a slow client thru an eepro, may be a driver problem with that and other cards.

I ended up changing it out.

try ifconfig and check for errors.

I'm kinda a newbie, and don't know have a clue as how to troubleshoot a NIC.

If anyone can give me some pointers or point me someplace more indepth your help would be appreciated.

By the way:
The NIC is a Compaq Netelligent 10/100 TX Embedded UTP Controller and uses the tlan.o module. Also, it is labeled in the RedHat supported hardware list as a "second tier", or "Community Knowledge" device, which means that it works (to some extent) but isn't supported by RedHat.

type

ifconfig

press enter

read output


in the line it will have the word errors:0 or something like errors:3789 or something.

then following that is a description of what kind of errors.

Like this


RX packets:3042 errors:0 dropped:0 overruns:0 frame:0
TX packets:2808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:5 Base address:0xdc00

Right after reboot it is clear so you need to transfer data with it and then check.

M.I,

So your routing packets to the Linksys router.
Have you enabled forwarding?

If not then the first packet will get through but the rest will stop, then a resend is requested, so something like Netscape will keep adding the packets to the cache from each new requests to make the page. "very very slowly + stalls"

type:
echo 1 > /proc/sys/net/ipv4/ip_forward

See if that fixes it.
/raz

Raz,

How come the first packet still gets through even though forwarding it disabled? Is this a standard routing thing or a *nix querk? My routing knowledge can be summerised by the two lines needed (well 1 needed, 1 advisory!) to enable NAT under 2.2.x...

cheers

Jamie...

No idea why but if you try to ping something without the option "in 7.1" the first packet gets a response the rest fail.

Same goes for tcp.

I think it's a bug of some sort.
try it.

/raz

I've tried typing "ifconfig", but the command isn't found.

Also, I do appear to be recieving packets beyond the first.

Make sure your logged in as root.
Then type
#/sbin/ifconfig -a

Post the results to us.

Also do a ping on this address and see what happens with this command.
Also post all the results to us.

Also what area of the world are you in ?
"It will help us to work out what's happening from the ping results"

type:
#ping -c 10 -v -p ff -s 9032 32.96.111.2
send us results

Now type:
#ping -f -c 200 -s 1024 32.96.111.2
send us results

Don't type the last ping command more then once, or men in black suits will be knocking on your door. 8-)
"Can anyone guess what the IP address is?"

/Raz

Here are the results of ifconfig:

eth0 Link encap:Ethernet HWaddr 00:80:5F3:40:C4
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:36 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0x1420

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0


Now for the ping results. I'm pinging from New Jersey, USA.


#ping -c 10 -v -p ff -s 9032 32.96.111.2

PATTERN: 0xff
PING 32.96.111.2 (32.96.111.2) from 192.168.1.100 : 9032(9060) bytes of data.
9040 bytes from 32.96.111.2: icmp_seq=0 ttl=242 time=1.074 sec
9040 bytes from 32.96.111.2: icmp_seq=1 ttl=242 time=1.019 sec
9040 bytes from 32.96.111.2: icmp_seq=2 ttl=242 time=989.863 msec
9040 bytes from 32.96.111.2: icmp_seq=3 ttl=242 time=1.229 sec
9040 bytes from 32.96.111.2: icmp_seq=4 ttl=242 time=1.029 sec
9040 bytes from 32.96.111.2: icmp_seq=5 ttl=242 time=709.434 msec
9040 bytes from 32.96.111.2: icmp_seq=6 ttl=242 time=619.876 msec
9040 bytes from 32.96.111.2: icmp_seq=7 ttl=242 time=1.029 sec
9040 bytes from 32.96.111.2: icmp_seq=8 ttl=242 time=1.098 sec
9040 bytes from 32.96.111.2: icmp_seq=9 ttl=242 time=1.089 sec

--- 32.96.111.2 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/mdev = 619.876/989.127/1229.538/174.954 ms


#ping -f -c 200 -s 1024 32.96.111.2

PING 32.96.111.2 (32.96.111.2) from 192.168.1.100 : 1024(1052) bytes of data.
--- 32.96.111.2 ping statistics ---
874 packets transmitted, 200 packets received, 77% packet loss
round-trip min/avg/max/mdev = 82.572/3089.459/4660.067/1005.898 ms

ok good.

It looks like your ISP is very slow on latency times.
I'm in London and I get 400ms avg connection time, yours is close to 1sec. "+ your only 13 hops and I'm 18 from that 32* server"

Second ping show me the ISP's routers are timing out as too many of your pings get stopped due to latency speed again.

Also I hope that address of 192.168.1.100 is fake as your Linux box shouldn't work on an internal IP IANA range.

Ok so now you'll need to find out where your ISP is slowing down your connection.

type:
traceroute -I 32.96.111.2

post results to us again.

ok now go to this site and run the speed test and cut and past the results to us again.
http://www.dslreports.com/stest?loc=1

It looks like your ISP has some major overload issues in your area.
I believe the contention ratio is much higher with cable so too many people might be connected to the same backbone.

If this is the case you are limited in options on what to do, we will discuss this once I've viewed the new data.

/Raz

Here are the trace route results:
traceroute to 192.168.1.8 (192.168.1.8), 30 hops max, 38 byte packets
1 192.168.1.8 (192.168.1.8) 4.562 ms 0.468 ms 0.683 ms
[root@localhost sbin]# /usr/sbin/traceroute -I 32.96.111.2
traceroute to 32.96.111.2 (32.96.111.2), 30 hops max, 38 byte packets
1 65.2.222.1 (65.2.222.1) 326.214 ms 137.619 ms 77.432 ms
2 bb1-fe4-4-100bt.rdc1.nj.home.net (24.3.144.1) 24.660 ms 26.579 ms 90.192 ms
3 c1-pos4-1.nwrknj1.home.net (24.7.75.173) 28.445 ms 59.602 ms 45.926 ms
4 c1-pos5-0.cmdnnj1.home.net (24.7.65.233) 61.051 ms 94.468 ms 104.858 ms
5 c1-pos1-0.washdc1.home.net (24.7.65.85) 63.992 ms 82.365 ms 59.156 ms
6 home-gw.wswdc.ip.att.net (192.205.32.253) 39.263 ms 57.245 ms 104.585 ms
7 gbr3-p50.wswdc.ip.att.net (12.123.9.50) 41.413 ms 70.292 ms 130.927 ms
8 gbr3-p40.sl9mo.ip.att.net (12.122.2.82) 87.050 ms 91.122 ms 38.952 ms
9 gbr1-p100.sl9mo.ip.att.net (12.122.1.210) 116.102 ms 62.290 ms 53.944 ms
10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 65.815 ms 99.925 ms 120.020 ms11 12.125.75.18 (12.125.75.18) 115.186 ms 123.606 ms 72.526 ms
12 32.96.111.2 (32.96.111.2) 72.265 ms 108.723 ms 50.965 ms


Also for a comparison here are windows tracert results:
Tracing route to 32.96.111.2 over a maximum of 30 hops

1 85 ms 120 ms 100 ms 65.2.222.1
2 49 ms 118 ms 96 ms bb1-fe4-4-100bt.rdc1.nj.home.net [24.3.144.1]
3 38 ms 48 ms 26 ms c1-pos4-1.nwrknj1.home.net [24.7.75.173]
4 90 ms 70 ms 40 ms c1-pos5-0.cmdnnj1.home.net [24.7.65.233]
5 72 ms 61 ms 46 ms c1-pos1-0.washdc1.home.net [24.7.65.85]
6 100 ms 117 ms 106 ms home-gw.wswdc.ip.att.net [192.205.32.253]
7 140 ms 66 ms 49 ms gbr3-p50.wswdc.ip.att.net [12.123.9.50]
8 95 ms 76 ms 40 ms gbr3-p40.sl9mo.ip.att.net [12.122.2.82]
9 134 ms 704 ms 92 ms gbr1-p100.sl9mo.ip.att.net [12.122.1.210]
10 208 ms 112 ms 104 ms gar1-p360.sl9mo.ip.att.net [12.123.24.209]
11 624 ms 116 ms 166 ms 12.125.75.18
12 138 ms 70 ms 115 ms 32.96.111.2

Trace complete.


Here are the speed test results in linux, except using the eastcoast server (which happens to be in NJ, where I live) because the westcoast server was busy.

traceroute to 192.168.1.8 (192.168.1.8), 30 hops max, 38 byte packets
1 192.168.1.8 (192.168.1.8) 4.562 ms 0.468 ms 0.683 ms
[root@localhost sbin]# /usr/sbin/traceroute -I 32.96.111.2
traceroute to 32.96.111.2 (32.96.111.2), 30 hops max, 38 byte packets
1 65.2.222.1 (65.2.222.1) 326.214 ms 137.619 ms 77.432 ms
2 bb1-fe4-4-100bt.rdc1.nj.home.net (24.3.144.1) 24.660 ms 26.579 ms 90.192 ms
3 c1-pos4-1.nwrknj1.home.net (24.7.75.173) 28.445 ms 59.602 ms 45.926 ms
4 c1-pos5-0.cmdnnj1.home.net (24.7.65.233) 61.051 ms 94.468 ms 104.858 ms
5 c1-pos1-0.washdc1.home.net (24.7.65.85) 63.992 ms 82.365 ms 59.156 ms
6 home-gw.wswdc.ip.att.net (192.205.32.253) 39.263 ms 57.245 ms 104.585 ms
7 gbr3-p50.wswdc.ip.att.net (12.123.9.50) 41.413 ms 70.292 ms 130.927 ms
8 gbr3-p40.sl9mo.ip.att.net (12.122.2.82) 87.050 ms 91.122 ms 38.952 ms
9 gbr1-p100.sl9mo.ip.att.net (12.122.1.210) 116.102 ms 62.290 ms 53.944 ms
10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 65.815 ms 99.925 ms 120.020 ms11 12.125.75.18 (12.125.75.18) 115.186 ms 123.606 ms 72.526 ms
12 32.96.111.2 (32.96.111.2) 72.265 ms 108.723 ms 50.965 ms

These results seem ok. The only difference besides time between the earlier ping tests and these is that the second computer connected to the router was off, which runs win2k and was downloading at the time. When the win2k box is downloading, etc. I still get normal download speeds while in windows.

As for my ISP, Comcast @home, it is spread fairly thin in my area because of a large increase in demand recently. I can still get O.K. download speeds but my upload speeds are capped to something way below 100 k/s.

About the IP address of this box, (192.168.1.100) this is what the router assigns by default when using DHCP. Is this a problem?

Suggestions Razbot and David are good starting point to diagnose the slowness observed from the original poster - (M.I. newbie?). But I have a different opinion - I don't think the slowness was caused by ISP, even though it is possible, if indeed they have such slow network performance, they'll go out of business very soon. Since M.I. was getting 'normal' speed with Win98, and only the Linux was slow, I think the cause was not a latency issue on the ISP side, but configuration problem on the Linksys or Linux box.

I could think of three possibilities causing the slowness and ping response.
1. Your Linksys router/hub was not properly configured.
2. wrong or improper routing table on Linux, to check, type
#/sbin/route -n
3. DNS server was not properly configured. This does not explain slowness with ping, but can cause slowness with browsing if you not have the default DNS server entered. Type and post also: cat /etc/resolve.conf

Good luck.

LionKing may be right, I didn't notice you said the windows box is ok.

Anyway this is how I see it from the linux box.

From the traceroute your first @home router is not responding well to it.
1 65.2.222.1 (65.2.222.1) 326.214 ms 137.619 ms 77.432 ms

It's way way too high, considering it's on the same backbone as your connection. "should be more like 20-30ms"

Looking at your ISP's cable info, it looks like your cable is capped to 128k/bs upload "i.e going from your system to the internet"
So from my calculation your upload speed will never be higher then 14K per second. "what does the speed test say it is"

x = kps (128 kilobaud)
y = bytes in a bit (8)
z = over head from ATM and TCP/PI relays (10% & 3%)
x \ y \ z = K

K = 14kbit per second.

The next step is to see if you can make some changes to increase the TCP packets window sizing and other TCP settings "nothing to do with MS windows" On the linux box type the commands below.

sysctl -w net.ipv4.tcp_max_syn_backlog=256
sysctl -w net.ipv4.vs.timeout_established=9600
sysctl -w net.ipv4.tcp_syn_retries=5
sysctl -w net.ipv4.vs.timeout_synack=60
sysctl -w net.ipv4.route.mtu_expires=512
sysctl -w net.ipv4.tcp_keepalive_time=7600
sysctl -w net.ipv4.tcp_fin_timeout=360
sysctl -w net.ipv4.tcp_rfc1337=1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 262144 > /proc/sys/net/core/rmem_default
echo 262144 > /proc/sys/net/core/rmem_max
echo 262144 > /proc/sys/net/core/wmem_default
echo 262144 > /proc/sys/net/core/wmem_max

The next step is to see what the routing table is trying to do.
type:
#netstat -rn
post results to us.

Now type this:
#netstat -s
Post results to us.

Also look in the log files for any errors that keep repeating in /var/log/messages

Don't worry about that IP address, I though you were doing NAT but it looks like your router is doing that for you.

/raz

Here are the results of netstat -rn. The table made didn't survive copying and pasting, so this is the table vertically.

Destination
192.168.1.0
127.0.0.0
0.0.0.0

Gateway
0.0.0.0
0.0.0.0
192.168.1.1

Genmask
255.255.255.0
255.0.0.0
0.0.0.0

Flags
U
U
UG

MSS Window
40 0
40 0
40 0

irtt Iface
0 eth0
0 lo
0 eth0

And netstat -s:
Ip:
192 total packets received
0 forwarded
0 incoming packets discarded
183 incoming packets delivered
228 requests sent out
Icmp:
1 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 1
2 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 2
Tcp:
21 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
162 segments received
204 segments send out
4 segments retransmited
0 bad segments received.
0 resets sent
Udp:
18 packets received
1 packets to unknown port received.
0 packet receive errors
22 packets sent
TcpExt:
TW: 6
TWRecycled: 0
TWKilled: 0
PAWSPassive: 0
PAWSActive: 0
PAWSEstab: 0
DelayedACKs: 23
DelayedACKLocked: 0
DelayedACKLost: 1
ListenOverflows: 0
ListenDrops: 0
TCPPrequeued: 0
TCPDirectCopyFromBacklog: 0
TCPDirectCopyFromPrequeue: 0
TCPPrequeueDropped: 0
TCPHPHits: 31
TCPHPHitsToUser: 0
TCPPureAcks: 22
TCPHPAcks: 9
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 4
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 0
TCPDSACKOldSent: 1
TCPDSACKOfoSent: 0
TCPDSACKRecv: 0
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 0
TCPAbortOnClose: 2
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 0
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0