Please can someone explain my HG612 stats to me

http://i.imgur.com/YlWlttu.png

Forearmed is forewarned so to speak. I'd like to have some ammo when speaking to technical about my line. Would you say there is an issue on my line going by these stats? I do not understand all of the graphs listed here other than most of the time lower is better (excepting SNR of course).

The last 2-3 disconnects were me resetting the modem btw. Other than that it's as you see.

In the batch file script version that you have been using, FEC & CRC data was taken from the modem's GUI.

Unfortunately, the modem's own software has a bug & the GUI displays the data incorrectly.

For FEC errors, use the RSCorr graph & for CRC errors, use the OHFErr graph.

Your SNRM looks very dodgy, especially upstream.
Do you have any equipment running that coincides with the SNRM change timings, such as a TV, Sky box etc?

Your interleaving depth is fairly high, usually a sign of some 'noise' interference, needing a lot of FEC/RSCorr error correction.

The connection was up for more than 160 hours before it resynced at 04:00 on Saturday 13th.

The early hours is usually when DLM takes 'corrective' action to deal with interference/instability etc.

It looks like you were on Fastpath until that resync when Interleaving was switched on, which is when RSCorr error correction commenced.

How long have you had FTTC & have you seen similar issues previously?


BTW, more reliable/efficient program versions of the scripts, fully configurable to run data harvesting & optionally graphing on user determined schedules (via a settings editor GUI) can be downloaded here:-

HG612 Modem Stats 1.0


These program versions provide a lot more data & do report FEC/CRC errors correctly.

By using the scheduled harvesting/graphing options they can be left running 24/7, totally unattended.

I've been on it for several weeks. I only had the ECI modem to hand so all I know is that I was on interleave for a few days then it switched back to fastpath on it's own. Speed has steadily dropped since then. I have updated the scripts and started a new scheduled task. I will provide better graphs then. Until then here is a snapshot using the latest scripts.

http://i.imgur.com/9AUZlf2.png

I don't know about what could be causing any issues. I thought it might be the TV but it does not coincide with the SNR. The only other things are my PC, monitor and router or the fridge freezer. Unfortunately I live in a flat above a hair salon and next door to me are an accountant and my landlords office. Next to the accountants is a car repair shop.

EDIT: I've just taken the interstitial plate off and attached one of my numerous filters to test. Sync rate went down but US SNR went back to normal of around 6dB. It may just be the resync did it though so I will have to leave it like this for a bit. Attainable US rate also went up obviously.

Edited by deleted (Wed 17-Jul-13 15:00:50)

looks like you got some noise ingress thats intermment. It looks like my old adsl line with that behaviour.

It could be local, it may not be local, it could be crosstalk related as well, however given the frequency its coming and going it would be unusual for someone to be constantly disconnect and recconecting their line like that. line fault could cause that? dont know.

The only immediate way I can see you ensuring fast path is downgrading to 40/10 so you have the required snrm buffer to absorb it. So trading sync speed for latency. With that data its pointless asking for a DLM reset as it will only revert back. So either live with it, get the problem fixed thats causing those errors or downgrade the product.

I won't know for another 24 hours if connecting a filter to the test socket (and changing the RJ cable too just to be sure). made any difference. All I can say for now is upstream SNR went back to normal upon connecting the external filter and upstream error values do seem lower. But I need the stats to know and only 30 minutes connected or so is not going to tell me much. I will update when I can. Thanks for looking at this.

BTW if you ever have time an exe running in Windows system tray with some stats would be nice.

EDIT: Someone advised to connect a RJ11 to BT cable to do a proper test keeping any filters and phones out of the way. I have done so and saw a drop in attainable rates but this might be because I disconnected too many times today. DLM might go nuts in the AM and drop my speeds right down as I understand DLM does not implement anything immediately and logs errors and disconnections before doing so?

Anyhow let's see how that goes.

Edited by deleted (Wed 17-Jul-13 16:45:22)

In reply to a post by Oddball:

I've been on it for several weeks. I only had the ECI modem to hand so all I know is that I was on interleave for a few days then it switched back to fastpath on it's own. Speed has steadily dropped since then. I have updated the scripts and started a new scheduled task. I will provide better graphs then. Until then here is a snapshot using the latest scripts.

I can see from your Discovery phase band plans that you are connected to a Huawei cabinet DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)


These are the band plans for an ECI DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)

There was a short period recently when engineers were instructed to only install ECI modems, regardless of the DSLAM being connected to (certainly in the Oldham area where I live & some other areas - Perhaps Zarjaz could confirm if this was a short-lived nationwide policy).

An engineer who visited me at weekend to check whether my loss of 10 Mbps DS sync speed was crosstalk or a line 'fault' confirmed that local engineers are now instructed to install/replace existing modems when visiting using Huawei HG612 modems.
That may only be a local instruction though as all the DSLAMS in Oldham are apparently Huaweis.

It seems that ECI modems can occasionally struggle to actually sync when connected to Huawei DSLAMs, particularly on longer D-side connections.

Through monitoring other connections to ECI DSAMS, we have seen a slight deterioration when connecting a Huawei modem.
However, but at least obtaining a pattern of connection stats is easy & reliable when doing so.



Have you checked that the program is actually logging data every minute, 24/7?

The best method is to rename your original modem_stats.log (In the Ongoing_Stats folder) & allow the new programs to start a brand new modem_stats.log

Once a new log has started logging, the old data can be copied & pasted into the new log BEFORE the new data, ensuring no blank lines between old & new data.

You can check the ongoing logging at any time by manually running graphpd.exe & specifying a few minutes or a few hours by entering say '30 m' or '4 h' (it defaults to 24 hours if nothing is specified).

