Below is the tracert from here:

1 <1 ms <1 ms <1 ms home.gateway.home.gateway [192.168.1.254]
2 16 ms 15 ms 16 ms bottomless.aa.net.uk [81.187.81.187]
3 16 ms 16 ms 16 ms n.aimless.thn.aa.net.uk [90.155.53.104]
4 17 ms 16 ms 16 ms rt-lonap-b.thdo.bbc.co.uk [5.57.80.90]
5 * * * Request timed out.
6 * * * Request timed out.
7 16 ms 17 ms 16 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
8 18 ms 18 ms 18 ms 132.185.255.148
9 17 ms 17 ms 16 ms www.bbc.co.uk [212.58.244.68]

As you guys have said, it has to be the routing that AA use. IDNet were consistently 10ms, so I must have been in a favourable location for their gateways.

I am a gamer but I'm not kidding myself that at my age, 6ms will make the difference to my gaming experience. It's just a case of "this is what I had, and this what now have".

In other news, G.INP has now applied to my upstream, so my intermittent line issue is making itself known.

Paul

Paul

Yes, I can't see anything that stands out there. Interesting that you mention about G.INP on Upstream, because my line has had it almost all of the time its been live. My line is noisy, but apparently it's not faulty. What's this "intermittent line issue" you speak about?

Edited by deleted (Tue 02-Oct-18 15:51:16)

In reply to a post by youngsyp:

Below is the tracert from here:

1 <1 ms <1 ms <1 ms home.gateway.home.gateway [192.168.1.254]
2 16 ms 15 ms 16 ms bottomless.aa.net.uk [81.187.81.187]
3 16 ms 16 ms 16 ms n.aimless.thn.aa.net.uk [90.155.53.104]
4 17 ms 16 ms 16 ms rt-lonap-b.thdo.bbc.co.uk [5.57.80.90]
5 * * * Request timed out.
6 * * * Request timed out.
7 16 ms 17 ms 16 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
8 18 ms 18 ms 18 ms 132.185.255.148
9 17 ms 17 ms 16 ms www.bbc.co.uk [212.58.244.68]

As you guys have said, it has to be the routing that AA use. IDNet were consistently 10ms, so I must have been in a favourable location for their gateways.

I am a gamer but I'm not kidding myself that at my age, 6ms will make the difference to my gaming experience. It's just a case of "this is what I had, and this what now have".

In other news, G.INP has now applied to my upstream, so my intermittent line issue is making itself known.

I've not looked at your line, but email in if you had lower latency before- we may be able to reset DLM etc - depending on the service you have, openreach may have automatically applied low error correction when the line moved over, which adds 8ms. DLM may well remove this automatically at some point though.

His line has G.INP not interleaving.

I think both Andrew and yourself are wrong.

G.INP always applies a low level of interleaving on Bearer 0, normally depth 8. But the �delay� parameter is set to zero. It does not add to latency. Unlike non-G.INP where when interleaving is ON the minimum �delay� setting is 8ms and often more.

Irrelevant to this discussion, on G.INP Bearer 1 also has interleaving, depth 3.

Yes, you're right and sorry that I didn't make myself clear. What I meant by "interleaving" is when it applies delay as well e.g. Interleaving+INP+Delay. Whereas, G.INP is just G.INP+Interleaving.

Normally, when a VDSL line is considered "interleaved", it doesn't have G.INP e.g. when a line has say a downstream interleaver depth of 763 and an INP of 3.00, instead of when G.INP is active, when the interleaver depth could be 8 with an INP of 48.00, but without say a delay of 8, which is, as you said, set when interleaving is active without G.INP.

Edited by deleted (Wed 03-Oct-18 18:28:01)

In reply to a post by andrewhearn:

I've not looked at your line, but email in if you had lower latency before- we may be able to reset DLM etc - depending on the service you have, openreach may have automatically applied low error correction when the line moved over, which adds 8ms. DLM may well remove this automatically at some point though.

Thanks Andrew, I'll ping a mail across.


To the point on whether it's interleaving or G.INP causing the increase in latency or not - I had G.INP on the downstream when I was with IDNet and the ping to the beeb was 10 or 11ms. I don't have details of the route it took though, unfortunately. As wsa pointed out above, I think it's simply a case of the route being longer with the current provider.

Paul

In reply to a post by WilliamGrimsley:

What's this "intermittent line issue" you speak about?

Early on in my FTTC tenure, a 'battery contact' fault was diagnosed on my line. When the OR engineer came out, he found a dodgy joint in a piece of aluminium cable connecting two poles, down the road. The symptoms of this fault were US sync nose diving from circa 9Mb/s to 1.5Mb/s and a large variance on the US SNRM. Some of the higher frequency US bins would also either not be present at all or diminish quickly over time.

The current intermittent fault exhibits the exact same characteristics to the last one but, the drop in sync and low US rate on re-sync occurs much less often. US bins diminishing and spiky US SNRM are as frequent though. The former not so now G.INP is enabled on the US.
When the US SNRM gets very spiky, I've also checked the line with an analogue phone and it was VERY noisy. Not something I've experienced at any other time.

I'm not keen to request an engineer visit this time as it was only due to the tenacity of the last OR engineer that he found an issue with the line. Not being able to guaruntee the same guy this time and the fact that whoever turns will not have access to the notes from the last issue, just makes it more likely than not to cost me money and not have anything rectified.

Paul

Is the analogue phone noisy all the time? Have you confirmed using a second wired handset? If so report it as a fault to your line rental supplier.

Interesting. I wouldn't expect G.INP to reduce the spikiness, but instead reduce the amount of errors. It has to be said though, that even G.INP isn't of much help when there's a fault.