Print

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

[Bowdon]

Hi all,

I just hooked this HG612 unlocked modem to my FTTC connection. I've been having problems with the HH5 since the recent firmware update. The event log seems not to be the correct times, and it keeps reporting devices have disconnected when they never connected, and those devices werent even turned on at the time. So I'm thinking the HH5 is on its way out.

The HH5 as been re-syncing a few times recently. On Tuesday there seemed to be something wrong with the exchange. Though my area code wasnt mentioned on the BT service status phone line, Manchester central was. So I'm wondering if that was causing the constant re-sync's. Then I updated the rj11 cable, to an rj45 to rj11 (its an openreach mk2 new phone box I'm plugging it in to). Then this morning the speed dropped to 58mb, it had been around 63mb's before. I've known I've had interleaving on the line before. But its never dropped the speed to 58mb's. I'm wondering if the disconnections are the cause of that.

Anyways I setup the hg612 modem stats and took a snapshot of it. Can you let me know if you see any problems?

Thanks all

P.S. the vdsl as only been up for around 3 hours when I took the snapshot.

[Chrysalis]

sadly you didnt post the error stats which are key.

The line is interleaved suggesting previous stability issues which for your loop length I consider unusual.

crosstalk isnt too bad.

[Bowdon]

Is this the error stats? I'll attach them.

I've been experimenting with a new rj11 to rj45 cable during the instability situation. But I'm not sure the rj45 end is fully pushed in. I'm considering going back to a twisted pair rj11.

Before BT was doing something (and the HH5, before I used the hg612) kept resync'ing, I noticed that the noise margins on the downstream was getting low at 5.4, then coming back up in the evening. Since the exchange issue happened the noise margins seem a little higher.

I'm not sure if to change the rj11/rj45 cable as soon as I get it or wait a few days to see what happens with the line.

[Bald_Eagle1]

The entire contents of one of your Plink logs would contain all the relevant 'snapshot' data.

Continuously logging/graphing the Ongoing stats would depict any fluctuations in conditions and/or error counts which may indirectly point toward a fault or source of interference.

A FULL__MONTY ongoing graphs montage has a small enough file size to attach to a message in this forum.

24 hours minimum would be ideal, but montages can be created for various windows of time (all working back from the current time) by running graphpd.exe, either via the button in the GUI or by double-clicking its icon in the Scripts folder.

e.g. the latest 30 minutes, 8 hours, 4 days, 360 days etc.
It's usually best to use units in multiples of 2,3,4,6 in order to view the times along the x axis with more clarity.

[Bowdon]

Hmm on the next snapshot am I better to zip up all the files created and post them on here? I wasnt sure how many attachments I could make per post.

Whats the best way to upload the Plink log, its 331kb big and the max upload per file is 200kb?

[loonylion]

Whats the best way to upload the Plink log, its 331kb big and the max upload per file is 200kb?

zip or rar it, ascii text should compress pretty well.

[Bowdon]

Thanks loonylion, good thinking

Ok here it is.

[Bald_Eagle1]

Your DS sync speed is currently 60065 Kbps.

When multiplied by 0.9679, that equates to an IP Profile of around 58136 Kbps or 58.14 Mbps.

Actual throughput should be somewhere between 94% & 97% of that.

DS Interleaving depth is quite high at 1489 & US Interleaving depth is extremely high as US is not often interleaved.

DS Impulse Noise Protection (INP) is 4.00 i.e. higher than the usual starting level of 3.00 when Interleaving is applied.
US INP is 2.50. More usually it is zero.

DS delay is 8.00 (the lowest level when interleaving is applied) & US is 6.00 (it is usually zero).

CRC or OHFErr errors are only 10 in the 3.25 hours you had been connected & FEC or RSCorr counts are as to be expected with such interleaving depths.

DLM has seen quite a bit of instability and/or impulse noise & taken action to provide a more stable connection at the expense of fastpath & sync speed.

It is possible that matters will improve following a sustained period of stability, very few resyncs & low error counts.
This period of stability could be anywhere between a few days or a few months.


FWIW, you are connected to an ECI DSLAM cabinet & your HG612 is still running old firmware where the lower DS & US tones are 'shared'/overlap (shown in blue in the graphs).

The latest firmware, which is likely to be remotely installed by BT (unless you have intentionally blocked updates) does appear to help stability with either no interleaving or lower depths.
It also allows a level of FEC, without immediately applying or increasing interleaving depth.
It also appears to improve (increase) bitswapping rather than to simply mark tone as unusable.

Looking at your QLN graph, it appears that you have quite a 'noisy' connection (or at least it was at the time of the latest resync).

-140 dBm/Hz would indicate a 'quiet' connection.


I have attached my own snapshot montage from my 1100m or so length connection, Huawei DSLAM & updated HG612 firmware.

My QLN graphs were much closer to -140 dBm/Hz when FTTC was installed in 2011.

I was able to achieve around 30Mbps sync speed (interleaved) back then.

The worsened QLN graphs & much reduced sync speeds that I 'enjoy' these days are the result of increased crosstalk as more users have gradually been connected.

My connection is now able to sustain fastpath, but I really do miss the higher sync speeds that I genuinely did enjoy on my quite long connection.

[WWWombat]

I'll just add to BE's commentary:

The downstream INP of 4 and delay of 8ms led the modems to set FEC overheads at 14 bytes out of every 54. That's 26% of your bandwidth, and is quite heavy protection.

The existence of upstream intervention is unusual, and the settings of INP=2.5 with delay=6 led to FEC overheads of 16 bytes out of 76, or 21%.

When DLM intervenes for both downstream and upstream, it seems that it normally chooses a compromise delay, so instead of just 8ms delay downstream, it would perhaps allocate 6ms down with 5ms up. It seems that DLM really doesn't like your line.

As a result of all this intervention, you've ended up with 2 ES's over 3 hours. If that extrapolates linearly, it'd be 16 ES's per day - well under any threshold for DLM to reduce the intervention level.

I'd say it is worth leaving on the line, and monitoring. De-intervention will probably need a lot of good days.

[Bowdon]

Thanks for giving your opinions guys.

All was reasonable until tuesday morning in the early hours (around 2am).. when my then HH5 kept disconnecting and reconnecting in a cycle until around noon that day.

I had noticed that prior to that the noise margins were going low on the downstream.. and since it came back on the noise margin improved, not going below 6db.

I bought the hg612 unlocked before I realised the cabinet was an ECI. I might buy an ECI modem with that. I did by an RJ45 cable for the openreach mk2 connector and put it in yesterday though I never heard it 'click', and my noise margin didnt improve, so I'm going to go back to an rj11 twisted pair soon.

If I was to let the modem update the firmware then I'm assuming the modem would be locked again? So how would I get the stats off a locked modem?

So what can I do to reduce the ES's / FEC's?

There seems to still be an on-going situation in Manchester central exchange, 0161. I'm 01706, which is a sub area of Oldham, which in turn is a sub area to Manchester. I had wondered if the unstability of the line occuring was connected to that. I noticed the fault is still on going according to BT's status page.

[NewtronStar]

Thanks for giving your opinions guys.

All was reasonable until tuesday morning in the early hours (around 2am).. when my then HH5 kept disconnecting and reconnecting in a cycle until around noon that day.

FTTC modems don't like being disconnected and reconnected in quick succesion it kept doing this on the HH5 in a cycle this may be the reason why the DLM has intervened.

As BaldEagle1 has said you must keep FTTC modem as it is and no more disconects for 4 to 14 days and let the DLM reduce the level.

Then you can start investigating whether it was the cable or the HH5 that started the issue 

[Bald_Eagle1]

Thanks for giving your opinions guys.

All was reasonable until tuesday morning in the early hours (around 2am).. when my then HH5 kept disconnecting and reconnecting in a cycle until around noon that day.

I had noticed that prior to that the noise margins were going low on the downstream.. and since it came back on the noise margin improved, not going below 6db.

The noise margin may have improved, but that COULD be due to the rsync when Interleaving was applied/increased, along with the lower speeds in order to maintain the 6dB target noise margin.

I bought the hg612 unlocked before I realised the cabinet was an ECI. I might buy an ECI modem with that. I did by an RJ45 cable for the openreach mk2 connector and put it in yesterday though I never heard it 'click', and my noise margin didnt improve, so I'm going to go back to an rj11 twisted pair soon.

Now you have said where you are based, I'm a little surprised that the DSLAM is ECI.
I thought that all the DSLAMS around the Oldham & surrounding areas were Huawei.

Some ECI modem models can be accessed for stats, but it usually involves some soldering inside the modem itself.

TBH, I would stick with the HG612 as all stats in a familiar format are so easily obtained, logged & graphed.

Some users believe the ECI modem works best with ECI DSALMS & some say it makes little if any difference.
I regularly remotely monitor a number of poor speed, very long VDSL2 connections down south via HG612 modemsthat use ECI DSLAMS.
Using a HG612 doesn't appear to cause any issues whatsoever.

If I was to let the modem update the firmware then I'm assuming the modem would be locked again? So how would I get the stats off a locked modem?

HG612 Modem Stats will continue to work, but you would lose access to the HG612's built in GUI.
I haven't had access to the inbuilt GUI for over 12 months now.
It doesn't matter to me as I have no desire to change any modem settings via the GUI & I still get all the connection performance stats I need.

You could download HowlingWolf's updated firmware with GUI re-enabled & lock it against future remote updates as many users appear to do.
The choice is yours.

So what can I do to reduce the ES's / FEC's?

ES seem very low & unless you experience bouts of 'interference' (visible via the ongoing stats montage), it is unlikely that DLM will make matters any worse (provided the connection remains in sync for a good few days).
FEC's aren't really anything to worry about.
They actually prove that Interleaving is doing its job & correcting errors rather than having to retransmit them due to high CRCs & RSUnCorrs

If interleaving is reduced or completely removed, you would see increases in various 'critical' error counts.

e.g. I see around 1000 or so DS ES per day on my fastpath connection (below the 1440 or so that are believed to cause DLM to kick in).

I also have reasonably low levels of other 'critical' errors.
i.e. Far fewer than before the modem's firmware was updated in October 2013.

There seems to still be an on-going situation in Manchester central exchange, 0161. I'm 01706, which is a sub area of Oldham, which in turn is a sub area to Manchester. I had wondered if the unstability of the line occuring was connected to that. I noticed the fault is still on going according to BT's status page.

I take it that would be the Shaw or Rochdale area then?

I live right on the outskirts of Oldham (0161), but I'm not seeing any particular issues here.
What's the link to the BT status page?
I'll take a look for curiosity.


I have attached my ongoing stats montage for the 24 hours leading up to 06:00 this morning for reference.

[Bald_Eagle1]

There seems to still be an on-going situation in Manchester central exchange, 0161. I'm 01706, which is a sub area of Oldham, which in turn is a sub area to Manchester. I had wondered if the unstability of the line occuring was connected to that. I noticed the fault is still on going according to BT's status page.

See the attachment.
Is that what you referred to?

Whatever it was (as mentioned before, I wasn't affected by it), it seems to have been fixed.

I'm with PlusNet FTTC, not BT Infinity, but it is still delivered by BT over BT cabling.
Maybe it was something to do with BT's own routing?
From what I can gather, my connection is actually routed via PlusNet's London servers, despite being around 200 miles away.

[Bald_Eagle1]

When my connection was interleaved yet I was able to achieve around 30 Mbps sync speed, I used to see many thousands of FECs per hour, never mind per day.

The connection was very stable though & would remain in sync for quite a few days at a time.


Since then, I have seen significantly increased crosstalk (noise), yet my connection eventually had all interleaving removed & albeit at lower speeds, FECs are still present, but now at quite low levels.

[Bald_Eagle1]

Hey NS.

Have you deleted your post regarding noise & FECs or have I replied in the wrong thread?