FWIW, via the settings editor program, I have my connection harvest & graph ongoing stats daily at 06:00 & snapshot graphs every 8 hours starting at 06:00.

Those scheduled events seem to provide a good daily view of snapshot data at a quiet time, when the connection should be performing at its best & at a typically 'noisy' time when many users will be using their connections.


You can of course manually run HG612_current_stats.exe at any time for ad-hoc data havesting/graphing.

http://i.imgur.com/9AUZlf2.png

I don't know about what could be causing any issues. I thought it might be the TV but it does not coincide with the SNR. The only other things are my PC, monitor and router or the fridge freezer. Unfortunately I live in a flat above a hair salon and next door to me are an accountant and my landlords office. Next to the accountants is a car repair shop.

EDIT: I've just taken the interstitial plate off and attached one of my numerous filters to test. Sync rate went down but US SNR went back to normal of around 6dB. It may just be the resync did it though so I will have to leave it like this for a bit. Attainable US rate also went up obviously.

Another source of connection interference could be an alarm system, connected to a remote monitoring station over the phone line.
Apparently these have occasionally been wired in BEFORE any DSL filters/faceplates & do not contain any of their own filtering.



If it's of any interest to you, an updated version of GRAPH6.exe (the actual snapshot data graphing program) can be downloaded here:-

Updated GRAPH6.exe Download



It provides a little more data such as connection up time at the time the data was harvested & displays the total bits loaded for DS, US & 'Shared' tones.

Simply replace the original GRAPH6.exe program eith the updated one.

You can even re-graph old Plink log data files by dragging & dropping them onto the GRAPH6.exe icon in the Scripts folder if you wished to have your old data in the new graph format.
The new format graphs will overwrite any old graphs stored in the same folder as the relevant Plink log file.

Edited by deleted (Wed 17-Jul-13 21:51:38)

Replaced the exe. Here is the new stats for the last 60 minutes.

http://i.imgur.com/VB2nHel.png

I put the filter back on in the test socket for the moment as the RJ11 to BT cable was to put it bluntly...[censored]. It had a broken clip so was loose in the modem socket and was a bit too long. I have ordered a 1m RJ11 to BT cable for testing purposes and a 1m ADSL Nation hi-speed RJ11 cable for permanent use (hopefully it will help a little).

As you can see the SNR on upstream is still wandering.

Someone said using an ADSL filter on a VDSL line makes no difference whilst someone else said it can cause issues in certain frequency ranges. Can you confirm or deny this?

EDIT: Also tried turning stuff on and off and it had no effect on SNR margins etc. I think it's something external outside my control.

Edited by deleted (Wed 17-Jul-13 19:44:03)

In reply to a post by Oddball:

Replaced the exe. Here is the new stats for the last 60 minutes.

http://i.imgur.com/VB2nHel.png

GRAPH6.exe is used to plot current/snapshot stats.
Have you been able to detect any significant changes in these since you started harvesting current/snapshot data?

I put the filter back on in the test socket for the moment as the RJ11 to BT cable was to put it bluntly...[censored]. It had a broken clip so was loose in the modem socket and was a bit too long. I have ordered a 1m RJ11 to BT cable for testing purposes and a 1m ADSL Nation hi-speed RJ11 cable for permanent use (hopefully it will help a little).

As you can see the SNR on upstream is still wandering.

I would recommend leaving the connection alone (in sync) for a while now, allowing it to stabilise (or not, as the case may be).

I don't think I've ever seen such a high US Interleaving depth as yours (around 350) from the numerous connections I have monitored.
So it does appear that either something is physically wrong or you are suffering very badly from some sort of interference.
Your connection does also seem to experience bursts where unusually, US RSCorr (FEC) is having to work quite hard.

Someone said using an ADSL filter on a VDSL line makes no difference whilst someone else said it can cause issues in certain frequency ranges. Can you confirm or deny this?

I did have a problem with a faulty BT supplied VDSL2 filtered faceplate at one time (the connection would lose sync whenever the phone was used).

I ran my connection & phone with no issues via an old ADSL dangly filter plugged into the master test socket for a while, which resolved the issue until an engineer replaced the SSFP.

That temporary solution worked on my connection, but I haven't actually compared any differences between the performance of ADSL & VDSL2 filters for an extended period.

EDIT: Also tried turning stuff on and off and it had no effect on SNR margins etc. I think it's something external outside my control.

That does appear to be the case, but tracking it down to a definite source will be a tough job.

Monitoring your connection stats for an exteb=nded period MAY just demonstrate a timing pattern that MAY give some clues as to what the cause might be.

Are you able to link any of this to the hotter recent weather?

I had experinced another issue where my connection would resync randomly & frequently on very hot & dry days last year.
That turned out to be a poor joint between the undergroundcabvle & the pole mounted DP.



FWIW, I did also test a shielded, twisted pair cable between modem & master socket for a while.
That had quite a negative effect upon DS SNRM & sync speed when compared to the basic cable as supplied with the HG612 modem.

There was a short period recently when engineers were instructed to only install ECI modems, regardless of the DSLAM being connected to (certainly in the Oldham area where I live & some other areas - Perhaps Zarjaz could confirm if this was a short-lived nationwide policy).

This was more to do with Openreach have vast swathes of ECI stock, and little or no Huwawei.

Have seen three instances where previously working circuits using ECI modems on a Huwaei DSLAM, stopped syncing, but would happily work with JDSU testers and matching Huwawei modems and DSLAM.

In reply to a post by Oddball:

BTW if you ever have time an exe running in Windows system tray with some stats would be nice.

That had been one of my intentions, not sure if I'll ever get around to adding it though.