Kitz,
In my case I lost a few megabits from crosstalk and when G.INP was enabled this sync speed returned.
I'm now terribly confused
I havent had a look at your stats, but its impossible for g.inp to recover crosstalk sync. As mentioned above crosstalk is a constant which affects your SNR so the noise is there at sync time. Retransmission is a method of recovering data in the event of noise bursts. They work at different levels.
As NS says the increase will be because Interleaving - or more correctly RS encoding - was turned off when G.INP was applied. G.INP can only recover any sync speed lost from RS overheads.
Think of it this way: Crosstalk is a constant and you only see your SNRm change with the disturbers line is either switched on or off. REIN and other environmental type noises cause spikes in the SNRm.
You should already be familiar with the fact that when SNRm spikes occur then data packets can be lost, which in turn trigger errors such as CRC/FEC/ErrSec/LEFTRS etc.
In old money it was the job of ReedSoloman redundancy to attempt to recover from FEC. The downside it carried a heavy overhead which subtracted from your available sync speed.
These days the retransmission process only kicks in only when it detects a lost packet and needs to recover it. But the good thing about g.inp is that it works on the fly without permanent overheads so if the line isnt erroring then it doesnt need any overheads... and hence why it can give back speeds lost through Interleaving and ErrorCorrection.
Hope that helps make things a bit clearer