Sudden strange occurrences with ST546v5

Speedtouch 546v5
Firmware v6.1.4.7
Interleaving ON
DMT v7.5
WinXP Home/Win2K

So there I've been, merrily sync'ing away at a shade over 4M bps (downstream) and a typical evening SNR of around 7dB for about a year, with no disconnections. Rock solid, over that time. Along the way, FEC errors have mounted steadily to astronomic figures but CRC errors have been no more than an average of about 900 per day, which I gather is respectable for the 3km line on which I operate. Daytime SNRs have been typically 9.5dB - 11dB.

I run a dualboot of WinXP and Win2K, with DMT v7.5 running in both. Originally, I'd used DMT v7.5 to force the target SNR to a higher value than normal, accepting that my sync rate would be commensurately lower (in fact, that shade over 4M bps). So, that's how I've been running my connection to the exchange for all that time, and I've been perfectly happy with the situation.

Lately, I'd had a feeling that my surfing wasn't quite as perky as normal and indeed I hadn't looked at the ADSL status in the ST546 for a couple of weeks or so till tonight. But I was then shocked to see that my sync speed had dropped right down to 2.6M bps (from 4023K bps to 2656K bps), with a SNR of 13.5dB.

I've now used DMT to get me back to something like I had before. It's now just after midnight and I'm running on 4064K bps, with an SNR of 7dB, having put DMT to use again. Hopefully, come daytime, that SNR will move up to 9 or 10dB.

All of this begs the question as to why the sudden change in sync speed occurred. According to the ST546, it happened 13 days ago. But it's mighty strange that one or two users of later Speedtouchs have lately been reporting similar strange occurrences. Could this be due to a bug in the core firmware? Could it be that something odd like this happens if the FEC or CRC counters finally overflow? Or perhaps there's a bug in DMT v7.5 that only comes into effect when the FEC and/or CRC counts get very high?

Mind you, I do recall that a few weeks ago, there was an extended loss of service from my ISP. When the service finally resumed, I did check with the ISP's tech support that an outage in their network had occurred and they confirmed as such. So maybe that was the cause of my ST546 completely resync'ing? I'll have to check my old e-mails to see on which date that loss of service took place. But could a complete loss of service (no e-mailing, no browsing) have propagated right down to my exchange and thence on to me in such a way as to cause total loss of sync in the ST546?

Anyone got any useful comments or suggestions on this?

It's now 11am the next day and the SNR hasn't shifted much, so I've used DMT yet again, pushing the target SNR slider a good bit further up its scale. I normally do the sequence: Apply/Resync, Save Settings, then Reboot/Resync. It's noticeable that, when I get to pressing Reboot/Resync, the synchronisation with the DSLAM seems incapable of waiting long enough for the ST546 to complete its resyncing sequence (as indicated by the lights on the ST546). Consequently, the Reboot/Resync fails and I'm simply left with a router that's disconnected. I then go through the whole 3-stage exercise again and, this time, the connection's successful. Odd, that.

Anyway, have now got the line working at 4128K bps, with an SNR of 12.5dB. After a further day's observation, I might well bump that SNR up even more, as from past experience my line can sometimes get hammered by sudden high levels of spurious noise. Really, I want to keep my worst-case SNR (usually observed in the late evening) to no lower than about 6.5dB - 7dB. As previously, I'm prepared to accept a slightly lower sync speed. Just a tad over 4M bps seems to be the optimum for me.

I checked my old e-mail. The loss of service occurred on 1st Oct, whereas the evidence of uptime, taken from the ST546, suggested that the major auto-resync of the ST546 took place on 3rd Oct. Conceivably, though, another major service outage could have occurred on the 3rd during a period of the day when I wasn't anywhere near the router or the PC.

Postscript:

11.50am. Have just run a speedtest and I'm getting data download speeds of around 1.9M bps. That's way, way below the profile that should correspond to a sync speed of 4128K bps, even taking contention, etc into account. Instead, 1.9M bps would seem to be the ballpark dataspeed figure for that 2656K sync speed. Perhaps I need to give it a bit more time, maybe a few days?

Edited by deleted (Tue 16-Oct-07 12:03:27)

I never do a reboot after saving the settings I know someone on here (possibly yourself) said its needed to properly set the new settings but I have never had a problem with just applying and if stable then saving the settings. By hitting reboot after you adding an extra synch event and have a risk of upsetting BTs automated profiling system.

I would say nothing complex about what happened you probably had a noise burst it caused your router to synch at a low speed and it stayed there until you noticed it.

Yeh, I'm now inclined to agree about that 'extra sync event'; it's probably unnecessary to press Reboot/Resync.

You could well be right about the problem having been caused in the first place by a big splurge of noise. What I don't quite fathom is that, in the 13 or so days that then passed, it didn't re-sync back to the original 4M bps figure. Should it have done?

At the moment, I seem to be stuck on a data download rate of around 1.9M bps. That, in fact, is more like what you'd get with fixed-speed 2M bps ADSL. I'm monitoring it now for a few days, in the hope that it'll move back up to around 3.5M bps, the IP data profile it should have, for my current sync speed of 4128K bps.

it's probably unnecessary to press Reboot/Resync

