Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pettaw]

Hello everyone,

Long time lurker but new guy around. I've already encountered Mr Baldy who gave me his fantastic stats scripts so I've unlocked my modem.

A little bit of history first. I've had BT's FTTC since January, where I had maximum speed at that time. I've known that I had impulse spikes or short bursts of noise on the line because the scripts showed it, but because the line was limited to 40/10, I had plenty enough SNRm to not have a problem.

I've upgraded a couple of months ago to the new 80/20 package and since then because the SNRm is that much lower, the line drops every couple of days or so. I also note when I run the web app for the modem that I have drops of about 2dB SNRm when I pick up the phone, and about 2dB SNRm on upload if I ring the phone from my mobile.

I've got a very long modem_stats,log if someone would like to look at it I can email it, but I've got the two plinks: the 0606 is with the receiver down, and 0607 is with the receiver picked up.

[Bald_Eagle1]

Hi pettaw & welcome to the Kitz forum.

I still have some of your logs & graphs from March, in case we need to refer back to them.

If you still have my email address, by all means send the modem_stats.log to me for a look-see (or post it somewhere that we could download it).
If you don't still have my email address, drop me a PM confirming your current email address.

It's not too easy when looking at limited info, but from your Plink logs, I have attached the bit-loading graphs & produced the pbParams data.

The graphs appear to contradict the pbParams data though. Maybe you obtained the stats part way through the modem refreshing its stored data?

I had a similar issue with use of the phone, SNRM sometimes actually dropping sufficiently to cause an immediate resync, but dialling in from another phone temporarily "fixing" things for a few hours.

Using a dangly filter in the test socket instead of the filtered faceplate confirmed a faulty faceplate.

However I also had other completely random disconnection issues that were fixed at the same engineer's visit when he remade a loose pole top DP connection between the underground cable & my drop wire.

My connection has been very stable since that visit (still unfortunately at less than 40Mb due to distance from the cabinet).

Maybe seeing your ongoing logs will give us some pointers, but it does sound a little like a HR issue brewing.

Does this issue get worse during warm & dry weather?
Mine definitely did.

Cheers,

Paul.


EDIT:

Looking directly at your Plink logs, I see that Interleaving is OFF for both DS & US & that INP & delay have values of zero.
That actually suggests you have a basically stable connection, not requiring error correction & Impulse Noise Protection.

[Bald_Eagle1]

Hi pettaw,

For easier viewing I have split your modem_stats.log into the 3 chunks that actually contain data. i.e. March, May/June & August.

There are one or two spurious results that I haven't bothered to filter out as we can still see the overall state of your connection.

I have to leave for the office now, so haven't time to analyse things in depth yet (I'll have a closer look later on though).

In the meantime, maybe other experienced members may wish to comment on what is shown in the graphs.......


Cheers,

Paul.

[pettaw]

Thanks Baldy, Its weird certainly. I've looked into my router's logs and the resync on Wednesday morning, hasn't shown up in the logs so it must have been such a short loss of service that the router hasn't even shown it. Since Wednesday it hasn't resynced so its probably about time this weekend Also strange that even though it resyncs reasonably regularly, the DLM hasn't kicked in Interleaving or INP.

I'll do the phone experiment again and try and get new graphs.

EDIT: OK so I've done some more experiments. First log is with receiver down. Second is with receiver off the hook, third is with receiver replaced back again, fourth is with ringing the phone, and then finally nothing again. I've split them over 2 zip files.

[Bald_Eagle1]

Hi pettaw,

Thanks Baldy, Its weird certainly. I've looked into my router's logs and the resync on Wednesday morning, hasn't shown up in the logs so it must have been such a short loss of service that the router hasn't even shown it. Since Wednesday it hasn't resynced so its probably about time this weekend Also strange that even though it resyncs reasonably regularly, the DLM hasn't kicked in Interleaving or INP.

On the fly resyncs are usually too quick to be recognised by an ISP & thus a new PPP session is not initiated & the event is not reported in the router/hub.
However, these events are usually recorder in the HG612's built-in logs (if logging is enabled - it is OFF by default).


Here's an example of the HG612's log for a couple of resyncs & a reboot:-

2012-7-21 6:23:24 Warning 104001 System reboot
2012-7-19 19:53:7 Notice 0 admin login
2012-7-19 15:56:42 Notice 104500 DSL activate succeed
2012-7-19 15:56:26 Notice 104500 DSL deactivate
2012-7-19 10:54:36 Notice 104500 DSL activate succeed
2012-7-19 10:54:19 Notice 104500 DSL deactivate

