Print

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

[Chrysalis]

I have but I can tell you I check very frequently anyway and the snrm, attainable rates is actually quite stable, it fluctuates a few hundred kbit during the course of the day.  The drops in attainable rate are 2 single sudden large changes a week apart, the line is not jumping up and down.

All of it points to crosstalk on the evidence, and yes thanks for the batch file that makes smaller graphs.

[Chrysalis]

you see the graph you posted the QLN is around 120, on my 90mbit is also around 120, on my 73mbit its over 140.

[Bald_Eagle1]

Don't you mean the other way round?

My QLN is around minus 140dB, in your 90Mb graph it is around minus 140 & your 73Mb graph it is minus 120.

Minus 140 is quieter than minus 120 (i.e noise is more attenuated).

Also, remember that QLN & Hlog are only updated at a resync & that data remains static until the next resync.

Bitloading, attainable rates & SNR do continually fluctuate during the whole duration an ongoing connection though.

I also see that Retrain Reason is 1 for your 73Mb graphs.
On various users' connections I only usually see reasons 0 (reboot/power cycle) & 2 ("on the fly" resync - usually when DLM adjusts things).

I admit that I don't really know what reason 1 signifies, but I suspect it may be due to a "problem", rather than a DLM adjustment due to crosstalk.

On the very rare occasions where I have seen reason 1, it has been on connections needing some repair/adjustment of either external or internal cabling.
Once that work has been done, those connections have tended to stabilise at higher rates.


I just wonder if someone might have switched on their Christmas tree lights using a "dodgy" power supply yesterday.

Do you have any idea what time the reync happened yesterday & did it coincide with another user being connected?

It is just slightly feasible that the engineer may have unwittingly "disturbed" your connection during that installation.

It just seems too big a drop for it to be crosstalk.

[AndrueC]

I'm not having any luck getting the scripts to do anything unfortunately. I've had to edit them to change the IP address to .253 but the problem seems to be in the login process.

If I run SET_HG612_DATE_AND_TIME.BAT it enters 'admin' as the user name but then seems to issue another CR which results in a blank password rather than a second 'admin'. Something similar appears to be happening with other scripts.

This is a machine running Windows 7.

[Bald_Eagle1]

I use Windows 7

I have attached a version of SET_HG612_DATE_AND_TIME.BAT that definitely works.

You will have to edit the modem's IP address if not using 192.168.1.1

I have also attached a screenshot of how it should look.
(The password 'admin' doees indeed look blank, but it is actually used).

Just to check, can you get to the modem's GUI using your revised IP Address?

[AndrueC]

Yeah, I can log in just fine. In fact using the telnet statement from the batch file I can log in:

C:\HG612_Modem_stats\Scripts>..\Apps\Plink -telnet -P 23 192.168.1.253

Welcome Visiting Huawei  Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>^C
C:\HG612_Modem_stats\Scripts>

Edit: That's me typing in 'admin' 'admin' manually.

It just won't work if I run the batch file 

[AndrueC]

It didn't like the cr/lf pair in the files created with echo. I edited them to only leave cr and it works.

Unfortunately Getstats.bat doesn't work - it just complains that a file is being used by another process. I'm trying to track down why using sysinternals.

Edit: It was a stale copy of plink.exe - probably sat there confused after failing to log in. I think I'm running now but I don't know why my machine needed the lf stripping off the login text files. Something for the readme perhaps. The machine is running the x32 version of Win7 Professional.

How does this look:

[Chrysalis]

Don't you mean the other way round?

My QLN is around minus 140dB, in your 90Mb graph it is around minus 140 & your 73Mb graph it is minus 120.

Minus 140 is quieter than minus 120 (i.e noise is more attenuated).

Also, remember that QLN & Hlog are only updated at a resync & that data remains static until the next resync.

Bitloading, attainable rates & SNR do continually fluctuate during the whole duration an ongoing connection though.

I also see that Retrain Reason is 1 for your 73Mb graphs.
On various users' connections I only usually see reasons 0 (reboot/power cycle) & 2 ("on the fly" resync - usually when DLM adjusts things).

I admit that I don't really know what reason 1 signifies, but I suspect it may be due to a "problem", rather than a DLM adjustment due to crosstalk.

On the very rare occasions where I have seen reason 1, it has been on connections needing some repair/adjustment of either external or internal cabling.
Once that work has been done, those connections have tended to stabilise at higher rates.


I just wonder if someone might have switched on their Christmas tree lights using a "dodgy" power supply yesterday.

Do you have any idea what time the reync happened yesterday & did it coincide with another user being connected?

It is just slightly feasible that the engineer may have unwittingly "disturbed" your connection during that installation.

It just seems too big a drop for it to be crosstalk.

reason 1 is the retrain from when the attainable sync took a 20mbit dump.

Obviously if I am synced at 79999 and the attainable sync drops to 73mbit the sync will drop :p

since its been synced at 73mbit there has been no drop and likewise before was no drop.

So to make it clear there is no ongoing issues with the line, the line is actually very stable, I am still on fast path so DLM also sees no issue with it either.

