DSL dropped. Much better sync on manual connect

That was weird. I left the house for an hour and about fifteen minutes before I got back my HG612 lost sync. And it stayed lost. First I knew was when I switched my Sky box on and it whined about having no internet. So I power cycled the HG612 and it reconnected just fine. But here's the (good) thing: My speed tests have jumped from around 55Mb/s where they've been for six months back to around 67Mb/s where they used to be before openreach relocated my PCP.

It's great to be back on my original speed but a bit weird that my HG612 couldn't re-establish sync automatically.

Well that's curious. I was talking about this with a friend and he pointed out that he had a similar experience. Months on a reduced sync then a sudden correction at an unusual time of day (ie;not early hours). In his case his modem resynced by itself but the similarity is that it happened while he was running a lengthy upload. And that's what I'm doing. Just before I went out I kicked off a backup to the cloud (some 400GB of data). It's almost as if continuous upload saturation triggers the better sync.

Two cases is hardly proof but it's a curious co-incidence.

For many many months my HG633 was rock solid at around 4mb, then the speed crept up to 5mb, but after a week or two it dramatically dropped to around 1mb, this is now the norm and it needs to be rebooted every couple of weeks.

Just checked my profile and:

The current Downstream BRAS rate is: 67.84 Mbps
The current Upstream BRAS rate is: 20 Mbps

So it looks like it's still holding. Pity I didn't think to check the profile back when it was running slow :-/

a drop and re-sync was probably caused by high error rate per min/per hour

so if there is no traffic.... no errors
now you generate a high (and continuous) traffic load,
and the error counter/per time period increases...

Normally you would expect it to re-sync lower, to reduce the likely error rate.
but when it looks at the history / of the moment conditions, it is a good thing that it tried to upgrade adapt the line also.

A manual reboot or disconnect / re-connect (preferably via the GUI option than pulling the phone plug !) could/can achieve the same in a shorter timescale.

as you say, worth knowing.

so if there is no traffic.... no errors
now you generate a high (and continuous) traffic load,
and the error counter/per time period increases...

That's not how DSL works.

Enlighten me then...
how 'does' it work and my assessment be incorrect ?
i.e. why would additional traffic not add to the probability of increases errors.
Happy to learn.

Surely there is background sync, a nice simple data pattern - and it is stable.
But when actual varying data is passed there is increased usage of the spectrum and additional opportunity for corrupted reception.

No need to be sarcastic or a ****. It just doesn't work like that.

If I plug in my modem, get sync and walk away (without even connecting my router and establishing a PPP session (so no data) I get a consistent 1000 FEC every minute. If I connect my router, and hammer 50Mb down, I get a consistent 1000 FEC every minute.

Think of it like a train constantly running on a line. When your transferring data it's within the carriages, but the carriages are always running. The mechanics are checking the carriages for errors, they don't care how many people are on board.
Well you data is the people. The error checking doesn't touch your data. It doesn't even know it's there (It's all in PTM packets).

Edited by j0hn83 (Sat 10-Feb-18 12:43:33)

There are plenty of protocols with (to use your analogy) constant empty carriages.
Likewise, plenty that establish a maximum performance rate during initial handshake sequences.. .but then do not need to use all of that coded capability until demanded. The null / holding frames are reliable and highly interference tolerant. (yes, we can debate whether they would be better used to stress the system at this time... but that's another discussion)

So when those carriages are filled less benign/null data, it starts to have an effect.
Therefore the error checking of the carriages (packets) would reflect any corruption seen whilst carrying different data.

Now it could be that the coding of the data, is such that it has been designed to be 100% equal, but most systems do not achieve that goal, the change to actual non-null data has an impact in some (sometimes rare) situations.

So why/how does the sending of non-null packets not differ from sending data specific ones. i.e. how would my proposal be incorrect in the context of xDSL/FTTx transmission and better, the poster's issue actually be caused. The poster is seeing an issue, so lets go explain that.

Perhaps my analogy wasn't detailed enough. Think of your line as train tracks. When the DSL is in sync the line is always full of carriages. Imagine a never ending train, always running on the line. The data inside is irrelevant, it has no impact on the train.
Data being transmitted doesn't change anything physical on the line. Power levels, SNR, noise, etc, all remain the same.

It's the same how crosstalk doesn't change wether your neighbour is using their connection or not. It's a constant noise. As long as the line is synced it creates the noise that disturbs your line. The neighbour randomly downloading a 100Gb file doesn't create any additional noise.

What the OP is describing is called a coincidence. Doing a large upload during the line resyncing cannot increase sync. The data being transmitted on xDSL has no impact on any of the lines characteristics.

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.