Print

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

[rbel]

Grateful for some advice.  I have just replaced the OR issue ECI modem with an unlocked HG612 (and noticed an immediate drop in performance) but cannot get DSLstats to function with the Huawei - it indicates that there is 'no response from the modem/router'.  I took my Billion7800n out of the picture, created a new connection to the modem and it provides working access to the net but not DSLstats.

[roseway]

I believe that this is to do with the port binding in the HG612 when it's operating in bridge mode. I don't have a VDSL2 connection myself, so I'm vague about the details, but I believe that you have to connect the router to one ethernet port and the machine running the monitoring program to the other port. Hopefully someone else will be able to clarify this.

[Bald_Eagle1]

With the unlocked HG612 in its default configuration, it simply acts as a bridge.

i.e. connected to the router via both the HG612's LAN1 & LAN2 ports.

That's how my connection operates


Alternatively, it can be connected to the router via LAN1 for normal internet access (as per 'locked' condition) & connected directly to a PC via its LAN2 port.


With both HG612 ports connected to the router, the internet & the modem's stats can be accessed at the same time by any PC over a network via the DSLStats and HG612 Modem Stats programs (running together if required).



HTH.

 

[roseway]

Thanks for that information BE1.

[rbel]

BE1  many thanks.

Here are the first set of stats - my immediate impression is that snr is very low and CRC too high but I would be grateful for more experienced interpretation of the figures.

[rbel]

I should have mentioned that with ECI modem I have been getting 12 Mbps down for some weeks but exchanging it for the unlocked HG612 produced an immediate drop to 8.4 Mbps.

[Bald_Eagle1]

Hmm.

That's unusual.

from your PbParams data - Discovery Phase bandplan, I see you are connected to an ECI DSLAM.

From remote observations of other similar long connections, we usually see a slight speed improvement when using a HG612.


SNR/SNRM is indeed currently very low. It must have been higher when your connection synced at 9002 Kbps some 10 hours or so before you grabbed the stats (AS:  37213 - Available Seconds) as attainable rate has now dropped to only 7008 Kbps due to the reduced SNRM levels:-

Max:   Upstream rate = 553 Kbps, Downstream rate = 7008 Kbps
Path:   0, Upstream rate = 583 Kbps, Downstream rate = 9002 Kbps

CRC errors are quite low for that duration (CRC:      65      0)


Your connection is currently on fastpath:-
D:      1      1

I wouldn't be at all surprised if DLM kicked in some time soon & applied Interleaving, which is likely to reduce sync speeds.


Maybe it's too early to say yet, but do you know whether or not SNR levels fluctuate a lot during a given 24 hour period?

The target SNRM for VDSL2 connections is 6dB.
Resyncing at 6dB is also likely to lower your sync speeds in order to try to maintain a 'suitable' margin.

SNR/SNRM hardly fluctautes day or night on my connection & it could easily maintain stability & increased speeds at 3dB.
However, that currently isn't an option for VDSL2 connections.


Finally, I can see that your HG612's firmware hasn't yet had the OCtober 2013 firmware update applied.

Unless you have blocked firmware updates, it's likely to be updated within the next few days.

The HG612 firmware update does appear to slightly improve performance & stability on longer connections, despite seeing increased error counts & increased bitswapping (particularly DS).

The big gap in your bitloading graph is due to really high US Line attenuation in the U1 band, that high that no signal is able to get through for that band.

Is there any evidence of a bridged tap in your Hlog graph?


I have attached montages from another long connection using a HG612 on an ECI DSLAM (before & after the bridged tap & a split pair were removed).

The improvement is quite dramatic.

[rbel]

BE1

Many thanks for the response.

Here is a second batch of stats, this time including an Hlog graph.

The speed rates seem very similar, the snr is still very low and the connection still appears to be on fastpath.

Each time I have checked the snr levels have shown very little variance, with down figure getting no higher than 3.0.

I am not aware of blocking firmware updates.

The Hlog graph doesn't show any spikes - would I be right in assuming that this means that there is no bridged tap present.  As a matter of interest I have been unable to complete a full BTW TAP3 test despite trying many times - BT are supposed to be running a remote test with me next week.

Can any conclusions as to the line condition and connection constraints be reached based on these current stats or is necessary to carry on monitoring for a period of time before a pattern emerges?

