Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on April 18, 2014, 07:49:35 AM
-
[Don't upgrade to this version yet if you use a Thomson/Technicolor modem/router]
Changes since v4.50.1:
- v4.52.1 fixes "List index (-1) out of bounds" error with some setups
- while recording is in process the login details can't be changed (you now have to pause or stop recording first)
- fixed issue with invisible graph labels when using a dark desktop theme
- fixed incorrect detection of VDSL2 band plan with some modem/routers
- the alerts system can now send alerts to the event log as well as to email
- added more triggers to the alerts system (CRC, FEC, ES, SNRM return after low value)
- the email alert "From" address is now set to a sensible format
- now provides some limited support for D-Link DSL-3780 (more work to be done)
http://dslstats.plainroad.me.uk (http://dslstats.plainroad.me.uk)
-
Installed and running here. The alerts for CRCs to the Event log is already working well for me this morning.
Stuart
-
Thanks Stuart.
-
Im not sure whats gone wrong. Ive tried redownloading again.. and Ive also rebooted the PC
Typical I didnt keep a copy of the old version, have you got a link so I can roll back please.
Out of bounds error.
-
Sorry about that. I'm a bit puzzled at the moment.
http://www.s446074245.websitehome.co.uk/files/dslstats32W-4.50.2.zip
-
Thank you eric,
I'll try do some more testing to see if I can recreate exactly what happened, but atm it appears to be if I try to keep my .ini
If I start from fresh without using my old .ini it seems ok.
-----
ETA
Do I do something wrong when I upgrade to a latest version.
Normally I just take the .exe file and let it overwrite the old one. Should I be doing something more?
-
Do I do something wrong when I upgrade to a latest version.
Normally I just take the .exe file and let it overwrite the old one. Should I be doing something more?
The file routers.dat changed between the versions, and it's possible that using the previous version with the new version of DSLstats would cause the error message you saw, but I'm not certain about that. I'll check it out tomorrow.
(Memo to self - in future, mention these changes when they occur with an upgrade.)
-
This latest release has been in use at The Cattery for around an hour . . .
So far there is nothing abnormal to report. :)
-
Eric the alerts seemed to have stopped after midnight. This morning I can see conditions which should trigger an alert to the event log but it did not do it. I am not emailing alerts just recording to the log.
Stuart
-
Could you give me the specific details please, Stuart? i.e. What settings you have for alerts, and the relevant entries in the event log. Thanks.
-
I've updated the downloads to v4.52.1 which fixes the "List index (-1) out of bounds" issue with some systems.
-
Eric I have set for CRCs over 15 and FECs over 10000 only. They worked fine yesterday but the last log entry was for just before midnight. Since then I have had a couple of times when CRCs went over 15 but no log entries. The last log said
18 April 2014 23:50:40 Alert: Downstream FEC/min rose to 24415.86
after that no more alerts. I tried ticking and unticking the alerts but no change, Ive had 2xCRCs over 15 and 2xFECs over 10000 but no log entries. Rest of the log is working fine with all expected messages, just no alerts.
Stuart
-
Stuart, it's working as designed (although you may take the view that the design needs changing :) ). What happens when an alert is triggered is that the value which caused the alert becomes the new trigger threshold. The trigger thresholds are reset to the values you entered if you stop recording, there is a re-sync, or you edit one of the values (which resets just that value).
I did it this way to avoid the possibility of an endless stream of alerts if the line becomes very noisy while you're not present to notice it. It would be simple enough to change this behaviour, or make it optional perhaps.
-
Stuart, it's working as designed (although you may take the view that the design needs changing :) ). What happens when an alert is triggered is that the value which caused the alert becomes the new trigger threshold. The trigger thresholds are reset to the values you entered if you stop recording, there is a re-sync, or you edit one of the values (which resets just that value).
I did it this way to avoid the possibility of an endless stream of alerts if the line becomes very noisy while you're not present to notice it. It would be simple enough to change this behaviour, or make it optional perhaps.
I can see your point however in the case I'm looking for I set the initial threshold higher than any normal value for for both thresholds and I do need to keep that initial value so perhaps setting it as an option is the best way forward. When looking for spikes it is the only way to do it.
Stuart
-
I can see your point however in the case I'm looking for I set the initial threshold higher than any normal value for for both thresholds and I do need to keep that initial value so perhaps setting it as an option is the best way forward. When looking for spikes it is the only way to do it.
And in turn, I can see your point. I'll make it optional next time.
-
Thanks Eric, I wont be around for a about 10 days, so I wont be ignoring your, I just wont be here ;)
Stuart
-
I find it hard to keep up with the DSLstats updates, once a week would be fine and just updated to v4.52 to find another update pop-up for v4.52.1 thats what I call realtime updates cheers Eric ;D
-
Thank you eric, just updated and so far so good :)
-
Thanks both. :)
@NewtronStar: the only reason for v4.52.1 coming so quickly after v4.52 was to fix the bug which Kitz reported, which only affected some setups. I'll try not to do it again. :)
-
there is one thing I have noticed with V4.52 and V4.52.1 compared to V4.50 is that if you double click the DSLstats icon while DSLstats V4.52 is running it will open up a new DSLstats screen (two running together) it does not cause any hassle on my PC but in V4.50 it said there was a Version of DSLstats already running and would not open a second one.
-
Yes, sorry, you're right. While I'm testing I disable the "Single instance" code, and in this case I forgot to re-enable it before building the download packages. Running a second instance isn't a big problem normally, but if you're running the webserver it will cause an immediate crash.
-
Hi Eric :)
ive noticed there seems to be an issue with the RS counters on mine? left running a few hours:
RSCorr/RS isnt displaying a value... RSUncorr seems to be about correct I think
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FBcPZp9k.jpg&hash=7c29ff39c9a2d54eea82f009d3a0bd333933aae2)
stats:
adslctl info --stats
adslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 1252 Kbps, Downstream rate = 21680 Kbps
Bearer: 0, Upstream rate = 1212 Kbps, Downstream rate = 19998 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): 4.9 9.2
Attn(dB): 25.5 14.5
Pwr(dBm): 18.7 12.1
ADSL2 framing
Bearer 0
MSGc: 81 15
B: 142 15
M: 1 8
T: 3 7
R: 10 16
S: 0.2469 3.6226
L: 4957 318
D: 128 8
Counters
Bearer 0
SF: 32379318 95955
SFErr: 3650 6
RS: 4156034355 420644
RSCorr: 9984725 3291
RSUnCorr: 41307 0
Bearer 0
HEC: 11032 7
OCD: 0 0
LCD: 0 0
Total Cells: 3130262526 1490764448
Data Cells: 398487893 21204067
Drop Cells: 0
Bit Errors: 0 1584
ES: 2149 3
SES: 0 0
UAS: 55 55
AS: 521682
Bearer 0
INP: 1.00 1.50
INPRein: 0.00 0.00
delay: 8 7
PER: 16.11 16.64
OR: 43.19 10.09
AgR: 18459.94 1126.26
Bitswap: 82061/83513 10804/10804
Total time = 1 days 55 min 45 sec
FEC: 9984725 3291
CRC: 3650 6
ES: 2149 3
SES: 0 0
UAS: 55 55
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 45 sec
FEC: 315 0
CRC: 1 0
ES: 1 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: 1066 0
CRC: 3 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 55 min 45 sec
FEC: 3182 0
CRC: 10 0
ES: 8 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: 5268823 619
CRC: 2024 2
ES: 960 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 6 days 54 min 50 sec
FEC: 9984725 3291
CRC: 3650 6
ES: 2149 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
cheers
-
Yes, it looks as though you're right, snadge. I'll investigate.
[Later] I've found the cause and fixed it for the next release.
-
Don't know if the Average Error page over 24 hours is new but it gets a Gold * from me very usefull indeed.
-
I'm glad you find it useful. :)
-
Eric on my return last night I updated to 4.52.1 and have now lost the AS uptime, it shows the label but no time. $.52 worked fine.
Stuart
-
I'll check it out Stuart.
[Later]
I think I've traced it. Can I assume that (1) you're still using the HG622 and (2) your uptime is greater than 49 days?
-
[Later]
I think I've traced it. Can I assume that (1) you're still using the HG622 and (2) your uptime is greater than 49 days?
Indeed I am Eric and yes it is greater than 49 days.
Stuart