Print

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

[jeffbb]

Hi
What could have caused it ?? ,not really able to say as BK suggests Xmas ligths is one of many possibilities . But this problem has not just started its been with you for a long time . When errors get very high that Bit swapping can no longer take place then a resynch is bound to happen . At that point the connection stats will be negotiated . so often as you have experienced Synch drops and SNR margin is reset to target.
quote I note that since the re-sync, my error count is much lower, but so is my sync speed, along with DS SNRM being somehat higher.
Your SNR margin had been less than the target due to some general noise on the line ,before the resynch

DS SNRM actually suddenly peaked at 8.1 dB some 16 minutes after the re-sync.
during this period  the general noise on the line dropped by a few dbs

It is currently running at 6.6 dB,
general noise on the line has increased slightly

but was typically running at an average of around 4.5 dB prior to this morning's re-sync.
that was with the higher synch rate

These sorts of changes are quite normal 2 to 3db  changes are quite normal the only problem is when yo have massive errors forcing a resynch.


Regards Jeff

[Bald_Eagle1]

Just a quick update:-

It appears that the BT supplied modem (Huawei HG612) incorrectly reports some of its statistics in its GUI, particlularly error counts.

It seems to get FEC & CRC errors mixed up with each other, & maybe neither of them are the "true" values anyway.

For now, I have started to graph exactly what is reported in the GUI, & also what is reported via the various xdslcmd info --xxxx commands from a telnet session (please see the attached 16 day graphs - apologies if it is hard to view without downloading it first).

Some of the completely blank parts of the graphs are due to the fact that I wasn't logging the relevent data at the time.

The error count appears to have reduced overall since the engineer's visit in mid-November, but the sudden bursts of various errors does occasionally cause a re-sync, which also adds / removes DS interleaving at various differing levels.
 
The sudden & large bursts of errors have masked out all the other less severe error counts due to the scale/size of the graphs.

The current totals for a 52 hour connection up time are:-

DS CRC 462902 (also reported as RSUnCorr via xdslcmd)
DS FEC 7197    (also reported as OHFErr via xdslcmd)
DS HEC 136565 (also reported as HEC via xdslcmd)

From looking at other users' FTTC connection stats (almost zero error counts across the board - a few hundred maximum), these error counts still loook excessive to me, indicating an ongoing & reportable D-side line "fault".
Of course, Plusnet don't see it that way as I am "currently achieving reasonable stability & my speeds exceed the estimated speeds".

Is it at all possible that something on my side of the BT modem could be causing the errors/re-transmissions, such as the router or my PC itself?


Paul.

[attachment deleted by admin]

[burakkucat]

Is it at all possible that something on my side of the BT modem could be causing the errors/re-transmissions, such as the router or my PC itself?

No. 

A simple test. Remove the Netgear router by physically disconnecting it. Connect your main desktop workstation to the Huawei HG612 modem's LAN2 port only, just so that you can monitor the statistics. Do without Internet access for 24 hours. Any usage of that VDSL2 link will be just the normal conversational dialogue between the Huawei DSLAM in the FTTC and the Huawei HG612 in your office. What do the statistics look like when you are not using the link?