[svlug] suddenly low bandwidth on lan cable

[Ivan Sergio Borgonovo]

On Sun, 19 Dec 2010 16:15:49 -0800
joel williams <joel at emlinux.com> wrote:

> It was not clear if you were able to isolate the problem to the
> LAN or the wan.

> If WAN:
> Not sure about the D-Link 320T specifically but there is a classic 
> problem with
> some of these low end products, including D-Link products; they
> have memory leaks that manifest as slow throughput. What happens,
> is the memory pool (eg: skbufs)
> gets to a low threshold, and you keep recycling the same 2-6 bufs,
> which causes all kinds of problems. For example, the dsl or enet
> chips require a ring buffer
> full of bufs, if there are not enough to go around, then data is
> discarded, hence lost packets.
> Try power cycling the d-link and see if things are better upon
> reboot, and then
> degrade again.

> Also cable changes could "possibly" trigger this problem as
> follows: Amazingly some mis-wired cables may still work, however
> they may auto-negotiate
> to half duplex. A correctly wired may auto-negotiate to
> full-duplex, which changes the timing and hence buffer management
> pathology.

Magically all bandwidth problems with the *long cable*
[router]--[modem] disappeared.
Magically means: I changed the cable and I still got a lot of frame
errors on the eth of the router.
Suddenly all problems disappeared without any intervention.
Maybe it was not the magnetic gun of my neighbourhood but rather the
intermittent lights of his Christmas tree.

I'm not that satisfied since if I don't understand how magically
everything got right it could happen again... but now the *internet
connection* is very slow.

It may be the same problem that made the cable very slow
(maybe neighbourhood turned of the tree but the comet is still on
(?!?!)).

ISP said that physically the line is ok.
Modem says:
Downstream
SNR 17dB Attenuation 14dB
Upstream
SNR 25dB Attenuation 11dB

Downstream SNR doesn't look very good.

> You can get adventurous and dig into this; use wireshark and
> analyze the timing
> between Ethernet frames, re-tries, corrupted packets, etc.
> You will probably see where the problem is occurring.

There is already a long path between me and anything that can reply
something other than icmp (8-9 hops).

This is what I did:
I plugged my notebook directly into the dlink modem. I configured the
modem to take care of PPPoE.
- traceroute and ping delay is reasonable. 50-70ms on all hops.
- When I download something from different servers (some of which
  are reasonably near to me) bandwidth start at ~300KB/s, stay there
  for a fraction of a sec, quickly reach 150KB/s (2-3 sec) and then
  oscillate between 150KB/s and 70KB/sec
wireshark says:
TCP Previous segment lost
TCP Dup ACK 25#1
...
TCP Dup ACK 25#5
TCP Fast Retransmission
TCP Retransmission
...
TCP Window Update
etc...
similar schema no matter which is the server I'm downloading from

From my understanding packets get lost and TCP tune the window
accordingly.

The cable between modem and notebook was pretty short (1.5m) cat5e
and ftp... and I bought it, I didn't make it.
ifconfig didn't report any frame or error problem during the test on
the notebook eth. Dlink 320t runs Linux too and ifconfig didn't
report any frame or error as well.
I don't have tcpdump on the modem.
If I use another modem (Alcatel SpeedTouch Home) on which I don't
have so much control, results are the same.
No errors on any interface I can check, same TCP errors as above.
I couldn't check if there were any errors on the interfaces of the
Alcatel modem.

Is LHC running and pointed in the wrong direction?

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it