Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Bald_Eagle1 on January 18, 2012, 10:48:23 PM
-
Along with the current Linux graphing script, a set of recently released scripts (batch files) are now also available for Windows only users to harvest & graph their UNLOCKED Huawei HG612 modem's connection statistics via this link:-
Huawei HG612 Graphing Scripts (https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4)
The batch files, full setting up instructions & details of / links to the other freely available Windows versions of a few additional programs / utilities that are required are all included in the zip file "hg612_wingraphs.zip"
These are the details from the summary of what the batch files actually do - "hg612_wingraphs_SUMMARY.TXT":-
WINDOWS ONLY HUAWEI HG612 STATS COLLECTING and GRAPHING BATCH FILES
PUBLIC RELEASE v1.0
Dated 15/01/2012
These WINDOWS only batch files, along with a few other utilities that need to be downloaded and installed, will allow you to generate relevant graphs for the Huawei HG612 modem's connection stats, simply by double clicking the relevant batch file icons.
They have been developed and converted to batch files from the original Linux script (Graph.sh) by Bald_Eagle1, with much assistance and advice from asbokid and burakkucat.
There is no need to install any Linux shells such as Cygwin, Ubuntu etc, as the batch files already use native Windows versions of the most popular Unix utilities.
A set of default folders & subfolders will be created on your C: Drive.
However, these locations can be altered, along with amending the HG612 modem's default IP address to suit individual requirements by easily editing a couple of lines of code in the batch files.
Once fully set up, the relevant data will be harvested & logged, either automatically via Windows Task Scheduler (every minute 24/7), or by double-clicking a batch file icon.
There is no need to be manually logged into the HG612 modem, or to manually run a Telnet session as auto-login & collection/dated storage of the relevant data is built in.
The batch files are initially set to use Windows 7 fonts and font sizes.
However, they have also been fully tested using Vista & will PROBABLY work in XP.
For some text data to display fully, a quick edit near the top of of GRAPH6.BAT will reset the fonts for Vista.
(Possibly the same fonts and sizes as used in Vista are used in XP)
To start the setting up process, simply extract all the files included in hg612_wingraphs.ZIP to any folder of your choice and double-click START.BAT
INSTRUCT.TXT & README.TXT can be read before starting the setting up process, but they will also be displayed again during execution of START.BAT
Full details of other required downloads, & links to them are included
PLEASE MAKE SURE THAT 32 BIT VERSIONS OF ANY PROGRAMS ARE DOWNLOADED, EVEN THOUGH WINDOWS 7 IS A 64 BIT OPERATING SYSTEM
DISCLAIMER:
No warranty regarding the use of these batch files is given or implied
The use of these batch files is entirely at the user's own risk
Apart from setting Windows Task Scheduler to run every minute (can be disabled if no longer required) and editing your Environment PATH, no permanent system changes are made.
Paul.
-
b*cat would like to suggest that Mr Eagle investigates the usage of external links for situations like --
. . . & graph their Huawei HG612 modem's connection statistics via this link:-
https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4
It would be so much easier on the eye to insert [url=] [/url] tags, such that the above abomination then becomes something like --
. . . & graph their Huawei HG612 modem's connection statistics via this link (https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4).
But I guess that is the result of not having any feathers "up top"! :lol:
-
Hi b*cat,
b*cat would like to suggest that Mr Eagle investigates the usage of external links for situations like --
Thank you for pointing out the error of my ways (and citing an example).
I have now edited my post accordingly to how I wanted it to look in the first place. I hope you now approve of it.
I'm afraid I had got used to the little helpful box that pops up in the other forum when inserting links & had forgotten how to do it manually.
But I guess that is the result of not having any feathers "up top"! :lol:
Hmmmm, I'll treat that remark with the contempt it deserves (for now) :-\
-
Hi b*cat,
b*cat would like to suggest that Mr Eagle investigates the usage of external links for situations like --
Thank you for pointing out the error of my ways (and citing an example).
I have now edited my post accordingly to how I wanted it to look in the first place. I hope you now approve of it.
Absolutely purrfect. ::)
But I guess that is the result of not having any feathers "up top"! :lol:
Hmmmm, I'll treat that remark with the contempt it deserves (for now) :-\
That's fine by me, as my friends, the Liverbirds, will provide me with lifelong support and protection from molestation by any little avian entity! ::)
-
Please note that the downloadable zip file was updated yesterday (19th January).
The only change is a slightly amended version of GRAPH6.BAT
The amended version is only really of any use if wishing to re-plot older 8c connection snapshot logs that didn't originally include the specific profile detail, using different colour Band Plan bit-loading.
It now attempts to determine the older 8c profile from just the pbParams Band Plan data (8c - 2000 tone x-axis) rather than defaulting to the 17a - 4100 tone x-axis as an undetermined profile.
-
Good work and thanks for the update.
-
Update 22/01/2012:
A couple of example log files have now been uploaded to the main download location:-
Huawei HG612 Graphing Scripts (https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4)
Plink_20120121-0031.log contains the Current (snapshot) data.
modem_stats.log contains the Ongoing data.
Users could now plot the 2 graph sets from these example log files if they wished to test things out BEFORE going to the trouble of unlocking their modems.
Please note that these example logs have been harvested from a poor(ish) connection, so at least there a few error counts, re-syncs, fluctuating SNRM & Interleaving depth graphs to have a look at.
-
. . . these example logs have been harvested from a poor(ish) connection, so at least there a few error counts, re-syncs, fluctuating SNRM & Interleaving depth graphs to have a look at.
That reads as if it is an example of the connection to "The Aerie". ::)
-
That reads as if it is an example of the connection to "The Aerie". ::)
It can't be. "The Aerie's" connection is apparently stable & within acceptable limits.
-
It can't be. "The Aerie's" connection is apparently stable & within acceptable limits.
:tongue: :-\ :no:
-
Update 28/01/2012:
Despite trying many times, I have been unable to get the HG612 to synchronise with any online time servers.
I have been manually setting the modem’s internal time (used for it’s built-in logs) by running PuTTy to access the sh shell, working out the time & date format & entering something at the prompt on the lines of:-
date -s 121808182011.36 (MMDDhhmmYYYY.s)
to get this result:-
Sun Dec 18 08:18:36 UTC 2011
The modem’s internal ongoing time is maintained following “on the fly” re-syncs but is lost following a reboot / power cut etc.
To speed this up, I have now added another batch file named SET_HG612_DATE_AND_TIME.BAT to the main download zip file.
If setting up the batch files from scratch, this new batch file will be already included in the default Scripts folder ( C:\HG612_Modem_stats\Scripts )
If already fully set up, simply extract SET_HG612_DATE_AND_TIME.BAT to the Scripts folder.
A double-click on this new batch file will automatically pick up the Windows system time, add a few seconds to allow for auto-login to the HG612 & processing time, reset the modem’s internal clock & quit.
There is no need to be logged in to the HG612’s GUI, although no harm is done if you are already logged in.
The resulting time reset isn’t exactly correct (it might end up a few seconds out), but it’s near enough.
It’s certainly a lot closer than some date in the year 2000 that is normally recorded in the in-built modem log.
Paul.
-
Update 29/01/2012:
I have now added some setting up instructions that include some screenshots to the main download zip file (hg612_wingraphs.zip):-
These instructions are named Setting_Up_Instructions.pdf
The PDF file can also be viewed/downloaded on its own at the main download site:-
Huawei HG612 Graphing Scripts (https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4)
-
Update 12/02/2012:
I have now checked out the licence & copyright terms & conditions for all the components.
It appears that I can now package everything together in one download zip file.
I have also been putting together a very simple to use setup procedure.
Basically, after downloading one file & unzipping it, a double-click sets everything up for plotting "snapshot" graphs.
For the time being, full versions of the other programs/utilities are included.
This could be useful as they can be used for many other purposes.
The downside is that together they take up quite a bit of disk storage space.
At some stage, I might release a "Lite" version that includes just enough for HG612 graphing purposes, but that might not be too soon.
Another double-click now sets up Windows Task Scheduler to harvest statistics 24/7 (optional).
A couple of other clicks ensure Task Scheduler is set for different Windows versions & password implications.
Another double-click stops the 24/7 logging whenever it is no longer required.
I have chosen not to automate the graphing itself, as not everyone would wish to plot graphs all the time & some would wish to plot them at events such as modem re-syncs/reboots etc.
It just takes a double-click whenever graphs are required.
I hope to release the simplified setup file(s), along with some included updates to the existing scripts, during next week, following a little more testing to ensure compatibility between Windows versions XP, Vista & Windows 7.
-
I read excellent "stuff". :clap2:
However I will never use it, as I do not have an FTTC service not do I use anything from the Redmond company. :no:
-
Update 20/02/2012:
The new simplified setting up process, along with updated batch files (HG612_wingraphs.zip) has now been uploaded to:-
Huawei HG612 Graphing Scripts (https://docs.google.com/leaf?id=0B6wW18mYskvBMTEyNzk2MTQtNWEyNC00NTBlLWFiMjYtNTg0MDdhMTBlNDdk&sort=name&layout=list&pid=0B6wW18mYskvBODZjMTk1YmUtZDA0ZC00Y2NlLWEwYWItMjEyNmRjNTk0MWU5&cindex=4)
After downloading the zip file, the whole process now only takes a few minutes.
Please also see “Setting_Up_Instructions_v2.pdf” which is located on the same web page as the download.
For future reference it is also included in the download zip file.
For a quick start, unzip HG612_wingraphs.zip into any folder of your choice & double-click “START.BAT”.
Everything will be initially set up on your C: drive & ready for you to generate “snapshot” graphs by double clicking “Teststats2.BAT” which is located in the folder named “C:\HG612_Modem_Stats\Scripts”.
You may also wish to set the HG612 modem’s internal clock (used for its own inbuilt event logs).
If so, double-click “SET_HG612_DATE_AND_TIME.BAT”, also located in the folder named “C:\HG612_Modem_Stats\Scripts”.
This isn’t necessary for the graphing scripts as the Windows system time is used throughout, but it COULD be useful for cross-referencing re-sync / reboot events etc.
To optionally start/stop 24/7 every minute logging of connection stats & graph them, double-click START_LOGGING_24-7.BAT or STOP_LOGGING_24-7.BAT which are also located in the folder named “C:\HG612_Modem_Stats\Scripts”.
For these scripts to function, the HG612 modem obviously has to be “unlocked” & switched on.
For optional 24/7 logging, the PC also needs to be switched on & “active”.
The scripts have been successfully tested by me (both Ethernet connected & wirelessly) on a “reasonable” spec Windows 7 desktop PC, an old & slow Vista laptop & an almost obsolete Pentium 3 XP desktop PC running at 733MHz, with only 256MB of RAM.
The differences in processing times are noticeable, but the output graphs are identical.
A small number of other users have also tested the scripts on various specs of PC.
Please provide any feedback either publicly in this forum or via a PM.
Perhaps more importantly, please post links to the montage graphs for us all to have a look at & compare against other stats.
Initially, all the graphs are generated in “low” resolution to speed up processing time & keep output file sizes as low as possible.
With a quick edit of a batch file, a couple of “high/medium” resolution graphs can be generated.
This aspect is NOT yet fully implemented.
If/when it this facility is required, I may add an option for users to choose the resolution immediately before generating the graphs.
-
I read more excellent "stuff". :thumbs:
[ot]
Now that you have publicly released the revised and simplified graphing scripts, etc. for 'doze, does it mean that Mrs Eagle will finally be getting her promised new kitchen and utility room? ;D
[/ot]
-
Haha,
It's either that or we will have to sell the house as it is to pay for the Divorce lawyers :no:
-
I'm afraid I had got used to the little helpful box that pops up in the other forum when inserting links & had forgotten how to do it manually.
Use of the button (https://forum.kitz.co.uk/Themes/KitzBlue/images/bbc/url.gif) may be of help when it comes to using and remembering the codes for links. That particular button will automatically insert the url tags.
Theres a few more that can be found up above the emoticons on the page when making a post.
Hope this helps :)
-
My simplified setup routine seems to have gone down well Paul. I've not seen anyone complaining about setup times of late. :clap:
-
It has indeed Darren.
Remember the guy back then (who will remain nameless) who said it took him 18 hours to get the first public release working? :lol: :lol:
I know I was a little reluctant at first, but I'm really glad you kept on at me & did all the hard work (not forgetting all the testing of Task Scheduler scripts on XP etc.) to push me into making the right decision :)
-
Interactive graphing alternative using Bald_Eagle's logfile
I have been using Bald-Eagle's very helpful statistics gathering for the HG612 for some time.
However, I did find the associated graphing rather laborious. I have put together an interactive graphing package that works off the same modem_stats.log file he generates. It operates from a modern web browser: Chrome, Opera, Firefox and IE 10 tested (IE slow to load the data). The fast Dygraphs package does the real work ( http://dygraphs.com/index.html )
You can try it by visiting http://programbits.co.uk/modemGraph/plotstats.html and pointing it at your log file. Internet security rules mean it is a few (very easy) steps to load the data initially; but you can then easily zoom in and out, change details plotted, etc.
For now, if you have any comments/issues etc please post them on http://forums.thinkbroadband.com/technical/f/4185132-interactive-graphing-for-hg612-statistics.html#Post4185132 . I may arrange it in a more 'normal' repository at some point.
It currently consists of two files. plotstats.html contains the HTML and javascript source, and dygraph-combined.js the underlying graphing package.
-
does the modem have snmp so can collect stats remotely?
I have a cacti server for this sort of thing much better suited than a local windows box.
-
does the modem have snmp so can collect stats remotely?
I have a cacti server for this sort of thing much better suited than a local windows box.
Not sure what you mean about the modem having snmp.
I occasionally remotely monitor connections via LogMeIn (Windows 7 at my end & XP, Vista or Windows 7 at the other end).
If you can access an email server, a program named Blat (as just one example) can be used to email logs from the remote location & this can be automatically scheduled via Windows Task Scheduler & a simple batch file.
e.g. I have the remote connection's 24/7 Ongoing_Stats.log emailed to me at midnight every night & the snapshot Plink logs at 02:00 & 14:00 every day.
If I ever want/need additional logs etc. I can always login via LogMeIn, although once everything is all set up that isn't really necessary.
-
snmp is a daemon used on various devices wether they linux servers or network routers to collect stats.
The vast majority of commercial routers on the market (even consumer ones) will have this feature.
Its simple, light and allows stats to be collected remotely to be graphed.
Looking at google for the modem it suggests it does have snmp but its unclear if its configurable to work for remote access.
However thinking about it I realise now my question is stupid, since the modem itself wont have a WAN ip as its just bridging the connection to a router. So the router would have to forward a port to the modem snmp lan interface and then I think it could possibly work.
-
got this working now thanks.
Yesterday I had a 110meg attainable sync, today it dropped to 90 and I have had a burst of crc errors (probably when it changed), now the crc errors are very low again so its not an ongoing issue although I hope it wont make DLM throttle my line tommorow.
I made a graph plot on the bit signal and the left side of the graph looks damaged I will post it here.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.chrysalisnet.org%2Fhg612%2FSNR-20121214-1443.png&hash=0d8a733d4629ffc121c36d588c4d0f6dc1f58d73)
-
It looks o.k. from where I am sitting. Are you concerned about the 'valley' at about tone 250? If so, don't be. There is a complex output power 'mask' applied to minimise cross-talk, not only with other VDSL2 services in the same cable bundle but also the far weaker ADSL2(+) services that will also be present.
[ot]
I wonder if Mrs Eagle will have a fully restored renovated and refurbished house this Christmas? Or will Baldy Bird be spending his Christmas in the dog house again, just like last year? ::)
[/ot]
-
[ot]
I wonder if Mrs Eagle will have a fully restored renovated and refurbished house this Christmas? Or will Baldy Bird be spending his Christmas in the dog house again, just like last year? ::)
[/ot]
Woof, woof :no:
Some of it will be partially restored. I'm still at the plastering stage & Mrs. Eagle has invited loads of guests, just to spur me on a bit.
-
Woof, woof :no:
Meow (http://www.centos.toracat.org/ajb/tmp/kitten.wav)?
-
It looks o.k. from where I am sitting. Are you concerned about the 'valley' at about tone 250? If so, don't be. There is a complex output power 'mask' applied to minimise cross-talk, not only with other VDSL2 services in the same cable bundle but also the far weaker ADSL2(+) services that will also be present.
[ot]
I wonder if Mrs Eagle will have a fully restored renovated and refurbished house this Christmas? Or will Baldy Bird be spending his Christmas in the dog house again, just like last year? ::)
[/ot]
yeha I guess it was to help adsl services. However the situation has now changed, it seems I am the victom of some pretty severe crosstalk.
Initially I had a 110meg attainable sync and I thought I would be set for a lifetime 80meg sync with that kind of buffer, upstream also looked pretty healthy at 36mbit. I changed to 90mbit attainable the day after I unlocked my modem and the above graph was taken on that. This morning I had another large drop down to 73mbit attainable (which of course has now lowered my sync below 80mbit) and upstream attainable is now just 23mbit. Ok we all know crosstalk happens on vdsl2 and also documents I have read from vdsl vendors is that crosstalk can also be very severe at around 40% of lost dsl signal which is why vectoring is been developed to combat that, my concern however is reports from other users is when a neighbour gets vdsl installed they might lose a few mbit of attainable sync each time and the 40% accumulates over dozens of installs. For me I seem to have lost a whopping 40mbit of attainable speed in 2 weeks and for 2 installs.
Here is some new graphs now from today, notice the higher quiet line noise and the drop off on available snr on the higher tones that wasnt previously there. Also my upstream is now operating on lower output power. Apologies if these are too big I dont know how to shrink easily.
Now 73mbit
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.chrysalisnet.org%2Fhg612%2Fline_stats-P-20121222-1621.png&hash=22de595ed199cbb6b79140ea2a546955dea182e8)
Before 90mbit
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.chrysalisnet.org%2Fhg612%2Fline_stats-P-20121214-1443.png&hash=6f531dcfb02173cea29b32ca3bda325afd00bd17)
-
Here is some new graphs now from today, notice the higher quiet line noise and the drop off on available snr on the higher tones that wasnt previously there. Also my upstream is now operating on lower output power. Apologies if these are too big I dont know how to shrink easily.
I don't know what's caused the downward slide, but it seems quite severe.
Have you tried running the 24/7 Ongoing Stats harvesting/graphing?
FWIW, if you are interested, I have attached a newer version of GRAPH6.BAT that you could replace your current version with.
It produces smaller montages that can now be attached to messages in the Kitz forum & they present the data slightly differently.
-
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.
-
you see the graph you posted the QLN is around 120, on my 90mbit is also around 120, on my 73mbit its over 140.
-
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.
-
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.
-
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?
-
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 ???
-
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?