Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[craigski]

See my post #202 above, although J0hn didn't agree.

Lets say you have 2 10G switches in a lab. You uplink the 2 switches using 2 x 1G ports using LAG, so the switches have 2G LAG interconnect.

You plug a 10G devices into each switch.

You then run a iperf3 single thread test between devices, will you see 1G or 2G?

[Alex Atkin UK]

You'll see 1G, as LAG AFAIK cannot split a single stream of data, it merely allocates streams to different links.  Its why I was glad to get rid of it on my router, as sometimes if I tried to push FTTP and 5G at the same time they would end up on the same port.

Granted at a backhaul level I have no idea if its got some smarter allocation, but my understanding is you don't want traffic to the same destination to go across multiple paths as you end up with out-of-order packets.  Though if that DID happen, that would explain the problem.

[bogof]

Well, yesterday my connection dropped, and when it came back around I was on some odd gateway with it looks like dodgy / incomplete DNS settings.  And it had full line rate, almost full line rate for single threads!  Chancing my arm (as it was a Manchester connection with poor latency), I dropped the session and connected again, back to half line rate for most places, poor single threads. Did a bunch of session drop / restarts, but never ended up back on the high performance gateway.  Don't know if it was some test box out in the wild or what.

traceroute to www.google.com (172.217.169.36), 30 hops max, 60 byte packets
1 51-148-72-73.dsl.zen.co.uk (51.148.72.73) 12.226 ms 12.154 ms 12.193 ms
2 no-dns-yet-51-148-73-142.zen.net.uk (51.148.73.142) 20.249 ms 20.443 ms 20.193 ms
3 lag-16.p2.thn-lon.zen.net.uk (51.148.73.103) 20.150 ms 20.115 ms 20.091 ms
4 lag-1.br2.thn-lon.zen.net.uk (51.148.73.169) 20.303 ms 20.274 ms 20.237 ms
5 72.14.223.28 (72.14.223.28) 20.211 ms 20.415 ms 72.14.217.190 (72.14.217.190) 19.673 ms
6 * 74.125.242.97 (74.125.242.97) 22.080 ms *
7 172.253.66.89 (172.253.66.89) 22.209 ms 142.251.54.32 (142.251.54.32) 19.639 ms 172.253.66.98 (172.253.66.98) 21.753 ms
8 108.170.246.175 (108.170.246.175) 20.032 ms 172.253.66.89 (172.253.66.89) 22.074 ms lhr48s08-in-f4.1e100.net (172.217.169.36) 20.824 ms

[bogof]

See my post #202 above, although J0hn didn't agree.

Lets say you have 2 10G switches in a lab. You uplink the 2 switches using 2 x 1G ports using LAG, so the switches have 2G LAG interconnect.

You plug a 10G devices into each switch.

You then run a iperf3 single thread test between devices, will you see 1G or 2G?

But surely, the PPPoE stream session looks like a single thread through the backhaul, so it's hard to understand how these mechanisms work.  I'm going for there being some issue with the timing of the PPPoE arrival at the gateway (maybe it arrives in bursts) which causes the single connections through the PPPoE link to get backed off by TCP.  If there is congestion on the route the PPPoE traffic gets more bursty, worsening the single threaded throughput. 

Otherwise you'd have to assume the issue Chrysalis is seeing lives in AAISPs network...  AAISP do have their FTTC and FTTP services on different equipment.

@Chrysalis - I wonder if it is worth trying to log on to the AAISP test LNS?  Though maybe you just end up on a test version of the FTTC LNS, instead of on an FTTP LNS.

[craigski]

Well, yesterday my connection dropped, and when it came back around I was on some odd gateway with it looks like dodgy / incomplete DNS settings. 

BTw?

Scroll back to reply #117
https://forum.kitz.co.uk/index.php/topic,27091.msg456733.html#msg456733

[bogof]

BTw?

Scroll back to reply #117
https://forum.kitz.co.uk/index.php/topic,27091.msg456733.html#msg456733

I'm not sure what the point is that you're making.  I'm not (as far as I can tell) migrated back back back back to BTW (lol) so I think this just represents some other bank of gateways hitherto unseen, as indicated by the DNS, and the IP address not being in the same range as any of the others (although it's a 72 like the BTW one).  What is odd is that it is the only gateway I've seen while on GEA (assuming it hasn't migrated me back) that is performant.  Maybe I was the only person on it...

[Alex Atkin UK]

But surely, the PPPoE stream session looks like a single thread through the backhaul

That's certainly what I'd think, given the out-of-order packet issues if it were to get split across LAG.

[craigski]

I'm not sure what the point is that you're making.

Based on what we saw around post #116, it looks like you were possibly using a gateway on the BTw backhaul when you did the traceroute on your post today.

[Chrysalis]

Would love to understand the mechanism by which the backhaul affects single threaded performance.  Given you're talking to some real people at AAISP instead of 'droids, maybe you can ask them what gives?  Since it seems very odd when you'd consider that the PPPoE session I think terminates at AAISP.  As a relative luddite it's hard to explain the mechanism.

