G.INP symbols

I have an ASUS-DSL-AC88U on a G.Fast connection.

I am trying to make sense of the symbols reading for G.INP. On the downstream it seems to vary between 535 and 607. The upstream remains constant at 535.

Full set of stats below.

Although it is synching at the full rate I am working on my PC as the BTW checker is showing around 260Mbs and the TBB one shows around 140Mbps

Router Stats

Lesson: Don't trust the screen output for an Asus VDSL2 modem.

In fact, the better lesson is to just not trust the Asus VDSL2 modem full stop.

Out of interest, how far are you from the PCP, and what sort of speeds did you get in FTTC?

With an attenuation of 0, I expect within 50m.

Nothing short of 80/20 on FTTC I suspect.

Cable length is 110 metres. 40 metres overhead with four (!) DPs enroute and then 70 metres underground.

Got 76/16 on Infinity 2.

Thanks - interesting

Expect a real attenuation of around 5dB.

And attainable speeds of perhaps 120/35 Mbps.

More areas where the output of the Asus isn't to be trusted.

Surely attainable speeds will be higher than the sync speeds?

Ugh. Missed that it was G.Fast.

There's little publicly known about the line profile used on G.Fast lines. In fact, these might well be the first figures I've seen on here.

I believe that retransmission should be used, but we know little beyond that.

Which brings me back to part of my original post...

Both the BTW speedchecker and the Ookla one give me an average speed of 250-260Mbps while the one on this site is nearer 130Mbps. (All via a Cat 7 cable)

All three gave near identical results to each other when I had FTTC.

I'm working on the PC to see what I can tweak. Sadly I don't have a second PC to test further and the PC I do have only has 2.4Mhz wireless.

My phone regularly hits 260-280Mbps on 5Mhz.

All tests agree on 35-40 for upload speed.

And I still don't know if G.INP at 607 symbols is giving a light touch or make a more determined effort.

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!