Packet loss seems to have increased, how to diagnose?

Discussion in 'Broadband' started by cl, Mar 22, 2015.

  1. cl

    cl Guest

    My son and I both felt recently that "the internet seemed a bit slow".

    I finally took a harder look at things just now and we seem to be
    getting rather more packet loss than seems reasonable, typical is this
    sort of ping response:-

    chris$ ping cheddar.halon.org.uk
    PING cheddar.halon.org.uk (217.10.144.130) 56(84) bytes of data.
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=5 ttl=48 time=35.8 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=6 ttl=48 time=33.5 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=7 ttl=48 time=34.6 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=8 ttl=48 time=34.1 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=9 ttl=48 time=33.9 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=10 ttl=48 time=37.3 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=12 ttl=48 time=35.0 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=14 ttl=48 time=34.1 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=15 ttl=48 time=40.3 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=16 ttl=48 time=34.2 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=17 ttl=48 time=35.9 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=18 ttl=48 time=34.4 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=19 ttl=48 time=33.6 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=20 ttl=48 time=34.4 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=21 ttl=48 time=34.6 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=22 ttl=48 time=33.9 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=24 ttl=48 time=35.8 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=25 ttl=48 time=34.6 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=26 ttl=48 time=34.7 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=28 ttl=48 time=34.5 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=29 ttl=48 time=37.8 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=30 ttl=48 time=34.8 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=31 ttl=48 time=33.6 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=32 ttl=48 time=34.2 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=33 ttl=48 time=34.4 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=36 ttl=48 time=33.8 ms
    64 bytes from cheddar.halon.org.uk (217.10.144.130): icmp_seq=37 ttl=48 time=35.9 ms
    ^C
    --- cheddar.halon.org.uk ping statistics ---
    37 packets transmitted, 27 received, 27% packet loss, time 36095ms
    rtt min/avg/max/mdev = 33.593/34.998/40.325/1.477 ms

    It seems to take a long time to even start and then loses packets on a
    pretty regular basis. I'm sure it used to be better than this.

    The ADSL router is a Draytek Vigor 2820n and it's reporting:-

    ADSL Information ( ADSL Firmware Version: 232201_A)
    TX Cells RX Cells TX CRC errs RX CRC errs
    14948715 220326963 1056 27764

    Mode State Up Speed Down Speed SNR Margin Loop Att.
    G.DMT SHOWTIME 448000 4032000 11 48


    So, is my phone line getting noisy or is there something else amiss?
     
    cl, Mar 22, 2015
    #1
    1. Advertisements

  2. cl

    cl Guest

    Well a disconnect/reconnect of the 2820n to the phone line seems to
    have fixed it. It's renegotiated its speed up a bit too. :)
     
    cl, Mar 22, 2015
    #2
    1. Advertisements

  3. cl

    Graham J Guest

    Sadly, re-syncing the ADSL modem or rebooting the router will cure a lot
    of things, but then you never know why the problem occurred in the first
    place.

    As regards ping, the first IP address to try would be the Default
    Gateway shown in the router. On a 2820n this is called GW IP, in the
    WAN1 Status section.

    This is the first router in the chain between you and the rest of the
    internet, and is generally operated by your ISP. If pinging it is
    unreliable then you should take it up with your ISP. However be sure
    that you don't have other network traffic using some of the available
    bandwidth - this may delay ping responses (by design, ping has a very
    low priority). The 2820 will show you a traffic graph to allow you to
    identify whether there is any other usage.

    If this is reliable, but other addresses (such as www.bbc.co.uk) are
    not, then it's an issue for your ISP. Try several different addresses
    from services that likely to have high availability.

    Your 11dB SNR margin is not ideal. Having rebooted, what is it now?

    If you reboot the router the TX/RX cell count, and TX/RX CRC error
    counts should all reset to zero. Note the counts, and work out the
    error rate as a proportion of the total packets. Yours look acceptably
    low (1 in 10^4 and 1 in 10^5) but beware that all the counters wrap and
    I don't know at how many digits). So monitor every few hours.

    Also note whether the error counts increase smoothly, or stay fairly
    static and increase rapidly on occasion. RouterStats would help here,
    but I don't know how to make it work with a 2820. I think I had it
    working with a 2800, and certainly with a 2600. Any sudden increase in
    error counts would indicate an intermittent noise problem.

    If the noise margin increases and the speed consequently decreases your
    BRAS profile will reduce, and may take some time to return to its
    previously good figure. With some ISPs (BT, Demon) this never happens
    and you have to threaten to migrate away to get them to reset it. The
    perceived speed will stay slow until the BRAS profile returns to its
    former good value. Does your ISP give you a mechanism to see the BRAS
    profile?
     
    Graham J, Mar 23, 2015
    #3
  4. cl

    cl Guest

    Yes, I know, but still I do at least now have a responsive internet
    connection. Next time, if I have the patience, I may try a bit more
    diagnosis (if there is a next time of course!).

    Yes, OK, I did try 'nearby' IPs such as the ISP's DNS. They all
    showed the same level of packet loss.

    It was (I am almost certain) a bad ADSL connection between me and the
    ISP, not an issue with ISP connectivity beyond.

    It's showing 8 now. I still have the slightly improved speed, it's
    4.7Mb/s as opposed to the 4.0Mb/s I was getting before.

    Dropping the connection and reconnecting has reset the counts. It has
    been up just on 24 hours now and I have 1472 receive CRC errors and 35
    transmit ones. (RX cells 246749443, packets 735020). I make 1472 in
    735020 about 1 in 500 for receive.
    I'm with PlusNet, they reset it for me some months ago when my speed
    had migrated down to 3.3Mb/s or so and wasn't climbing back up. I'm
    very happy with 4.7Mb/s, it's as good as I've ever seen from here,
    over the years I've usually seen about 4.2 - 4.4Mb/s.

    Thanks for all the comments/advice.
     
    cl, Mar 23, 2015
    #4
  5. cl

    Martin Brown Guest

    Rebooting the modem is always worth a try before considering any other
    more serious sort of fault. Some tend to get unreliable after a month or
    two continuous running and/or large throughput.
    Sometimes modems or lines get themselves into strange states where the
    statistics report unrealistic values. Several of mine have a habit of
    showing a noise margin of zero when they get themselves into trouble.
    I suspect it is data loss on your ADSL link.

    I presume from the ping latency you are on interleaved and some packets
    are suffering enough corruption to be unrecoverable.
    That figures. You can trade noise margin for more speed and if you sync
    in the afternoon when MW interference is lowest you get the fastest
    connection with a slight risk of degradation after dark.

    Conversely you can get a slower more stable connection by syncing well
    after dark. Using the diurnal variation in SNR to alter the sync rate.
     
    Martin Brown, Mar 23, 2015
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.