Will start a new thread on my issue.

[Weaver]

By ‘single thread’ I think people are trying to say ‘single TCP connection’, as opposed to a speed test that attempts to more fully load up the pipe full of traffic, with no ‘bubbles’, by using multiple TCP connections active simultaneously. Is that correct? (Using the water pipe analogy where water is the data and bubbles represent time where the link is idle at some point along the path. Max throughput can only be achieved when the whole pipe is full of water and no bubbles, ie full of data with no idle time at any point along the length. The water pipe analogy is not entirely correct, because water is incompressible and the max total water capacity is fixed, whereas queuing in routers means that in theory you may possibly have more data in flight by having ingress queues in middleboxes that are part filled and so that gives more room for data than is needed to just fill the pipe and get max throughput. That isn’t an entirely realistic situation everywhere though, because TCP aims to avoid that situation, as it would mean queuing for no reason. But as we know, the phenomenon of buffer bloat exists, in ingress queues at the start of a path.)

I would expect that a badly set up TCP implementation at one or t’ other end would be slow because of the higher value of the ratio between round trip time and the max throughput capability in these fast 1 Gbps connections. Multiple TCP connections’ effect on a speed test would be like dividing the rtt by n.

Does that sound correct?

RTTs should be quite low for many of you, unless you live in far off wilderness regions like me, but the rtt is not allowed to be much at the kinds of ≥1 Gbps speeds we’re talking about.

[bogof]

Based on what we saw around post #116, it looks like you were possibly using a gateway on the BTw backhaul when you did the traceroute on your post today.

I don't think that's possible to happen on a one-off basis as I think the switchover to BTW from Zen is a significant event (it has a 14 day leadtime) and involves someone at BT reconfiguring equipment in the exchange.
What's interesting is that you can see the section with the higher latency on this graph is lacking the characteristic yellow/blue thick line of fur which I see when connected to gateways via GEA.

By ‘single thread’ I think people are trying to say ‘single TCP connection’, as opposed to a speed test that attempts to more fully load up the pipe full of traffic, with no ‘bubbles’, by using multiple TCP connections active simultaneously. Is that correct? (Using the water pipe analogy where water is the data and bubbles represent time where the link is idle at some point along the path. Max throughput can only be achieved when the whole pipe is full of water and no bubbles, ie full of data with no idle time at any point along the length. The water pipe analogy is not entirely correct, because water is incompressible and the max total water capacity is fixed, whereas queuing in routers means that in theory you may possibly have more data in flight by having ingress queues in middleboxes that are part filled and so that gives more room for data than is needed to just fill the pipe and get max throughput. That isn’t an entirely realistic situation everywhere though, because TCP aims to avoid that situation, as it would mean queuing for no reason. But as we know, the phenomenon of buffer bloat exists, in ingress queues at the start of a path.)

I would expect that a badly set up TCP implementation at one or t’ other end would be slow because of higher round trip time relative to the max throughput capability. Multiple TCP connections’ effect on a speed test would be like dividing the rtt by n.

Does that sound correct?

RTTs should be quite low for many of you, unless you live in far off wilderness regions like me, but the rtt is not allowed to be much at the kinds of ≥1 Gbps speeds we’re talking about.

Also interesting; the performance is much better on this link during the higher latency time than it is during the lower latency time, which must mean even at 20ms+ for a Manchester vs 4-5ms for London I'm no-where near what should be the limits for latency.  While the graph was "poor" for latency I actually had line rate, and when the latency becomes very good I'm back down to poor single threads on certain routes.

[bogof]

Just to draw this whole sorry tale to its conclusion, AAISP connection went live today.  After an initial blip that put me on an LNS that wasn't capably of full rate (ended up capped at around 800Mbps), I'm now seeing line rates well in excess of anything seen on Zen, very close to theoretical max.  This is with the same FTTP line, ONT and Ubiquiti UDM-Pro SE configuration (just updated PPPoE settings).

This is to Zen's speedtest server, to rub salt in the wound... lol
 

[Alex Atkin UK]

That is interesting, as Zen does seem to top-out around 915Mbit which is lower than a lot of FTTP ISPs.  It does make you wonder why this is.

I've been wanting to test direct into the ONT since I got the service, but my network is never idle so unplugging the router is not really practical (and also could account for 10Mbit less on the speed test).

[bogof]

That is interesting, as Zen does seem to top-out around 915Mbit which is lower than a lot of FTTP ISPs.  It does make you wonder why this is.

I've been wanting to test direct into the ONT since I got the service, but my network is never idle so unplugging the router is not really practical (and also could account for 10Mbit less on the speed test).

I'm not sure what it is.  There was a period of a couple of days when I had some connections to Zen that would speedtest above that level, but it went, just like it arrived.

One of the options AAISP expose on their portal is the ability to set a maximum for how much they will try and shove down the pipe to you, which is aimed at minimising backhaul bufferbloat and improving latency for time sensitive stuff like VOIP.  I wonder if this is something Zen have chosen to set at a particular level.

[Ixel]

Good to hear that the connection with AAISP is performing excellent.