I'd expect a higher attainable than that on a 110m G.Fast circuit....

In general, yes. Unless running below the target noise margin.

But, on VDSL2, I've learnt to distrust the output displayed by Asus modems. What they tell you may bear no resemblance to actuality. My starting point is to trust nothing.

But ... I wrote that answer having missed the reference to G.Fast, so it's all void anyway.

I haven't learnt whether to trust Asus modems for G.Fast, but you can bet that my default trust level is not set high. To start with, the attenuation isn't likely to be zero.

http://tbb.st/1503996439389179855

Seems to suggest something is limiting the test to FTTC type speeds.

This G.fast test does better but seems to have a limit around the 100 Mbps mark http://tbb.st/1502747985244055455 - might also be one of your tests.

The tester itself can do what you need e.g. BT FTTP user http://tbb.st/1501690866409176055

Other testers don't generally record the trace during the test and this makes it hard to diagnose or make comparisons, particularly as some have a tendency to show close to the maximum speed, rather than a median.

Asus still haven't fixed the DSL-AC68U.
I really wouldn't expect the DSL-AC88U to work well on G.Fast anytime soon.

I would completely ignore ANY stats from the Asus GUI.

Get a debug version of the firmware, telnet in, and run "adsl info --stats"
post back here with the output?

In reply to a post by MrSaffron:

This G.fast test does better but seems to have a limit around the 100 Mbps mark http://tbb.st/1502747985244055455 - might also be one of your tests.

I think that was one of mine - the night I tried running the test in Windows Safe Mode. Been trying to work out since what is limiting things.

Trying to do things which don't involve re-setting the connection too often or the DLM will kick in and bring another unknown into the equation.

I have no doubt the BTW tester tries to show things in the best light but there does seem to be a big disparity.

I can't tell you whether those values are low or high.

When G.INP retransmission is active, the INP parameter really defines how big the retransmission queues have to be. The INPREIN parameter defines the amount of FEC and interleaving.

But, because retransmission is dynamic, any knowledge about whether the settings impact your throughput really relies on knowing the error rates - the FEC success and failure counters, and the number of blocks being retransmitted. These aren't visible.

We cant quite see how much fails retransmission. CRC is 8, so quite low. But ES is 583, which would be fairly high in VDSL2 terms for 1 day. However, the two figures are inconsistent, so we don't know which to believe.

It might be better to see if you have any packet loss, using a ping quality meter on the main TBB site.

In reply to a post by lee111s:

I'd expect a higher attainable than that on a 110m G.Fast circuit....

Yes, me too.

That attainable might match the old trial results for distances of around 150m, but even that is quite low compared to current expectations.

This might be old (amendment 1) hardware, running at the lower power. A shame that the Asus doesn't give us the downstream power, which might have given us a clue.

Apologies for the delay - day job got in the way!

Managed to borrow a laptop and it confirms the weak link in the chain is the PC.

Got speeds of 299 to 306Mbps on the BTW checker and 260 to 275Mbps on the TBB version.

PC is probably due for replacement so will look at doing that.

The high error rates were mentioned earlier in the thread. These built up very quickly in the first few hours of the latest session but have barely changed since, some six days on. The cause might have been a plethora of hands working on the cabinet last weekend. I always know they there because I can hear the extremely loud creaking noise the left hand cabinet door makes when they open it!