I think your analogy was quite fine.
I think we are talking about slightly different things.

I am suggesting that it could have an impact on the modulated signal and its susceptibility to interference or ability to be distorted due to (poor) line characteristics. Therefore it does matter in some situations when changing from constant null data to now changing random data.

I don't have the knowledge on the specifics of how the data is coded or spread across the DSL line (the modulation not the ATM encapsulation), to know if that is valid. But such things often are... so whilst it could be co-incidence, it could also be a trigger factor. Just simplifying it to the next layer (ATM) before the DSL modulation is not addressing that aspect.

It may well be that there is no constant pattern on the modulation signal with Null data, and that (to use another analogy) were one to do the traditional "listening with a radio" / RF spectrum analysis to the excess radiation you could not hear or notice the difference at all between when there is constant Null data and changing (i.e. intentional/informational) data. i.e. both are equally vulnerable to distortion or being distorted and randomly appear across the all of modulation/frequency spectrum.
As an aside, I had a line that was syncing quite fine at 6 Mb/s, but could you get 0.5Mb/s of useful data down it ... only with a struggle. Lowering the modulation from ADSL2+ to simple ADSL, allowed more useful data down even thought only was syncing at 2.5Mb/s. Thus merely getting and keeping high sync is not proof of usability (and no, I don't have a record of what the errors were doing).

As to the improvement the posters saw:
Re-syncing at a time of better line conditions (eg. different users on or not on, neighbouring lines or other electrical aspects due to time of day) could change the rate at which it negotiated to sync at. That is irrespective of why it dropped in the first place. But that is a 2nd aspect to the situation - the reconnection.

upshot is, manually disconnecting (or in these cases, dropping and not reconnecting) and then reconnecting can change (up or down) the rate at which one connected.

Edited by andy88 (Sat 10-Feb-18 16:17:47)

I was simply pointing out that your statement of "more traffic = more errors" was incorrect. The train analogy obviously didn't work.

The best way to think of it is the line is constantly using its full bandwidth (let's say 80/20).
It is absolutely irrelevant if the PPP session is established and you are sending/receiving traffic or if the xDSL connection is established but unused.
There is always 80/20 going back and forward. Errors don't increase or decrease with throughput.

I am suggesting that it could have an impact on the modulated signal and its susceptibility to interference or ability to be distorted due to (poor) line characteristics. Therefore it does matter in some situations when changing from constant null data to now changing random data.

I hear what you're suggesting. It still makes no difference though. There is no "null data". The DSLAM and modem couldn't care less what you are transferring.

Again, what the OP saw is a coincidence. Of course resyncing a line when conditions are better (less noise for example) will give a better sync. It is absolutely, 100%, no doubt what-so-ever unrelated to the OP uploading lots of data.

Point of information:-

In reply to a post by andy88:

I don't have the knowledge on the specifics of how the data is coded or spread across the DSL line (the modulation not the ATM encapsulation), to know if that is valid. But such things often are... so whilst it could be co-incidence, it could also be a trigger factor. Just simplifying it to the next layer (ATM) before the DSL modulation is not addressing that aspect.

There is no ATM encapsulation on FTTC.

And yet..it's a weird sequence of events. A line that is stable at around 68/20 for nearly three years. I change ISP and after I connect to the new ISP I'm on 57/20 for six months. Then one weekend I decide to push a large amount of data upstream, my modem drops the line and fails to recover by itself. On a manual connect I find myself back at 68/20.

Could it have been some kind of stuck profile, instead? Maybe stuck on a nominal 55/10 and the large upstream run caused DLM to spot the mismatch with the profile and trigger the disconnect?

It just sounds odd. This is not an unstable line. Over the first few months after I got it in April 2012 the speed adjusted downwards a bit (presumably as my neighbours joined me on our new cabinet) but then it was stable for a year at 62/20. Then Openreach pushed a firmware mod that jumped me to 68/20. From there until August last year it was rock steady at 68/20.

Thanks for that reminder.
PPPoE as opposed to PPPoA.

and not going to go back into the discussion on variable/fixed lengths , constant/variable content again

PTM, not ATM, to be precise.