The QLN test, a higher graph is more not less noise.  It even states this on the hg612 unlocking firmware site.

So to brief again.  The line has a very stable sync rate outside of 2 sudden rate changes  that both applied early morning around 10am a week apart that took large parts of the signal away.  It even barely variates from day to night. 

The snr graph is also telling my 73mbit graph looks like its a new different line, the pattern is different the signal quality noticebly dips like its higher attenuation, it all looks pointing to crosstalk to me.

[Chrysalis]

andruec I wonder if you getting this issue, I now cant login on my gui only telnet.

Login Failure: Duplicated Login.Please try later

Bald eagle when I get the login issue resolved on my 2nd machine in another room  I will get you some 24/7 stats.

[AndrueC]

I can still log on to my modem but I've stopped the scheduled task for now. Perhaps it's because the task has you logged in via Telnet and won't let you also log in via the gui.

[Chrysalis]

mine works now, I had to login again on this pc, then actually select logout as it doesnt allow login from 2 machines at once.

Its been logging for a few hours and I will post tommorow those graphs if not too busy.

[Bald_Eagle1]

It didn't like the cr/lf pair in the files created with echo. I edited them to only leave cr and it works.

Unfortunately Getstats.bat doesn't work - it just complains that a file is being used by another process. I'm trying to track down why using sysinternals.

Edit: It was a stale copy of plink.exe - probably sat there confused after failing to log in. I think I'm running now but I don't know why my machine needed the lf stripping off the login text files. Something for the readme perhaps. The machine is running the x32 version of Win7 Professional.

How does this look:

Mine's the x64 version of Win7 Home Premium.
I hope to release a new version soon anyway, using a compiled program that is far quicker to harvest the stats & more reliable.
It also graphs more data.

[Chrysalis]

I have some ongoing data now collated on my other pc, but it cannot for some reason generate current stats, but I have the ongoing.  as expected snrm and attainable rate pretty stable and get the odd sudden burst of crc's but the ongoing crc's (which is whats important and what DLM cares about are a trickle), I suspect the crc bursts could be down to using the hg modem on a eci dslam, the guy selling unlocked eci modems ran out so I ended up ordering a locked one which I expect will come after the new year now but maybe before if I am lucky.

[Bald_Eagle1]

It does indeed seem very steady.

It's a pity you don't have the ongoing stats right from the beginning as they MAY have helped to identify the cause(s) of the attainable & sync speed losses, which do still seem excessive (to me) for crosstalk to be the sole cause.

It's curious to see so many gaps in the data though.
One or two gaps could be expected, when the PC is very busy doing other things. But there seem to be rather a lot of gaps where I assume the data wasn't harvested for some reason.

One thing to mention is the higher error burst right at the start of the data collection.
That is probably from the cumulative data being continually harvested & compared with the previous minute's data.
If there wasn't a previous minute's data, it will incorrectly show as a large burst when the first "delta" data is plotted.
This has the effect of masking the true picture of the lower error counts due to the automatically adjusted scale of the graphs.

A quick solution is to simply delete the first row or two of data from the ongoing modem_stats.log 
True delta data is then reported.
However, due to the gaps in the plots, I suspect you currently have delta data for periods of more than one minute at a time, again slightly skewing the calculated data results.

One other point is that when plotting one day, it is assumed that all 1440 data samples are present.
Likewise when potting a number of hours, it is assumed that 60 samples are present for each hour being plotted.

It looks as though the data gaps in your plots mean that fewer than 1440 data samples were available for the 1 day plots.

That would explain the slight additional gaps to the far left & far right of the plots.

[Chrysalis]

I noticed you used the gui rather than telnet for fetching the stats which will be more problematic as that protocol wont be designed for that sort of use.  I expect login failures or throttling is occuring causing the gaps.

I can confirm the high errors at the start were pre accumulated but I do occasionally every several hours or so maybe once every 2 days or so get a burst of crc errors in one go, but its not a ongoing issue, I read it sometimes happens with hg modems on eci dslams.

The drops are on the back of my mind.

These are my thoughts and opinions are welcomed.

First it seems my line is nearer to 500m than 200m based on the attenuation reported by the modem which is around 10db on D1.  If it is 500m then my sync isnt that bad.
Second I do know official documents state crosstalk is brutal on vdsl2 and this is probably I expect why BT estimates are so low.

However on the other hand I cant drop the fact I started of with a 110/36 attainable rate and although this is estimated by the modem I can remember on a 79999/20000 sync I initially had a whopping 13db downstream snrm and similiar for upstream, then this after a week dropped to around 9db or so for the downstream (90meg attainable) but stayed the same on the upstream and then suddenly again to the current situation.  I power cycled my modem today and no difference.

Although over time I could have expected to be struggling to get 80meg, I admit it seems unusual for this sheer amount of lost signal in such a short space of time.  I am trying to find an excuse to get an engineer out without paying for it but I dont know what I can report as I am still over the estimated speed and the only unexpected 'los' I had is when the attainable changed from 90 to 73.

What are the chances my pair got swapped for a more undesirable pair? is there safeguards which stop engineers able to do this willy nilly?