.... So if 10dB prevents fastpath / DLM problems, but wrecks download speeds, then we need to continue working on it - and I'll endeavour to make that happen.
Download speeds will be wrecked, everyone that has tried the 10db suggestion so far has seen a decrease in download speed. This is not a surprise and is exactly how signal to noise margin works.
You basically want as big a difference as possible between attenuation and noise margin for the best speed, without pushing the gap too large as to a point things will not even connect or are unstable. The higher the attenuation number the lower the speed, the lower the noise margin (SNR) the better until it loses stability. (10db will typically give slower line speeds than say 6db, 3db will be even faster than 10db and 6db, but as that figure is nearing zero may be unreliable/unstable)
Asking people to jack up the noise margin to 10db is bad for a number of reasons...
1) By default BTs DLM (This all is for FTTC only) system will aim to try for a 6db noise margin regardless of how good or bad the lines attenuation is initially.
2) If that is not possible (IE a line is unstable) it will then either A) Interleave the line to prevent errors, B) reduce the attainable speed C) Increase the noise margin, typically alterations to noise margin are a last resort.
3) If the device is faulty or to be polite about the Asus device does not function well and you jack the noise margin up to 10db but have a decent 20db attenuation you are going to confuse DLM, it will wonder what the hell is going on, think to itself hmmm a 20db attenuation line should perform well, lead it to think there is some kind of fault and thus it will then first interleave (which will make no difference as you have vastly altered the noise margin) it will then takes its second step and reduce line speeds. If its still unstable it will likely just keep reducing the speed.
NO LINE, I REPEAT NO LINE which is normally capable of over 65(ish)Mb on FTTC should need a 10db margin. The only time it would is if there is a fault or a device can not hold on to noise margin (which is what is happening with the Asus).
I suggest you tell tech department as a start to look at the way bitloading is handled in the firmware, cos all fingers points to that and either the algorithm in general or the bits per tones.
If people set the device to a 10db margin it may well reduce the errors, but that is masking the issue because you are killing a massive amount of line margin in which to do it, which in turn obviously leads to a loss of speed.
Im sorry but if Asus tech department with regards to modems and routers does not understand this, then i politely suggest your company sticks to things they are good at (IE HARDWARE, like monitors and Motherboards) rather than devices that require large amounts of software coding doing complex maths (as is needed in a router/modem firmware).