Broadband Related > ADSL Issues

Uneven Latency - Imbalanced Rates

(1/3) > >>

Weaver:
See the following graph of an upload :

Note the upload at 23:00, the dark red line. The bright green (max latency) bright blue (mean latency) and dark blue (min latency) below are way up, should be like the other ones

The latency on line #3 is massive, especially so compared with the others. I am wondering what I should do to balance them out?



My queuing model spreadsheet says (very roughly) that at this bit-rate and run at 90% of 0.884434 of sync rate, there should be minimum of ~2 full-size, 1500-byte packets in the tx queue ahead of you when you want to transmit, this is corresponding to the min latency figure, a mean of ~5 packets and ~8.8 packets max. So that’s the tx queuing time that is getting added to the natural RTT from when it gets into the tx modem proper. (Poisson dist model.)

There could be queuing in the modem or in my Firebrick router, but a personal communication from RevK has ruled the latter out. He told me that the Firebrick (unfortunately imho) doesn’t maintain egress queues, it just ships everything immediately (or else drops it, presumably, according to the rate limiters’ state). So if my understanding is correct, it must be overdriving that modem, and the queue in question is at the modem. Is this idea correct?

Those numbers are only approximate but the model is not that ‘delicate’ or ‘sensitive’. I’m not at all sure I have the rates quite right. The problem might be that I somehow had the rates set wrong anyway, and that would make my spreadsheet a bit off, but not massively.

Real combined throughput upstream has dropped by 16% compared to previous tests, 1.26Mbps as compared with 1.5Mbps. (As measured by https://speedtest2.aa.net.uk)

[Moderator edited to concatenate the first three posts of this topic into one.]

Chrysalis:
In linux there is multiple places where packets can queue, e.g. on the interface but also within the networking stack, and on the shaper if shaping is enabled.

The way to ensure that the modem isnt queuing is really to have something else the bottleneck in front of it.  There is kernal tunables which might help, but not sure if they apply for bridge mode operation.  They also will need reapplying on every modem reboot.

as shell commands to view current sizes.

'cat /proc/sys/net/core/netdev_max_backlog'
also 'ifconfig' to check interface queues, but my zyxel defaults to a 0 queue length.

Look for a line like this in the ifconfig output, will be one for each interface.  'txqueuelen:0'

Just be aware tho generally jitter, higher latency is preferable to dropped packets.   If you shaping, you can choose which packets get dropped and then have them only drop on the low importance streams only.

Weaver:
My question is why that line and not others? Which way have things gone wrong do you think?

Chrysalis:
line 3 has the lowest sync rate?

Weaver:
Yes, line three has the lowest upstream sync rate. Downstream is very good however. That seems to be part of it. But all was ok a few weeks ago, when line three had a much lower sync rate. Now the line 3 upstream SNRM has been lowered with the effect that the sync rate of line 3 is much closer to the others.

In the Statsfest thread earlier, there is a complete set of stats and when that was taken there was no problem. Since then I have lost 250kbps (of TCP-payload throughput? - who knows) from the combined effective upstream speed reported by speedtest2.aa.net.uk which was 1.5Mbps before.

Right now line 3 is set at tx rate (IP PDUs) of 333520 bps, which is hopefully 90% of 0.884434 * 419kbps sync rate. The other modems have sync rates of 499 kbps or more.

Before that, the egress rate was much lower, also at 90% but of a low upstream sync rate because the upstream SNRM was way above 9dB.

Current sync rates:
    Link #1: down 2803 kbps, up 525 kbps
    Link #2: down 2843 kbps, up 499 kbps
    Link #3: down 2916 kbps, up 419 kbps
    Link #4: down 3118 kbps, up 499 kbps

Firebrick upstream rate limiters' tx speeds ::
    #1: 441111 bps
    #2: 419265 bps
    #3: 333520 bps
    #4: 419265 bps
Total combined rate: 1.613161 Mbps

Fractional speed contributions:
    #1: 27.345%   [██████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
    #2: 25.990%   [█████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
    #3: 20.675%   [██████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
    #4: 25.990%   [█████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]

Firebrick’s upstream links : modem loading factors ::
  Link #1: 95%
  Link #2: 95%
  Link #3: 90%
  Link #4: 95%

Navigation

[0] Message Index

[#] Next page