[Bald_Eagle1]

If you could copy & paste all the data from these tabs into a single text file via Notepad (not a word document), zip it to a smaller size & post here, I could take a closer look at the raw data & plot it in a format that I'm more famliar with:-

Connection Stats
Bitloading
pbParams
QLN
Hlog
SNR


(See the attached example that I have just grabbed from DSLStats from my own connection)

[rbel]

BE1

Sorry to be a nuisance but where are the data text files saved - my AppData\Local\dslstats folder just contains the graph png files, dslstats.ini, errors.dat, es.data, eventlog0.txt and traffic.ini.

I have the data headings you refer to checked in Snapshots>Autosave text pages.

[Bald_Eagle1]

As per my screenshot - DSLStats_screenshot.png.

What I did was to drag over all the text in the relevant tab to highlight it, copy it & then paste it into a new text document, working my way through the tabs that I had listed.

[rbel]

BE1

Apologies, I was looking for a series of DSLstats generated text files.  Here is the zipped txt file.

[Bald_Eagle1]

I have plotted the data you sent (attached for reference), but it appears that some of it is missing from the Bitloading & SNR sections.
Hence the 'odd' appearance of those graphs.

I don't know if Eric's program only reports particular 'useable' tones' data for those elements or perhaps you didn't manage to copy all of it.
Alternatively it could be some sort of issue that your modem isn't actually reporting on all the tones data.

Strictly speaking, there should be data for all 4096 tones (0 to 4095), even if it is zero values.

Could you double-check that you had actually copied all the data present & resend it if you discover that you had missed some of it?




I have inserted zeros for the missing data & re-plotted it (also attached), but we don't yet know for sure that the missing values were actually all zeros.

Your QLN & Hlog data is all there though & from that we can see that although a little 'spiky', QLN is generally low (which is good), but Hlog (attenuation) is quite severe. However, there is no significant evidence of harmful bridged taps etc.

The data suggests you are possibly around 1600m from the cabinet.
Do you know the actual distance?


There's every chance that your HG612's firmware will be remotely updated soon.
That may bring some improvement, as it does seem to improve performance & stability on longer lines.

You have 143 errored seconds over the 1 day 8 hours connection time, which isn't too bad for a less than perfect fastpath connection & all your other error counts (FEC, HEC, CRC etc.) are remarkably low or zero values.

Although all the band plan tones are there as Discovery Phase:-

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


your connection is only able to use a few of them at Medley Phase:-

Medley Phase (Final) Band Plan
US: (0,95)
DS: (32,859) (1216,1959)

That's not unusual for a long connection length, but the original, non-updated firmware reports all the tones for useable bands, whereas the updated firmware only reports the tones that were useable when the connection had trained up from cold or from a resync.

Overall & depending on the actual length of your connection, everything apart from the really low SNRM values looks relatively good.

SNRM must have been higher when the connection resynced as DS Attainable rate is now only around 7Mbps, whereas an actual DS sync speed of 9 Mbpd was achieved.

This does suggest that SNRM has either gradually or suddenly lowered to the current 3dB.

Target SNRM for VDSL2 connections is 6dB, so connections usually sync at around that value.

Rebooting the modem during daylight hours (around noon) may show around 6dB SNRM.
It might be a good idea to try that & immediately grab all the relevant stats.





If your connection is significantly less than 1600m in length, it would appear that you have a serious problem somewhere.


I'm not sure for how long a period DSLStats can store ongoing data.

If you felt so inclined, you could try my HG612 Modem Stats program that can store many, many months worth of ongoing & snapshot data, sampled every minute for longer term monitoring of changing performance/conditions, but it does need to run 24/7 during the monitoring period to be worthwhile & meaningful data.

[roseway]

I don't know if Eric's program only reports particular 'useable' tones' data for those elements or perhaps you didn't manage to copy all of it.
Alternatively it could be some sort of issue that your modem isn't actually reporting on all the tones data.

The data in those text files is the raw data directly from the the modem in response to the CLI commands shown.

[Bald_Eagle1]

So the text displayed in the relvant tabs will ALWAYS actually include data for all tones from 0 to 4095?

It certainly did when I copied & pasted it from my own connection.


It does 'appear' that rbel didn't quite manage to copy all of it then.