Print

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

[mikehiow]

So a few weeks ago my sync dropped from 80mbps all the way to 40mbps before settling at 59,996kbps.

I reported a fault which prompted an engineer visit which consisted of a few tests and concluding with a lift and shift.

This put me back at 80,000 sync for around 24 hours before the line dropped back to 59,996kbps again, this happened at exactly 7.02am yesterday morning. The odd thing is that max attainable is up at over 90,000!

Some stats between the drop - PPPoE didn't seem to drop at the time.

https://docs.google.com/spreadsheet/ccc?key=0AlG7Pd0m_By8dDFlM0pQUUtNczhFMzVnbDNmRHlqTUE&usp=sharing

I don't think anything has changed internally - I'm currently using a ~10m CAT5 to extend the router into under my stairs where there is a UPS, but I'm using RJ45 plugs each end on solid core cable. I think I'm going to crimp the cable directly into the faceplate and put a socket at the other end to be sure.

Any suggestions?

[mikehiow]

Few more stats with HG612 connected

Code: [Select]

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max:    Upstream rate = 30579 Kbps, Downstream rate = 91324 Kbps
Path:   0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
Medley Phase (Final) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      30579 kbps         91324 kbps
Actual Aggregate Tx Power:        1.8 dBm          12.7 dBm
============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  0.1     14.2    21.5     N/A    8.2     18.8    30.1
Signal Attenuation(dB):  0.1     14.0    21.5     N/A    8.2     18.8    30.1
        SNR Margin(dB):  13.2    13.1    12.6     N/A    14.4    14.3    14.5
         TX Power(dBm): -4.7    -46.1    0.8      N/A    8.7     7.3     7.4
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max:    Upstream rate = 30558 Kbps, Downstream rate = 91324 Kbps
Path:   0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps

Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        14.4            12.6
Attn(dB):        0.0             0.0
Pwr(dBm):        12.7            1.8
                        VDSL2 framing
                        Path 0
B:              239             236
M:              1               1
T:              64              5
R:              0               16
S:              0.1273          0.3771
L:              15081           5410
D:              1               1
I:              240             255
N:              240             255
                        Counters
                        Path 0
OHF:            669451          223186
OHFErr:         0               0
RS:             0               1615026
RSCorr:         0               0
RSUnCorr:       0               0

                        Path 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    157875671               0
Data Cells:     2373262         0
Drop Cells:     0
Bit Errors:     0               0

ES:             0               0
SES:            0               0
UAS:            22              22
AS:             1369

                        Path 0
INP:            0.00            0.00
PER:            2.03            6.12
delay:          0.00            0.00
OR:             90.32           203.67

Bitswap:        1               0

#


[Bald_Eagle1]

You seem to have plenty of spare SNRM for higher speeds & Interleaving is still OFF.

However, DLM must have seen something that made it decide to band your DS to 60 Mbps sync speed.
This could have been a few bursts of noise/interference etc. or even BT working on the line, perhaps unwittingly causing many disconnections that made DLM believe the connection was unstable.

If I'm not mistaken, you generally use an unlocked ECI modem for your connection to an ECI DSLAM & have developed a graphing program/programs.

Do you see any evidence of 'issues' during the period you were using the ECI modem?

As the lift & shift / DLM reset/re-calculation only provided a temporary respite, I would suggest you monitor the connection 24/7 for a few days.

DLM usually takes action between 04:00 & 06:00 to fine tune the speed/stability balance, so the fact that it took action at 07:02 suggests there may have been a sudden & unexpected issue.

Do have a record of the Retrain Reason from the 07:02 resync?

A minor DLM 'on the fly' adjustment usually reports Retrain Reason 2 & a complete loss of signal as Retrain Reason 0.

Connecting the HG612 would have obviously caused a complete loss of signal & the lower banded DS sync speed may just mask the issue to an extent (i.e. generally lower error counts).

If the issue(s) do continue, I would expect DLM to apply interleaving over the next day or so.

If your current monitoring/graphing programs are specifically written for the ECI modem & if you don't already have it, I would recommend using the HG612 monitoring package available here:-

http://www.freewarefiles.com/HG612-Modem-Stats_program_84567.html

