Kitz Forum
Broadband Related => ISPs => Topic started by: Chrysalis on September 24, 2019, 10:39:00 AM
-
Will be joining you on there in October Weaver.
-
Welcome to the club
-
What has brought this on?
And yes, welcome to the club. How many cultists does that make now?
-
:thumbs:
-
How many cultists does that make now?
More than one but less than twenty, I believe.
-
I called for an identification parade ages ago, some more will have come, some will have gone I’m sure.
-
Me too. ;)
-
You too, Vic ? :-\
-
In the AAISP club.
-
What has brought this on?
And yes, welcome to the club. How many cultists does that make now?
Will state the reasons after I migrate. I have always admired aaisp as an isp so I would have gone back to them at some point anyway.
-
Chrys I either didn’t know, or have forgotten because I’m only half with-it, you were once an AA customer.
What should we call such people, AAtheists ?
I’m truly convinced that AA is actually a cult though. I only discovered this much later, when I had already been drawn in. I was a Zen customer alongside AA for a year before I got rid of the Zen line which was at another site and AA remained.
-
Yes I still have my AAISP keyring as well :)
-
I'm in the club too. Since April. :)
-
Me too. Twice - at home and my mother's home.
-
wow TTB network has latency very close to sky, here is on fastpath. Interleaving was doubling my latency.
Tracing route to bbc.co.uk [2a04:4e42::81]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms hello.ip6.arpa [2001:8b0:you:want::1]
2 8 ms 8 ms 8 ms f.gormless.thn.aa.net.uk [2001:8b0:0:53::56]
3 9 ms 8 ms 8 ms o.aimless.tch.aa.net.uk [2001:8b0:0:53::105]
4 9 ms 8 ms 8 ms 2001:7f8:4::d361:1
5 9 ms 8 ms 9 ms 2a04:4e42::81
-
Not much chance of an RTT like chrys enjoys with full interleave and slow ADSL2 2.9 Mbps/0.5 Mbps sync rate.
This is a tracert over BT.
traceroute to 2a04:4e42::81 (2a04:4e42::81), 30 hops max, 56 byte packets
1 sent:10 loss:0% last:2.876 ms avg:5.537 ms
firebrick
2 sent:10 loss:0% last:36.796 ms avg:42.115 ms
j.gormless.thn.aa.net.uk (2001:8b0:0:53::114)
3 sent:9 loss:0% last:37.527 ms avg:42.305 ms
o.aimless.tch.aa.net.uk (2001:8b0:0:53::105)
4 sent:9 loss:0% last:38.958 ms avg:43.874 ms
2001:7f8:4::d361:1
5 sent:9 loss:0% last:40.194 ms avg:42.313 ms
2a04:4e42::81
-
>> with full interleave and slow ADSL2
Out of curiosity are any of your lines stable enough to cope either without or with a lower level of interleave as I can't help but wonder how much the overhead cost is.
The benefit of not having FTTC is that the adsl2 DLM (both 21CN & TT) are a lot more flexible and not as harsh when it does see any errors.
Personally I prefer to let any occasional burst errors just get it over & done with, rather than have increased RS overheads and additional latency 24/7.
I notice the effects of interleaving far more than I do the occasional noise burst. Granted it depends upon individual lines but I'm sure Chrys is also of the same opinion for his line too.
-
I think Weaver's lines actually have PhyR retransmission on the downstream.
I don't know about anyone else's long ADSL line, but for mine, I get more downstream bandwidth with interleaving than without, the coding gain is actually greater than the overhead cost.
-
>> with full interleave and slow ADSL2
Out of curiosity are any of your lines stable enough to cope either without or with a lower level of interleave as I can't help but wonder how much the overhead cost is.
The benefit of not having FTTC is that the adsl2 DLM (both 21CN & TT) are a lot more flexible and not as harsh when it does see any errors.
Personally I prefer to let any occasional burst errors just get it over & done with, rather than have increased RS overheads and additional latency 24/7.
I notice the effects of interleaving far more than I do the occasional noise burst. Granted it depends upon individual lines but I'm sure Chrys is also of the same opinion for his line too.
Kitz I agree, and doing some speedtests that also measure latency seems to explain things.
My base latency to the bbc under aaisp is 8-9ms under fastpath, it was 17-18ms under interleaving.
During a tbb speedtest on sky latency was measured at 25ms, on aaisp under fast path 28ms (20-22ms during the downstream part of the test thanks to aaisp's qos systems), on aaisp under interleaving 60ms O_o
So the increase seems even more pronounced during TCP sessions. Things immediately were snappier when DLM switched me back.
The problem is also compounded on the modern internet where loading a single webpage can have a dozen or so dns lookups, each of these the primary metric is RTT for page loading time.
I have a weird ES spike of 3200, on my dslstats graph which is odd, those ES are not in the telnet data, the spike is when I powered up modem after firmware swap. I think on this new dsl firmware this might be a problem when powering down modems if this gets passed up to the dslam. But I think its only since link time that gets passed on. I also think this might be a dslstats glitch, powering down a modem shouldnt cause 1000s of ES thats a duration of 50 minutes of continuous errors. I left the modem down for 3 15 min cycles so close to 50 mins, but it was powered off when plugging the dsl cable back in, so that 45mins downtime is not in the memory of it. Very odd.
Since Link time = 13 hours 25 min 1 sec
FEC: 0 131
CRC: 126 13
ES: 93 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FailedRetr: 0
-
Maybe we are at cross purposes. Are some of you talking about actual measured performance of certain TCP implementations? Whereas I was talking about flat out performance of the underlying link, regardless of any protocol. If your TCP implementation has an inadequate window size then clearly reducing RTT will help real world TCP performance, but then that’s nothing to do with interleave it’s just a rubbish implementation of one particular protocol, in this case TCP. And the inadequate performance of a single TCP connection can just be fixed by a code change or using multiple TCP connections.
-
RTT affects UDP as well e.g. dns is usually UDP and that performs better with lower RTT.
But different people have different priorities for their connection, and also the underlying requirements of the line need to be considered, if a line is only stable with interleaving then my view is stability is king. Also your line's speed is low enough where by extra speed is important, there is a big difference from going from 10mbit to say 8mbit vs going from 74mbit down to 70mbit.
Plus your base latency is going to be a lot higher due to your location, so if you went to fast path been based in the north of scotland you still going to have high latency regardless.
So RTT affects a lot of things, but like wise so does the underlying sync speed, I think all three of us are right in that regard. But for people like me and kitz where we have plenty of speed already we start to value RTT much more, but for you the underlying sync speed is of more importance, does that make sense to you?
How fast do your lines sync on fast path do they lose speed?
-
I’ve never tried fast path - I could do an experiment. The lowest RTT recorded was something like 39-40ms with interleave on.
-
I only got 2 days of samknows aaisp data, but one of the main reasons I dumped sky was their CDN cache performance.
For last 30 days the sky part of the plot for netflix had a almost nightly occurrence of going below 8mbps for netflix on samknows.
the lowest netflix speed plotted for aaisp is 62mbps for the 2 nights so far, only 2mbps below its highest of 64 (throughput is 64 for rate limits)
netflix video quality plot had sky unable to do uhd for 24 hour periods, with peak times moving between standard hd and sd quality, aaisp so far has been all uhd.
my own experience of netflix on sky is it would at peak hours not be able to stay at 1080p stream quality, it didnt buffer but did pixelate.
sky has better metrics on jitter and latency stability, but the differences I wouldnt consider service affecting.
All other tests both isps are the same or very similar.
Interestingly samknows has new tests including dns over http, but those are not been run on my unit, I assume a newer unit is needed.
I wont be keeping samknows enabled 24/7 anymore tho, might turn it on every now and then to stop it been deactivated, but I plan to only use it maybe to diagnose if I notice problems.
-
I'm in the AAISP club as well, have been for 14 years, 2 bonded FTTC lines with a Firebrick FB2900. Also got my mum moved over to them several years ago because of their promise to fix faults prior to go-live and TalkTalk had left her high and dry