I'll do the phone experiment again and try and get new graphs.

EDIT: OK so I've done some more experiments. First log is with receiver down. Second is with receiver off the hook, third is with receiver replaced back again, fourth is with ringing the phone, and then finally nothing again. I've split them over 2 zip files.

Your graphs look similar to what I experienced, only mine were more damaging (actually causing resyncs simply by picking up the phone).


Do you have a dangly filter to try in the master socket's test socket?
If so, you could see if the SNRM changes just as much when using the phone via the dangly filter.
If it does, it would suggest the issue is external, possibly some sort of a HR fault starting to develop.
If the connection remains steady via a dangly filter, it would point to a defective filtered faceplate. These are known to occasionally fail.


Cheers,

Paul.

[pettaw]

OK so as I predicted the modem resynced last night at 9ish. Interesting thing is that there is no entry in the modem logging. The entry is missing completely.

I've got a dangly filter, I'll try installing it later on, not today though, don't want to get the DLM all "interested"

[Bald_Eagle1]

OK so as I predicted the modem resynced last night at 9ish. Interesting thing is that there is no entry in the modem logging. The entry is missing completely.

When you say there is no entry in the modem logging, do you mean the modem's built in log, the 24/7 modem_stats.log or the router's log?

I can imagine the resync was too quick to be picked up in the router logs and/or it may have occurred just as the 24/7 script was harvesting data for modem_stats.log, however I can't imagine there is no sign of it in the modem's built-in log (unless you haven't actually enabled logging yet).


EDIT:

Just noticed that you had attached modem_stats.log & I can now see that the entry from around the resync at 21:51 is missing.

[pettaw]

Yeah exactly, the log from the resync time is missing. I've checked in my router logs and as you rightly say, the resync was too short to show up in the router log...no loss of service.

Any idea as to why? Possible modem problem? I'll try a dangly filter in the socket tomorrow I think and see whether I can get the same results playing with the phone.

[Bald_Eagle1]

Any idea as to why? Possible modem problem? I'll try a dangly filter in the socket tomorrow I think and see whether I can get the same results playing with the phone.

As mentioned previously, my connection suffered with similar symptoms (very frequent but random "on the fly" resyncs, being more severe during "better" weather conditions & more stable during wet & cold weather.

These issues were finally "fixed" by an OR Engineer replacing the filtered faceplate & also repairing a dodgy pole top DP joint 26th May, my connection regaining its early stability, but not its original speeds.

FWIW, I attach graphs from just 160 days of logging my stats that clearly shows the state of my connection before the fix & after the fix.
Due to the scale & fitting in 160 days, not all the resyncs/drops in SNRM etc. are easy to see, but you can see the general picture.

I suspect you are experiencing similar issues, perhaps at a slightly lesser degree.

Who knows, the dangly filter might just determine that the faceplate is the culprit, which would be a really easy permanent fix.

[pettaw]

lol I know that, I meant what would cause that particular minute not to be logged. Why no entry for 21:52?

[Bald_Eagle1]

lol I know that, I meant what would cause that particular minute not to be logged. Why no entry for 21:52?

Just put it down to a badly written script that can't cope with a resync ongoing just at the same time as trying to harvest the data, in the same way that the script still tries to do something over & over, even when the modem is disconnected (unless 24/7 logging is stopped).

Failing that reason, were you using any resource hogging software that took priority over the script at the time e.g. a virus scanner just as one possible example? This issue seems to affect Windows 7 systems more than XP & Vista systems due to the way it handles things differently.

My newest script (not released yet) has more error checking built in, so would probably handle such an event differently.
However, as I am currently working on a generally more efficient/reliable way to obtain the same raw stats data (& more), I might not now release the updated, but "clunky" batch file scripts at all, changing to a .EXE program instead (still using modem_stats.log & Plink logs for compatibility & historical data storage/graphing purposes though).

[pettaw]

Contacted BT yesterday through their Twitter account, (Its the best way to get through to the Northern Ireland based BT Care team that are much more clued up on DSL problems) and they phoned me having conducted tests and told me that because my line only resyncs once every 3 days that's "not bad enough" for their supplier (who I take it is BT Openreach or does a fault have to be raised with BTw who then forwards onto BTo? Anyway apparently it needs to be resyncing a couple of times per day at least for them to be interested.
I'm thinking that by the time it resyncs a couple of times a day, the customer will be complaining of hopeless speeds because DLM kicks in but anyways, just thought I'd post for information.