A resync is required to implement the tweaked noise margin, but not just for saving the settings (the Telnet command 'saveall' will do that without needing a reboot).

Hmm, not so sure about that, adebov. I have to confess that I'm still in two minds about it.

What I've observed is that when I press Apply/Sync, DMT appears to give the 546 a 'direct command' to resync to the required new settings, whereas when I press Reboot/Resync, DMT not only causes the 546 to resync but, at the same time, it causes the Ethernet interface to be disabled for a short time. I think this is why, when Reboot/Resync is first pressed, the DSLAM loses the connection completely (because it takes time for the Ethernet interface to recover, compared to the expectations of the DSLAM) and so fails to resync at all. But strangely, when you repeat the three-stage procedure, the DSLAM then copes and the line resyncs.

Incidentally, being the evening again now (nearly midnight), I've checked my downstream SNR, as reported by the 546, in Broadband Connection. The sync speed is still at 4128K bps but, from earlier today when I used DMT, the SNR has dropped from 12.5dB to 6.5dB. That rather indicates a considerable amount of noise on my line in the evenings now. Looks like I need to tweak the target SNR (set specifically during the daytime) to something a bit higher, perhaps 13dB or 14dB.

Edited by deleted (Wed 17-Oct-07 00:06:55)

What I've observed is that when I press Apply/Sync, DMT appears to give the 546 a 'direct command' to resync to the required new settings

Is that command 'adsl config modemoption=18' (for example)?
Because, if manually tweaking (using Telnet), that is all you require to change the target margin.
As soon as you hit 'enter', following the above command, the router automatically resyncs using the new setting.
Then 'saveall' is what you require to save the setting to memory.

whereas when I press Reboot/Resync, DMT not only causes the 546 to resync but, at the same time, it causes the Ethernet interface to be disabled for a short time.

It will do.
A reboot of the router, will reboot the entire router (ethernet interface, and all).

I think this is why, when Reboot/Resync is first pressed, the DSLAM loses the connection completely (because it takes time for the Ethernet interface to recover, compared to the expectations of the DSLAM) and so fails to resync at all.

Not related.
The ethernet interface, and the DSL interface (to the DSLAM) are entirely independant.
One doesn't require the other, to allow a DSL sync to occur, or to connect to the router (using the ethernet interface).

I have never had the DSL fail to sync, following a tweak (and I've carried out countless tweaks of Speedtouch and Belkin routers, over the last year or so).
The only thing that would cause the thing to fail to sync, would be if you set an impossibly low target margin, resulting in it syncing too fast for the noise, and it drops sync immediately (I've had it do that before).

Looks like I need to tweak the target SNR (set specifically during the daytime) to something a bit higher, perhaps 13dB or 14dB.

You must have a very noisy (or poor quality) line, then.
If I set a noise margin of 9dB, or above, the router will hold sync for weeks (and that's on a 57dB line).

Yep, it seems I've got a particularly poor line. It's now 1am in the morning and the SNR has dropped even further, to 6dB.

Meanwhile, there's good news on the data speed, as testing has now revealed that that's back at 3404K bps.

Thanks for your further comments, adebov. Much appreciated.

BTW, I'm doing all of the tweaking in DMT. I'm not using Telnet.

Yes, when the Resync fails, I get an error message in the DMT graphic that's something like "Error - cannot identify modem type". I reckon that occurs because the DSLAM tries to recover the synchronisation of the line before the poor old 546 has had time to fully go through its DSL resync procedure. That full procedure takes a minute or so to complete (the 'procedure' being as observed by the indicator lights on the 546).

Given that I've now almost restored my connection to its usual status (I'll tweak again later today), I guess "sudden strange occurrences" in my subject title was a bit of an overstatement. In fact, nothing particularly strange seems to have occurred, save that presumably a whacking great splurge of noise on the line some days ago must have caused the line to drop out and resync to a much lower rate. However, it looks as though it would have stayed there, had I not finally noticed the low data speed and then manually intervened.

It's around 11.15am on Wednesday now and I've just done some more tweaking with DMT. I edged the target SNR up one more notch. This has now given me a sync speed of 4032K bps at a daytime SNR of 13.0dB. At this time of year (and with the line conditions that I now seem to have), that SNR will come down to about 7dB in the evenings. I'd really like to push the target SNR up even further but, if I did that, my sync would drop below 4000K bps and consequently the IP data speed would drop some 500K bps.

I've now more-or-less got back to the situation I was enjoying before the problem occurred, that is:

Downstream sync: 4032K bps
Initial target SNR: 13.0dB (set during daytime)
Line attenuation: 50dB
Tx pwr: 19.0dBm
Interleaving: On

My data speed averages out at around 3400K bps, depending on traffic, contention, etc.

Edited by deleted (Wed 17-Oct-07 11:37:37)

i use a target snr of 8db on my line during the day which drops to 5db in the evening, the lines rock solid @ 7mb, average crc errors (about 400 a day) my line is 3.6km long 48db attenuation.
If I were you id set your target snr to around 8db and enjoy some increased speed. (I should imagine you may see 5.5 - 6mb with an 8db margin which is perfectly acceptable). Some isp's even use a target margin of 6db without problems. Infact I myself used to run my connection @ 5db (8mb sync) 24/7 however crc errors affected throughput in the evenings.