[mikehiow]

I had only been monitoring the ECI each minute - line state was Showtime at 7.02 (80k) and at 7.03 (60k) so I missed the retrain completely, I believe. I don't think there was a total loss of sync though, as PPPoE managed to stay up.

I didn't catch it the first time it dropped from 80-60 as I hadn't bothered to setup routing the management IP through my router since moving to Tomato. I'm not logging anything like Retrain reason from the ECI though, it's not something I've found.

I can check out the logs around the time I the speed dropped in terms of SNR/Gain/Bit loading/HLOG if I add some kind of time scroller to my app - any idea what I'm looking for or another way of visualizing the data?

I do indeed already have modem stats installed and running with default settings - is this sufficient, or should I be configuring more?

I only connected the HG612 last night to get the more extensive logging/stats of modem stats.

[Bald_Eagle1]

I do indeed already have modem stats installed and running with default settings - is this sufficient, or should I be configuring more?

I only connected the HG612 last night to get the more extensive logging/stats of modem stats.

What are the contents of your HG612_stats.ini file?

These are mine that generate daily Ongoing stats graphs at 06:00 (usually picks up any early morning 'normal' DLM initiated resyncs), along with snapshot data graphing every 8 hours, starting at 06:00 each day:-

Code: [Select]


[Login]

IP_address= 192.168.1.1
Username= admin
Password= admin
Shell= sh

[Locations]

Main_folder= C:\HG612_Modem_Stats
Scripts_and_Programs= C:\HG612_Modem_Stats\Scripts
Apps_folder= C:\HG612_Modem_Stats\Apps
Current_Stats_folder= C:\HG612_Modem_Stats\Current_Stats
Ongoing_Stats_folder= C:\HG612_Modem_Stats\Ongoing_Stats

[Mode]

Mode= extensive

[Graphing]

Pause_after_obtaining_snapshot_data= NO
Auto_graph_Snapshot_data= YES
Pause_after_snapshot_graphs_plotted= NO
Pause_after_ongoing_graphs_plotted= NO
Plot_area_background_colour= 31
Daily_Graphing= YES
Daily_Graphing_Time= 06:00

[Delays]

Delay_snapshot_data_harvest_seconds= 10
Delay_ongoing_data_harvest_seconds= 0

[Logging]

Ongoing_Logging= YES
Current_Stats= YES
Current_Stats_Interval= 8                 
Current_Stats_Datum= 06



HG612_stats ini settings can be edited manually or set via the Settings editor.

If you do go for scheduled logging/graphing, ensure any pauses are set to NO - to avoid unattended & invisible logging/graphing waiting for a user's key press.

You can also manually run graphpd.exe & HG612_current_stats.exe at any time for ongoing/snapshot logging/graphing respectively.

A RESYNC.LOG should also be updated each time a resync is detected.
The version you have doesn't record the Retrain Reasons in the log (an updated version, when eventually released does).
However, Retrain Reasons are recorded in the current/snapshot data Plink logs.

You may wish to use the attached GRAPH6.exe program instead of the version included in the download as it does report connection uptime between resyncs & total bitloading in the Bitloading graph for US, DS & 'Shared' tones.

[mikehiow]

Thanks!

I don't seem to be getting any ongoing stats though, despite letting it setup the scheduled task and enabling ongoing stats. Graphpd complained there is no log file in Ongoing_Stats folder.

My ini

Code: [Select]

[Login]

IP_address= 10.1.7.2
Username= admin
Password= admin
Shell= sh

[Locations]

Drive= C:
Main_folder= C:\HG612_Modem_Stats
Scripts_and_Programs= C:\HG612_Modem_Stats\Scripts
Apps_folder= C:\HG612_Modem_Stats\Apps
Current_Stats_folder= C:\HG612_Modem_Stats\Current_Stats
Ongoing_Stats_folder= C:\HG612_Modem_Stats\Ongoing_Stats

[Mode]

Mode= extensive

[Graphing]

Pause_after_obtaining_snapshot_data= NO
Auto_graph_Snapshot_data= YES
Pause_after_snapshot_graphs_plotted= NO
Pause_after_ongoing_graphs_plotted= NO
Plot_area_background_colour= 31
Daily_Graphing= YES
Daily_Graphing_Time= 06:00

