Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on August 05, 2015, 07:40:23 AM
-
Consolidation of various small changes included in pre-release versions, plus a few more small changes.
Changes since v5.5:
v5.6
- the "Per sample" option under the FEC graph now works correctly (really)
- changed the sample timing when MDWS is enabled to avoid duplicate uploads
- when the event log gets to 500 lines, it's autosaved and cleared to start afresh
v5.5.4 (pre-release version)
- added VDSL2 support for Thomson TG589vn V3
- added MDWS upload capability for Thomson/Technicolor modems
- added extra checking and retries for failed telnet disconnects
v5.5.1 (pre-release version)
- the path to curl.exe in the Windows version is now explicitly defined (may help
with occasional curl related issues)
- three extra items are now optional in "Items to monitor" (disabling these may
help with data collection issues with certain modems)
- the "Per sample" option under the FEC graph now works correctly (NO!)
http://www.s446074245.websitehome.co.uk/downloads.html
-
Eric just installed this and all seems fine (Windows version)....
Stuart
-
Win 32 and rpi versions installed and running fine.
I have seen the following for some time but have not submitted the bug-report yet...
On the Huawei HG635 the plot of the SES is correct but the totals and averages are incorrect; see attachments.
Ian
-
Eric just installed this and all seems fine (Windows version)....
Stuart
Likewise... :)
-
Thanks all :)
@kitzuser87430: Yes, I agree that those averages are not correct. It's something I've been aware of for a while, but I haven't got to the bottom of it. The modem/router uptime averages are accurate, but the daily averages go wrong after a while. If you press the "Reset values" button, the daily averages will be OK for some time.
-
v5.6
- the "Per sample" option under the FEC graph now works correctly (really)
It really works :). Thank you.
-
Thank you for confirming it. :)
-
Have you thought about adding the US ES/hour: and can see there is some space just after the DS ES/hour it would save me clicking on the stats tab to see US errored seconds.
And only look into this if the majority of users request it.
-
DSLstats does show both up and down ES/hour. See below (I rarely see DS errored seconds, but I did get a few yesterday).
-
If you press the "Reset values" button, the daily averages will be OK for some time.
Have done
Thanks.
-
DSLstats does show both up and down ES/hour. See below (I rarely see DS errored seconds, but I did get a few yesterday).
The main page as seen below, i have highlighted the current DS ES/hour and highlighted were the US ES/hour could go.
-
I see now. I thought you were talking about the graph. I'll see if I can squeeze it in.
-
I see now. I thought you were talking about the graph. I'll see if I can squeeze it in.
You are not the first person that get's confused with my text in here, it must be my northern dialect that get's me into trouble but i am sincere.
-
Don't worry, I'm quite capable of being slow on the uptake. :)
-
In this version I've noticed bug on Netgear DGND3700. Sometimes, CLI Commnand Prefix changes from "adslcfg" to "adsl" on its own. As a result, I can't use DSLStats unless I change "adsl" to "adslcfg".
Furthermore, both versions DSLStats 5.5 and DSLStats 5.6 have a bug on "Attenuation log". It shows line attenuation under "Signal attenuation".
I suspect it would be helpful for Netgear routers if DSLStats use "adslctl info --show" instead "adslctl info --stats" - shorter output .
Best regards
konrado5
-
In this version I've noticed bug on Netgear DGND3700. Sometimes, CLI Commnand Prefix changes from "adslcfg" to "adsl" on its own.
I presume that you mean that it changes in DSLstats. I can't think of any explanation at present. There were no changes between v5.5 and v5.6 which could explain this. I will see if I can find any explanation, but I'm not hopeful.
Furthermore, both versions DSLStats 5.5 and DSLStats 5.6 have a bug on "Attenuation log". It shows line attenuation under "Signal attenuation".
Could you please post the output of 'adslctl info --stats' and also the contents of the DSLstats Stats page.
I suspect it would be helpful for Netgear routers if DSLStats use "adslctl info --show" instead "adslctl info --stats" - shorter output
I don't believe that the --show command returns all the needed information. There is a section at the end of the --stats command which is headed "Since Link time =...", and some items in that section are used when the section exists.
-
Could you please post the output of 'adslctl info --stats' and also the contents of the DSLstats Stats page.
Following there are outputs. I also attach Attenuation log screenshot. If I enable both: LATN and SATN monitoring, Attenuation log shows in reverse order (only on Netgear).
adslctl info --stats
adslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1237 Kbps, Downstream rate = 19988 Kbps
Bearer: 0, Upstream rate = 1237 Kbps, Downstream rate = 18335 Kbps
Link Power State: L0
Mode: ADSL2+
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 1.3 6.7
Attn(dB): 23.5 15.6
Pwr(dBm): 18.3 12.0
ADSL2 framing
Bearer 0
MSGc: 51 16
B: 217 37
M: 1 1
T: 3 3
R: 0 0
S: 0.3799 0.9744
L: 4591 312
D: 1 1
Counters
Bearer 0
SF: 1040144 7092
SFErr: 182 0
RS: 0 619010
RSCorr: 0 0
RSUnCorr: 0 0
Bearer 0
HEC: 265 0
OCD: 0 0
LCD: 0 0
Total Cells: 730474772 49282321
Data Cells: 4834698 618533
Drop Cells: 0
Bit Errors: 0 0
ES: 175 0
SES: 0 0
UAS: 0 0
AS: 16891
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 16.23 16.07
OR: 28.07 10.94
AgR: 18292.54 1243.14
Bitswap: 0/0 0/0
Total time = 4 hours 41 min 31 sec
FEC: 0 0
CRC: 182 0
ES: 175 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 31 sec
FEC: 0 0
CRC: 10 0
ES: 10 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 8 0
ES: 8 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 41 min 31 sec
FEC: 0 0
CRC: 182 0
ES: 175 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 hours 41 min 31 sec
FEC: 0 0
CRC: 182 0
ES: 175 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
#
Stats recorded 06 Aug 2015 19:27:39
DSLAM/MSAN type: Not monitored
Modem/router firmware: Not monitored
DSL mode: ADSL2+
Status: Showtime
Uptime: 4 hours 47 min 39 sec
Resyncs: 0 (since 06 Aug 2015 17:30:20)
Downstream Upstream
Line attenuation (dB): 23.5 15.6
Signal attenuation (dB): Not monitored
Connection speed (kbps): 18335 1237
SNR margin (dB): 1.3 6.7
Power (dBm): 18.3 12.0
Interleave depth: 1 1
INP: 0 0
G.INP: Not enabled
RSCorr/RS (%): N/A 0.0000
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 0.53 0
I don't believe that the --show command returns all the needed information. There is a section at the end of the --stats command which is headed "Since Link time =...", and some items in that section are used when the section exists.
What do you think about possibility disabling monitoring such information and using "adslctl info --show" instead "adslctl info --stats"?
-
Thank you for posting that information.
Attenuation log: I see what you mean. At the moment it's hard to understand how this can happen on Netgear only, as the values shown in the Stats tab are the correct way round. I'll investigate.
I don't believe that the --show command returns all the needed information. There is a section at the end of the --stats command which is headed "Since Link time =...", and some items in that section are used when the section exists.
What do you think about possibility disabling monitoring such information and using "adslctl info --show" instead "adslctl info --stats"?
I don't want to do this because it would impact on many other users with different modems. Making special arrangements for just one modem causes too many problems with program maintenance.
-
Any chance you could add an option to remove SNR anomolies?
My lowest SNR is -2.1 when my modem resynced which obviously isn't too helpful when I'm trying to find my lowest SNR when the line was up.
-
You can turn off autoscaling, and set the maximum and minimum Y values to values which suit you.
(Although now I think about it, that wouldn't make any difference to the lowest SNR search.)
-
Does that affect the right click action which shows the minimum SNR, though?
-
No, I thought of that afterwards and edited my post.
I don't really want to throw away inconvenient data on the assumption that it's an anomaly - a short-lived SNRM of -2 dB may well be valid data.
-
Perhaps an option to delete data then? :)
-
Perhaps an option to delete data then? :)
Then only way i would see a negative SNR is during a very fast forced reync for example pulling out the HG612 power cable and then back in again in 5 seconds.
These days i wait 30 minutes before plugging the power cable back in.
-
In view of the amount of occasions this is likely to happen then Im unsure if it would be an efficient use of Erics time to try to delete one specific entry out of the whole set of data. He spends an awful lot of time on DSLstats... and knowing Eric probably more than he should be doing.
If you wish to clear the data, why dont you save what data you have, close the prog down and start a fresh window. :)
-
Thanks, I agree with that.
-
I have DSLstats running in a virtual machine, running Windows XP.
If I pause DSLstats and then save the machine state and then resume the virtual machine, this will cause a violation error in DSLstats.
-
If that's an Access Violation error, this happens when a program tries to read or write to memory which it doesn't have access to. So I can only think that something has changed in the machine state between saving and resuming it.
-
Eric I altered the number of days to delete snapshots from 14 to 60 but suddenly at lunchtime today it decided to delete all the data from 17th to 21st August. Not what I was expecting. For now I have unticked the option in the hope it will action the change. I'm wondering if you only read this setting on program start?
Stuart
-
Stuart, it's supposed to check the configured value every time, but it looks as though there's a bug there. I'll endeavour to fix it.
-
Stuart, it's supposed to check the configured value every time, but it looks as though there's a bug there. I'll endeavour to fix it.
Thanks Eric.
Stuart
-
Eric I have another issue but dont know if it is my router reporting badly or DSLStats. The SES averages screen for day 1 shows 136 SES for the 24 hour period but my telnet data shows nothing like this:-
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23811 Kbps, Downstream rate = 75616 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 63519 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.8 6.8
Attn(dB): 17.1 0.0
Pwr(dBm): 13.0 5.1
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 51 236
M: 1 1
T: 64 5
R: 12 16
S: 0.0260 0.3771
L: 19656 5410
D: 1243 1
I: 64 255
N: 64 255
Counters
Bearer 0
OHF: 281621071 274842
OHFErr: 301 136
RS: 3375366018 1280061
RSCorr: 1244097 2779
RSUnCorr: 13545 0
Bearer 0
HEC: 2599 0
OCD: 2 0
LCD: 2 0
Total Cells: 1737423204 0
Data Cells: 44888497 0
Drop Cells: 0
Bit Errors: 0 0
ES: 5955 942
SES: 35 5
UAS: 64 53
AS: 471447
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.67 6.15
OR: 114.72 202.87
AgR: 63633.43 20203.27
Bitswap: 114249/114252 3506/3603
Total time = 66 days 5 hours 25 min 16 sec
FEC: 3452696733 77538
CRC: 69154 3012
ES: 5955 942
SES: 35 5
UAS: 64 53
LOS: 1 0
LOF: 5 0
LOM: 0 0
Latest 15 minutes time = 10 min 16 sec
FEC: 1692 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 2712 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 25 min 16 sec
FEC: 45079 15
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 169999 812
CRC: 9 30
ES: 5 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 days 10 hours 57 min 25 sec
FEC: 1244097 2779
CRC: 301 136
ES: 66 56
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>
Stuart
-
Stuart, there's a bug lurking in the averages calculation which I've been unable to trace. If you reset the averages they should be accurate for some time, and if you switch to the modem/router uptime averages they should be accurate and remain so.
-
It's funny you should mention the modem/router averages roseway, my DSLstats seems to default to 24 hour averages after closing down the program even when i select modem/router uptime averages it goe's back to 24 hour averages :-\
-
You're probably right, NS. I don't think the setting is saved. I'll add that in the next release.
-
Eric this afternoon I had a 'divide by zero' error from DSLStats, is this a known error? Only seen the one so far today. Dont know if it is coincidence or not but I have today updated my ZyXEL to the final 11C0 f/w.
Stuart
-
It's just about impossible to tell, Stuart. There are divisions in numerous places in the program, and tracing a rare event like this is in the "needle in a haystack" category. If it repeats itself it may be possible to relate it to a particular set of circumstances, but failing that I'm not hopeful.
-
It's just about impossible to tell, Stuart. There are divisions in numerous places in the program, and tracing a rare event like this is in the "needle in a haystack" category. If it repeats itself it may be possible to relate it to a particular set of circumstances, but failing that I'm not hopeful.
OK no problem I just thought I ought to mention it in case it helps to build a bigger picture.
Stuart
-
This is a bit of an awkward and long question. I am running on a Raspberry Pi. Only version 5.4 seems totally reliable for me. :) It has yet to get divide zero and always restarts fine after modem power off and on. I get at least one divide zero each day with v5.6 and other versions. Other version have also failed to restart after DLM resyncs.
I do however have just one minor trouble with the web server (apart that is from it not serving the pages). I can use the created files with another web server (simplehttpserver -I have only tested and not run this long term) but have trouble with the combined html page. Looking at the combined html content it looks for a stats and fullstats files ending in .txt which are not there to be found. I can live with not using the combined file but I am always curious.
If I create an edited an renamed combinedx.htlml file which looks for the stats .html files rather than .txt files (which do exits) it works fine on the PI but not when used via the PC. (The fact that the edited file does not work on the PC may well be something to do with my novice use of simplehttpsever , it seems not to update the files served.) The question is should the .txt files be there or whether it should be using html files. if it should be using the html files then I may be OK if I can get the webserver to update the files.
Sorry for the ramble.
-
@les-70: I'll look at these issues as soon as possible, but I'm afraid it won't be before Tuesday.
-
Thanks, there is no rush, I am very busy as well
-
Just reporting that I have moved on from trying to get a local webserver working to uploading the files to some webspace. This is better as I can access the results from anywhere.
In summary v5.4 remains the only recent version totally reliable on my PI. No divide zeros and with restart after pause enabled just keeps going. I just can't get the latest version to last a day without stopping so I afraid that I am unhelpfully living in past.
If I create a renamed version of combined.html called index.html and replace the calls to .txt files (that are not created) with appropriate calls to e.g. stats.html the index.html files works fully on the PI but when uploaded (or previously when web served to the PC) the png files are not shown, just the stats.html and fullstats.html. I am afraid I barely have a clue with linux and rely a lot on googling for my commands and I have near zero clues with html.
-
I have to admit that I'm struggling with these issues. For personal reasons I'm not able to spend as much time on the PC as I used to, and it wasn't helped by the fact that I managed to fry my RPi version 2 by being hamfisted when I fitted it in a case. :( I'm setting up a new one now.
I'll continue working on the various reported issues, but it will take time, and for the moment major new features are off the agenda.
-
No worries just reporting. Somewhat separate from dslstats, do you or anyone else have any idea why the combined.html file fails to pick up the .png files when all is uploaded. Given the the files are all there I think things ought to work unless there is something about the combined.html files that only works on the PI.
It may be better if I move this issue to another thread as others seem to done this successfully and it is probably my ignorance that is causing my failures.
-
The reason the combined.html file does show the images for me when viewed via a webserver or upload seems to be simply that Windows (XP) can't open the crc.png etc files. I will try googling on this issue but I am not aware why this would be.
edit -- same for viewing with android or via webspace back to Pi
-
and it wasn't helped by the fact that I managed to fry my RPi version 2 by being hamfisted when I fitted it in a case. :( I'm setting up a new one now.
Arrgh how did that happen was it a metal case sorry i just hate to see good tech going to waste :(
-
I tried to put it in the case with the micro SD card still inserted. It's a tight fit in the case, and I must have damaged that area, because when I switched it on it didn't work, and I discovered that the the metal band covering the SD card was practically red hot.
-
Just to advise that my reported issues should drop to the very very bottom of your list. I have decided it best to just upload the fullstats page every minute and make do with that. It has the advantage of being a very lightweight action just uploading a single tiny file. I have an edited index.html file just displaying that content only on my webpage. So with that going, all I really need is working for me.
I don't know if the fact that v5.4 seems immune to errors will help fix divide zero errors in the current version -- I suspect not.
End result is me even more happy with dslstats :) so thanks again.
-
Many thanks for that. :)
-
I've started getting daily at around 10:40 (for last 2 days anyway) Floating point errors
Program seems to keep working after I acknowledge the error
Nothing in the event log
Upload to MyDslWebStats seems to stop until I stop and start recording again
Running Version 5.6.2 on Pi
Anywhere I need to look
-
If they're daily at the same time, that's a good pointer to the cause. I'll have a look at it shortly.
-
Thanks
Hit the problem again today at exactly the same time 10:41am
-
Version 5.6 does not seem to have the issue
-
I'll look to see if any of the changes from 5.6 to 5.6.2 could explain that.
-
No stress
5.6 is working fine and 5.6.2 is pre release :-)
-
Thanks for those words of comfort. :)
I still want to understand why, because the changes in the pre-release versions are needed (and don't at first sight appear to relate to the issue).
-
I had 5.6.1 running and uploading to mdws for several weeks without any problems. With 5.6.2 I got the floating point error yesterday and today at 23:03. Maybe this helps you to find the problem.
-
Thank you, I'll add that to the search.
-
The floating point error appeared again every day at the same time. Consequently I deleted the dslstats folder and configured all from scratch. The error disappeared and dslstats is now running stable since a few days.
-
Thanks for that information. I've been unable to find any reason for 5.6.2 to exhibit the problem when 5.6.1 didn't, and I've resorted to working through the code line by line, checking every instance of a floating point division. I've found a couple of instances where I can't be certain that the divisor will never be zero, and I've dealt with these. I'll review what I've done so far in the light of this additional information.
-
I know it's not much help my 5.6.2 on PC is doing this all the time and click OK when the error pops ups then it says do you want to close program and I say yes.
Then execute Dslstats and all is well for 2 or 4 days and then the error comes back again and have do the same all over again.
-
I am getting the same thing happening for version 5.6.1 using a Zyxel VMG8324-B10A running Firmware ver 1.00(AAKL.11)C0
I have been assuming it was something on my PC interfering with DSLStats.
Should I upgrade to ver 5.6.2 ?
-
The differences between 5.6.1 and 5.6.2 are very minor. As Morphium reported above, the issue may be related to upgrading from one version to another. In his case it seems that deleting the configuration files and reinstalling from scratch may have resolved the problem.
-
May I make what may be the daftest suggestion on the zero divisor problem?
It is to add a minuscule amount e.g 0.00000001 to the divisor that has been previously calculated.
-
Thanks, will try a clean install.
-
May I make what may be the daftest suggestion on the zero divisor problem?
It is to add a minuscule amount e.g 0.00000001 to the divisor that has been previously calculated.
It's a novel idea, but it would be obscuring a possible bug somewhere else in the program - if a divisor is zero, then there must be a flaw in the logic leading up to that point, and this needs to be addressed.
-
After deleting the configuration folder dslstats was running 10 days continuous without any error, but then I got the floating point error again. Today was the third day in a row. Each day the error appeared one minute later: (13.Nov: 19.51, 14.Nov: 19.52, 15.Nov: 19.53).
-
@morphium: Are you autosaving some graphs and then autodeleting them after ten days perhaps?
-
Eric I got another divide by zero again this morning, I do not currently delete any snapshots but do it manually which I have not done for weeks. Also the reason I was aware it stopped was because MDWS told me I was not uploading. I think this happened around 9am this morning but the last event log entry was snapshots at around 8am. Once I get the divide by zero error it stops uploading to MDWS although it appeared to still be sampling when I went to look at the PC. I amusing 5.6.2 on W7.
Stuart
Edit: just checked and I believe the last one was 10 days ago!!!!!
-
As far as I can see, apart from the snapshot autodeleting possibility, the only event which starts happening after 10 days is a shift of the error averages data (it keeps 10 days history, then drops off the oldest day and moves everything else along one place). But this doesn't involve any floating point operations, so it can't really be responsible.
-
@morphium: Are you autosaving some graphs and then autodeleting them after ten days perhaps?
No, this isn't enabled. In addition to the standard configuration only "upload to mdws" is enabled.
2 days ago I deleted the "es.data" but this seems not to help. Yesterday I deleted the "traffic.ini". I let you know if the error does not appear today.
Edit: Invalid floating point operation after 24h+1 min.
-
was just checking settings on DSLstats v5.6.2 and noticed the sample rate was set at 30 seconds switched back to 1 min samples and that seems to stop the divide by zero error each day :fingers:
-
That shouldn't be possible if you're uploading to MDWS. Do you know how it happened?
-
That shouldn't be possible if you're uploading to MDWS. Do you know how it happened?
Sorry I am talking about the PC the RPi does the uploading to MDWS and use DSLstats on the PC every evening until bedtime :sleep:
-
I am also getting divide by zero error on pc then it stops uploading stats. Stopped at around 16.20 yesterday. Not helpful I know but it can happen after a couple of hours or will run a couple of days then give the error
-
I am also getting divide by zero error on pc
I really am sorry about this issue, but I've been totally unable to find the cause so far. I don't have a Windows PC which I can leave running 24/7, and I can't reproduce the error on other OS's. I'm going to try a brute force solution, error trapping every floating point division in the program and logging any errors which appear.
-
Eric as I have a W7 PC running 24x7 which is my DSLStats PC as well I am more than happy to run any test version you can come up with to trap this if it will help.
Stuart
-
Thanks Stuart.
-
Eric I just had another error just ten days after the previous error. In fact looking at the timing it was just over 10 days, the previous one was 25/11 at 22.30 and today 6/12 at 08.30. So my prediction is another around 16/12 probably around 18.00 to 19.00 - now to see how well I've predicted it. Also assumes no reboots etc on the PC ;)
Stuart
-
There's hardly anything which happens on a 10-day cycle. Do you possibly have the check for program updates (on the Configuration --> Misc tab) set to 10 days?
-
Well I have it set to check daily for updates, also I do not have it deleting any snapshots at present and I can find nothing in the settings which would be based on a 10 day schedule either. I gather from earlier comments that this only happens on Windows and no one running it on Linux has seen it (or if they have they have not reported it).
One thing that appeared to happen today was that I did not see the error message immediately I switched over to the W7 PC on my KVM switch until I selected DSLStats as the active display on the desktop, this was all prompted by me seeing the MDWS warning email so it is difficult to know exactly when the error happened. I did check and the last graph snapshot was at 08.03 today and the MDWS email says it has not seen any recording since 08.06 today I do wonder if the process failing is the snapshots although 3 minutes is a long time (in CPU terms) after the graphs appeared in the folder. I've checked all the files saved at that time and the are all OK nothing seems missing or corrupt.
Stuart
-
I'm running dslstats 5.6.2 on the raspberry.
The floating point error appears repeatable exactly (+/-5 minutes) 10 days after deleting the config folder and start sampling. From now on the error appears every 24 hours at the same time, it doesn't matter if I restart the program at another time or only skip the error and pause/restart sampling.
As far as I know version 5.6.1 worked without this problem.
-
There's only one thing which happens on that cycle. Average errors are stored in a ten-element list. Each element contains the data for one day. 24 hours after a clean start, and each 24 hours thereafter, each element in the list is moved up one place and a new blank set of data is added to the bottom. After ten days the list is fully populated, and the topmost element is discarded each 24 hours.
Of course there's no floating point division in this process, but it looks as though something unexpected must be happening at the point where the ten day period is reached...
There was one relevant change between v5.6.1 and v5.6.2:
the state of the error averages 24-hour/Modem-uptime option is now saved and restored
-
Hi Eric, someones just brought it too my attention that this program no longer works on Netgear routers.... can I ask why? and do you have access to previous versions so that one can get the last version that was supported?
thanks :)
-
It's not exactly that DSLstats no longer works with Netgear modems. But newer models and newer firmware versions seem to be getting increasingly problematic, and I'm completely unable to support them. I don't think it's related to newer versions of DSLstats.
-
thanks Eric
it no longer works on the DGND3700v2, when ive checked it says the latest firmware upgrade was to fix the SOAP issue which left the router open to hackers, maybe that issue is on a few netgears and causing the problematic telnet access with DSLstats, I know someone who is using DMT Tool and RouterStats but just wanted to use DSLstats
cheers
-
The divide by zero error has not emerged since selecting 24 Hour averages if I was to select modem/router uptime averages on the PC DSLstats 5.6.2 the error comes back this must be the place that needs a close inspection.
-
Thanks for that useful information.
-
Just to confirm that I have Modem/Router uptime averages selected as well and I am seeing the error. I have changed to 24 hour now and will see if I get any more.
Stuart
-
Thanks Stuart.
-
DSLstats has been free from division by zero error for 4 days since moving to 24 Hour averages.
when I clicked on DSLstats the program would execute and then the red sampling text shows up and samples then the division by zero shows up and then click OK on the warning page it then says the program will close down.
All this has gone since selecting 24 hour averages.
-
This is valuable information, thank you.
-
DSLStats has now been running for more than 10 days since the last zero error although it is less than 10 days since I changed the setting, perhaps the real test will be in 10 days after I changed the setting which will be on the 26th December, however it does look promising.
Stuart
-
Updated the RPi from 5.6 to 5.6.2 this evening and straight away divison by zero error it seems the auto select is to use modem/router uptime averages.
The next execute of the program was able to pause the recording before the error showed up and changed it back to 24 hour averages and resumed recording.
That should stop this division by zero error showing up on the RPi which then stops uploads to MDWS :fingers:
-
I'll just throw something else into the mix here..
Since I switched to using the HG612 instead of the D7000 I have had no 'Divide by zero' errors, or any other problems, it's solid.
-
Thanks for all these contributions. My time on the computer is very limited at present, but I will deal with this as soon as I can.
-
Minor issues for the next release:
1) On the Stats tab, G.INP is showing Enabled for Downstream but is blank for Upstream though it is definitely on.
2) Note that the Upstream RSCorr/RS (%) is claiming 1477%. G.INP is good but it surely can't be that good!
Stats recorded 20 Jan 2016 12:24:05
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 7 days 3 hours 43 min 9 sec
Resyncs: 2 (since 23 Dec 2015 08:04:01)
Downstream Upstream
Line attenuation (dB): 16.6 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 62153 18998
SNR margin (dB): 6.8 6.3
Power (dBm): 13.6 6.9
Interleave depth: 4 4
INP: 55.00 48.00
G.INP: Enabled
RSCorr/RS (%): 0.5266 1477.0244
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
Thanks for that information. I'll look at it as soon as I can, but time at the PC is very limited at present for personal reasons.
-
I would like a feature within DSLStats that would automatically re-sync my modem if the SNR margin was above 7 for instance for more than 2 minutes. This would allow me to get a higher sync rate when crosstalk is removed for a short while. Do you think you could add this feature? Thanks
I know you could reconnect using these two commands:
xdslctl connection --down
xdslctl connection --up
-
I would like a feature within DSLStats that would automatically re-sync my modem if the SNR margin was above 7 for instance for more than 2 minutes. This would allow me to get a higher sync rate when crosstalk is removed for a short while. Do you think you could add this feature? Thanks
I know you could reconnect using these two commands:
xdslctl connection --down
xdslctl connection --up
but your SNRM will be much lower when the crosstalk disturber comes back online
-
Is a Mac OS X version ever likely mate?
-
but your SNRM will be much lower when the crosstalk disturber comes back online
Yes that is fine tho, it will probably be around 5 or 4.5 so I wont see any issues with that. My connection is also pretty stable so I believe DLM would be fine too.
-
My connection is also pretty stable so I believe DLM would be fine too.
Are your sure and just going by my own SNRM if it go's below 4.5dB for 24 hours it will do a 1 RDI ( Remote Defect Indicator/DLM) and re-sync, one thing with FTTC is that you can't fool the DLM oh yes you can by manually capping the line sync on the modem but this also has a negative impact if used over many months.
-
@gazaai: I'm sorry, but I'm just not able to spend much time on programming at present (a health issue) so new features are off the agenda for the foreseeable future. The best I can suggest is to use the alert system to send you an email when the SNRM falls below 6 dB (say) then another email when the SNRM subsequently rises to 7 dB, and act manually when the second one is received.
@underzone: No possibility at all I'm afraid. I understand that the Windows version of DSLstats works well using Wine in OS X.
-
@NewtronStar In the past I've had my connection run at 3db with no issues at 75mb sync rate, this was back when I had a bridge tap on the line now if my line was at 3db I should reach 80mb. That was up for just over a week then the router was unplugged by mistake and it resynced at 6db. I don't think the cabinet resyncs unless there is lots of errors.
@roseway No problem don't worry about it. Thanks for suggesting the alert feature I never thought about that, I'll look into it.
-
@underzone: No possibility at all I'm afraid. I understand that the Windows version of DSLstats works well using Wine in OS X.
Yes, it works perfectly with Wineskin (free) - thanks!
-
Excellent. Thanks for letting me know.