[Delays]

Delay_snapshot_data_harvest_seconds= 10
Delay_ongoing_data_harvest_seconds= 0

[Logging]

Ongoing_Logging= YES
Current_Stats= YES
Current_Stats_Interval= 8   
Current_Stats_Datum= 06


[Bald_Eagle1]

Thanks!

I don't seem to be getting any ongoing stats though, despite letting it setup the scheduled task and enabling ongoing stats. Graphpd complained there is no log file in Ongoing_Stats folder.

Are you using Windows 8?
There does appear to be a bit of an issue with its Scheduled Tasks program.

There may be some clues in ERROR.LOG that should be constantly updated (stored in the Ongoing_Stats folder).

You could always try runing HG612_stats.exe manually & capturing the screen output to discover where things go wrong.



EDIT:

Another thought - If you have a 'stuck' HG612_stats.exe process (or a number of them) in Task Manager, end the process (or even reboot the PC to clear everything).

[mikehiow]

I tried playing with the task etc. to no avail. A reboot fixed it in the end

[mikehiow]

I got some errors today. They happened around the time I went out and would probably coincide with the washing machine spinning.

I've no idea if these are considered high or not? It also looks like there may have been a resync?

Click for full size.

[mikehiow]

I've just put another wash on to see if I get the same pattern, but the modem is powered via the UPS, so I wouldn't have thought there should be too much of an issue with noise on the mains.

[Black Sheep]

Where do yo :lol:u live, Mike ?? I'll bring my washing round, whilst investigations are being carried out. 

[mikehiow]

Well, that theory has been debunked - not even a hint of errors this time.

[Bald_Eagle1]

I got some errors today. They happened around the time I went out and would probably coincide with the washing machine spinning.

I've no idea if these are considered high or not? It also looks like there may have been a resync?

So, the washing machine is ruled out then.

The errors reported so far don't look too bad.

Can you confirm the Retrain Reason?

I imagine RESYNC.LOG wasn't updated & a RESYNC Plink log wasn't generated as sync speeds were no doubt identical after the resync, being on a banded profile & your connection otherwise capable of higher sync speeds (plenty of spare SNRM).

I would keep the monitoring going 24/7 for now, just in case any patterns develop or massive error bursts are recorded etc.

Whatever it is, looking at error seconds, it does seem to affect both US & DS at the same time, which is slightly unusual.

The FULL_MONTY montage provides a little more information.
Is there anything showing there coinciding with the resync?

[mikehiow]

Retrain reason 2 on the scheduled current stats at 10pm. You're correct on the resync.log - nothing noted for the time shown on the uptime graph.

The only correlation I noticed was a downwards spike in snrm and the retrain seems to be as it starts to creep back up again.

Full monty here: http://vxr.in/share/line_stats__FULL_MONTY_P-20130722-2105.png

[Bald_Eagle1]

These are apparently the Retrain reasons:-

Retrain Reason Los Detector           0
Retrain Reason Rdi Detector           1
Retrain Reason Negative Margin        2
Retrain Reason Too Many Us FEC        3
Retrain Reason CReverb1 Misdetection  4

When DLM initiates a resync on the fly (very quickly), the reason is usually 2 i.e. there is no Loss of Signal as such, which would be Reason 0.
I can only imagine that SNRM dropped dramatically between data samples & thus a resync ensued.


I might change how resyncs are detected by the program.
Currently it checks for changes in sync speed (US and/or DS).
That method obviously hasn't worked as your sync speeds seem to have remained unchanged.


Interleaving is OFF on your connection for both DS & US, yet US RSCorr errors (FEC) are being recorded.

FEC errors are not usually recorded when interleaving is OFF.
Asbokid explained why that can happen & I can't quite recall his explanation now.


Looking at US SNRM (near the bottom of the montage), it looks quite messy, particularly in the U0 band & it hasn't recovered yet.

I'm not sure what that points to, but it may just indicate some sort of line fault?
It may even have been the cause of the resync?

It's certainly worth watching for the next few days.