Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on July 20, 2013, 02:33:04 PM
-
The main new feature in this version is traffic monitoring. I've labelled it Experimental, because there are numerous unknowns about the way different routers report traffic, but I've tested it with a TG582N and with an HG612, and it reports correct values for these. There's a small drop-down list of routers with known configuration requirements, and a manual setup procedure for the remainder. You'll find another page "Traffic monitoring" under the Configuration tab.
Anyone who successfully sets up a router which isn't already in the list, please let me know the setup details and I'll add it to the list.
Full list of changes:
- added option to choose horizontal scaling of bitloading graph (1, 2 or 3 pixels per tone)
- fixed issue whereby the SNRM graph would sometimes be clipped when using manual scaling
- added INP values to Stats page for Thomson routers
- added experimental feature to monitor upstream and downstream traffic
http://dslstats.plainroad.me.uk
-
Is this a bug, I'm assuming it is?
The error reporting seems to be bugged since 3.6, added a few images.
First is from 3.7, second from 3.61 have the same with original 3.6.
This traffic monitoring seems interesting...
Edit: Is the traffic meant to be plotted every time it samples? If so it isn't working for me, or will this feature not work if you aren't using the modem as VDSL2 modem/router?
-
The values in the traffic monitoring chart are rounded to multiples of 1 MB, so you won't see anything on the chart until it gets over 0.5 MB. The values in the box underneath the chart are rounded to 0.01 MB, so those should update regularly. The values are updated every sample.
Your graphs above clearly do show a bug. I'll need to see the output of the --stats command for your router to find out what's wrong.
-
I'm using the default HG612 drop down so I'm surprised no one else is getting it...
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 4763 Kbps, Downstream rate = 27876 Kbps
Path: 0, Upstream rate = 5113 Kbps, Downstream rate = 24843 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.4 5.0
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 7.4
VDSL2 framing
Path 0
B: 51 160
M: 1 1
T: 64 5
R: 12 16
S: 0.0666 1.0000
L: 7690 1416
D: 487 1
I: 64 177
N: 64 177
Counters
Path 0
OHF: 1117921592 1032403
OHFErr: 21264 4934
RS: 2720026715 4292343
RSCorr: 354295856 19676
RSUnCorr: 2040775 0
Path 0
HEC: 442582 0
OCD: 21647 0
LCD: 21647 0
Total Cells: 736285574 0
Data Cells: 2509995295 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2579 4440
SES: 47 0
UAS: 11 11
AS: 4782271
Path 0
INP: 3.00 0.00
PER: 4.26 16.25
delay: 8.00 0.00
OR: 52.56 19.20
Bitswap: 1394180 24139
Total time = 1 days 8 hours 25 min 3 sec
FEC: 354295856 19676
CRC: 21264 4934
ES: 2579 4440
SES: 47 0
UAS: 11 11
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 10 min 3 sec
FEC: 1326 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 192 5
CRC: 0 2
ES: 0 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 8 hours 25 min 3 sec
FEC: 83832 71
CRC: 16 29
ES: 8 27
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1053894 295
CRC: 56 104
ES: 18 99
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 49 days 17 hours 2 min 46 sec
FEC: 354295856 19676
CRC: 21264 4934
ES: 2579 4440
SES: 47 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#
My traffic doesn't seem to be plotting data on the graph, I've selected the HG612 and ticked Monitor Traffic box but it doesn't plot within the graph.
-
I'm sorry, I mixed you up with another person who uses the DGN2200.
I use the HG612, and it plots the FECs properly. I'll check your stats to see if I can see anything different about the way they're reported on a VDSL2 connection.
Concerning the traffic plotting, do values get reported in the text underneath the graph?
-
If i understand you correctly I want to say no... you are on about a value next to Today: and This month:? Then no, nothing is displayed on that page.
Here are the details from Traffic via Telnet page
ifconfig
br0 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:17
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14381573 errors:0 dropped:0 overruns:0 frame:0
TX packets:16305155 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:986424402 (940.7 MiB) TX bytes:1046533729 (998.0 MiB)
br1 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:17
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6880594 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1841340788 (1.7 GiB) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:17
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134728135 errors:0 dropped:0 overruns:0 frame:0
TX packets:185394847 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4219386954 (3.9 GiB) TX bytes:1902307715 (1.7 GiB)
Interrupt:40 Base address:0x6a00
eth0.4 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:17
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14381746 errors:0 dropped:0 overruns:0 frame:0
TX packets:16305152 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1245309681 (1.1 GiB) TX bytes:1116904872 (1.0 GiB)
eth0.5 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:17
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:120346389 errors:0 dropped:0 overruns:0 frame:0
TX packets:169089695 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2974077273 (2.7 GiB) TX bytes:785402843 (749.0 MiB)
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:11000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:11000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:11000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:220 errors:0 dropped:0 overruns:0 frame:0
TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:16332 (15.9 KiB) TX bytes:16332 (15.9 KiB)
pktcmf_sa Link encap:UNSPEC HWaddr FE-FF-FF-FF-FF-FF-FF-FF-00-00-00-00-00-00-00-00
UP NOTRAILERS RUNNING NOARP MTU:0 Metric:1
RX packets:292326373 errors:0 dropped:0 overruns:0 frame:0
TX packets:292326373 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1211485528 (1.1 GiB) TX bytes:1213844086 (1.1 GiB)
Interrupt:50 Base address:0x5220
pktcmf_sw Link encap:UNSPEC HWaddr FE-FF-FF-FF-FF-FF-FF-FF-00-00-00-00-00-00-00-00
UP NOTRAILERS RUNNING NOARP MTU:0 Metric:1
RX packets:202087735 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:104850194 (99.9 MiB) TX bytes:0 (0.0 B)
Interrupt:42 Base address:0x6a40
ptm1 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:18
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:457133240 errors:0 dropped:0 overruns:0 frame:0
TX packets:322365933 errors:76881 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1887676680 (1.7 GiB) TX bytes:1955216534 (1.8 GiB)
ptm1.101 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:18
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:116532412 errors:0 dropped:0 overruns:0 frame:0
TX packets:91699239 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:237130120 (226.1 MiB) TX bytes:2910114123 (2.7 GiB)
ptm1.301 Link encap:Ethernet HWaddr C8:D1:5E:85:4D:19
inet addr:30.178.37.155 Bcast:30.178.39.255 Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8484 errors:0 dropped:0 overruns:0 frame:0
TX packets:8712 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:462902 (452.0 KiB) TX bytes:451805 (441.2 KiB)
#
-
That explains the lack of traffic data. On my ADSL2+ connection, the interface which carries internet traffic is ppp256, but there isn't a ppp*** interface on your VDSL2 connection. You need to use the 'Other' option in the interface list, and enter the appropriate one from the list above. I would guess that would be eth0, if the high volume of upstream traffic matches your expectation for your connection, otherwise eth0.5
-
Okie, tried that and I get the following error.
I tried both, they just gave a different Integer...
-
It might be worth pressing the red button "Reset current month", as there might be inappropriate data left over.
If that doesn't work, I'll have to look more deeply.
-
Thank you, that solved the problem.
Works using eth0!
Though the data doesn't look accurate, about 10MB in upload in 15 seconds? I don't think so :D
-
The error has just replicated itself while running for 30/45 mins!
-
Perhaps it should be eth0.5 then, but that doesn't explain the "Invalid integer" error. I have some thoughts about that, which I need to check.
-
When using eth0.5 I just get the error straight away even when I've reset the month/day.
-
Might it be worthwhile making a telnet connection to the HG612, obtaining a shell and then examine the output of an 'ifconfig -a' command?
The correct interface must surely be the one that is assigned the dynamic IP address which your service is currently using. (I hope that makes sense.)
-
Something does not seem quite right. Here are my error stats ( in attachment). Somehow, even though the graphs are set up properly, no CRCs are being graphed, and only one upstream FEC at ~8 pm. edited
Moreover no snapshots are taken despite being set up. (Mea culpa)
-
I am seeing the same invalid integer message doing Traffic Measurement on the Windows version connected to my HG622, happens every time and reset does not stop it. The number shown is huge 4240291554 and is different each time.
Stuart
-
Thanks Stuart. I've got a good idea where to look for this, and I should be able to fix it. In the meantime, for people who see this issue it would be best to disable the traffic monitoring for the time being.
-
It seems the integer error is caused by values equal or bigger than 2łą.
I am using the "/proc/dev/net" source. Sometimes the displayed traffic randomly increases about 1 GB though the raw data only counted a few MB.
-
I have been running happily with a past version but now I really like :) the traffic monitoring in 3.7 and wonder over long term monitoring even when things are switched off each night. I may be missing something but past values seem lost with over night shutdowns.
I wonder whether allowance for modem/computer shutdowns over night or in the day might be made with the latest values traffic values for the current day being saved to a file with each sample. On restart a check could be made on this file regarding the traffic values and the date and time of the last sample. If a previous day it could be placed in separate recording file for past days and if not it could be taken into consideration for the current day.
Might something like this be possible? It is a great utility!
-
It seems the integer error is caused by values equal or bigger than 2łą.
I am using the "/proc/dev/net" source. Sometimes the displayed traffic randomly increases about 1 GB though the raw data only counted a few MB.
Yes, it's caused by a string to integer conversion function which only returns a 32-bit signed value. There's a 64-bit version of the function which I'll be using instead, which will effectively provide unlimited capacity.
I'm not sure about the random jumps in displayed traffic, but these may be the result of an error in parsing the raw data. I'll check it out.
-
I have been running happily with a past version but now I really like :) the traffic monitoring in 3.7 and wonder over long term monitoring even when things are switched off each night. I may be missing something but past values seem lost with over night shutdowns.
I wonder whether allowance for modem/computer shutdowns over night or in the day might be made with the latest values traffic values for the current day being saved to a file with each sample. On restart a check could be made on this file regarding the traffic values and the date and time of the last sample. If a previous day it could be placed in separate recording file for past days and if not it could be taken into consideration for the current day.
Might something like this be possible? It is a great utility!
Thanks for those comments. When DSLstats is closed down, the current state of the traffic data is saved, and restored when the program is started again. But it may not handle this correctly if there's a change of day between closing down and restarting. I also suspect that there may be an issue if one of the router's traffic counters wraps round from 4 GB during the closed-down period. I'll be looking at these issues.
-
Something does not seem quite right. Here are my error stats ( in attachment). Somehow, even though the graphs are set up properly, no CRCs are being graphed, and only one upstream FEC at ~8 pm. editedMoreover no snapshots are taken despite being set up. (Mea culpa)
Thanks for correcting that point. :)
Are you still seeing an absence of CRCs and FECs being plotted? It's possible that you're just not getting many. I believe that there is a bug in the reporting of the FEC averages when the program is closed down and restarted, but I haven't yet had time to look properly at it. This could be the cause of higher levels being reported in the averages than are shown in the graphs.
-
Thank you eric, I will download and install in a bit and give relevant feedback :)
-----------
However, (you are going to hate me now) but since it would appear that my upstream issue is back, pwetty please is it possible to log the atten figures for vdsl.
The attenuation cant be obtained via the normal stats on the HG612 and I think you may need to get it from # xdslcmd info --pbParams for FTTC lines.
xdslcmd info --stats
Max: Upstream rate = 35417 Kbps, Downstream rate = 102116 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 11.9 15.7
Attn(dB): 0.0 0.0
Pwr(dBm): 14.3 5.3
Using
xdslcmd info --pbParams
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 35349 Kbps, Downstream rate = 102116 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
Medley Phase (Final) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35349 kbps 102116 kbps
Actual Aggregate Tx Power: 5.3 dBm 14.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.8 17.9 29.2 N/A 11.1 24.5 38.8
Signal Attenuation(dB): 0.9 17.8 29.0 N/A 11.1 24.5 38.8
SNR Margin(dB): 5.9 20.8 14.2 N/A 11.6 12.1 11.9
TX Power(dBm): -4.8 -25.3 4.8 N/A 12.0 7.4 7.2
#
-
:)
Yes, I should be able to put something together.
-
Turned on computer and started dslstats this morning. The only entry on the graphs was @ 11:50 for upstream CRCs as per attachment. Nothing at all is recorded for FECs. However, assuming I am reading the stats correctly, an increase of the per second rate from 6456 in my post last evening to 8343 @~13:00 today indicates there is much activity.
BTWi how can I snapshot the telnet data, so to have available the actual status at the two hourly intervals?
-
However, assuming I am reading the stats correctly, an increase of the per second rate from 6456 in my post last evening to 8343 @~13:00 today indicates there is much activity.
I think that might be another indication of the suspected bug I referred to a few messages ago.
BTWi how can I snapshot the telnet data, so to have available the actual status at the two hourly intervals?
The only way at the moment is manually - highlight the text by dragging the mouse over it, then copy it to the clipboard with Ctrl+C. Paste it into a text editor to save it.
-
Oh dear! :o :D I'll have to use my excellent forgettery again to do get those telnets.
Now being the bear with little brain on this forum I am wondering, if until some of the matters are sorted I should revert to 3.6. :-\
OT but what are the problems with making Windows64 versions?
-
However, (you are going to hate me now) but since it would appear that my upstream issue is back, pwetty please is it possible to log the atten figures for vdsl.
The attenuation cant be obtained via the normal stats on the HG612 and I think you may need to get it from # xdslcmd info --pbParams for FTTC lines.
I've put together a version which hopefully will work. I've no way of testing it of course, so if it doesn't work, let me know.
You need to enable the option "Stats per band" in the pbParams section of Configuration --> Options.
http://www.s446074245.websitehome.co.uk/files/dslstats32W-3.71.zip
-
The errors have reset and the graphs are now working. This bear's brain is littler than before. :-[
-
Somewhat OT but can I use the command for extended router event log of the 582n in dslstats?
-
I am wondering, if until some of the matters are sorted I should revert to 3.6
You can if you want, but there were no changes to the program between 3.6 and 3.7 which would have affected the error reporting.
OT but what are the problems with making Windows64 versions?
The main problem is that I don't have a Win64 machine to build and test the program on. But there's little or no point anyway - the Win32 version of DSLstats works just the same on a Win64 machine.
Somewhat OT but can I use the command for extended router event log of the 582n in dslstats?
Sorry, but I don't know what you mean.
-
I think the command is
syslog msgbuf show hist=enabled. Is it possible to use that to make more comprehensive router log data available via dslstats?
-
I've put together a version which hopefully will work. I've no way of testing it of course, so if it doesn't work, let me know.
You need to enable the option "Stats per band" in the pbParams section of Configuration --> Options.
http://www.s446074245.websitehome.co.uk/files/dslstats32W-3.71.zip
Just downloaded it now and replaced the old 3.7.1.0 exe,, Will let you know how it goes
Thank you so much :)
-
>>> Somewhat OT but can I use the command for extended router event log of the 582n in dslstats?
If Ive understood you right, its not applicable for the 582n.
-
I think the command is syslog msgbuf show hist=enabled. Is it possible to use that to make more comprehensive router log data available via dslstats?
If that command (or any other) is available, you can enter it as a custom command in the Configuration --> Custom commands section.
-
Eric,
Just for info - yesterdays traffic usage is correctly displayed today, for two days prior to that the usage from past days vanished - hence me thinking it did not record it with shutdowns.
I don't know what has changed. I don't close down DSlstats when turning of the router or shutting down the PC so maybe something can go astray if sampling is in progress at the time of shutdowns.
-
Thanks for the report, Les. DSLstats saves its data when it's shut down manually, but I don't know what happens when it's closed down by Windows. This is something I need to check. If you turn off the router while DSLstats is recording, it ought to handle it without losing data, but again I need to look at this more closely.
-
Just downloaded it now and replaced the old 3.7.1.0 exe,, Will let you know how it goes
Thank you so much :)
It seems to be recording as follows:-
Down Up
U0 U1 U2 U3 D1 D2 D3
22 Jul 2013 02:22:51 0.0 0.0
-
Thanks Eric! How patient you are with my ability to forget! :)
One little thing: if I save a graph using the Windows commands Alt & PrtScn, the info below the actual graph is included in the jpg, but not when dslstats saves the graphs.
Most likely my rare personal opinion, but I would prefer dslstats to include the graph and the info below.
-
It seems to be recording as follows:-
Down Up
U0 U1 U2 U3 D1 D2 D3
22 Jul 2013 02:22:51 0.0 0.0
Yes, I realised after I uploaded it that it would still display the unwanted information which was already being displayed before this version. What it should have shown at the end, though, is a line like this:
Line Attenuation(dB): 0.8 17.9 29.2 N/A 11.1 24.5 38.8 (hopefully lining up with the U0, U1, etc labels).
I'll have a look at it later today.
-
Thanks Eric! How patient you are with my ability to forget! :)
One little thing: if I save a graph using the Windows commands Alt & PrtScn, the info below the actual graph is included in the jpg, but not when dslstats saves the graphs.
Most likely my rare personal opinion, but I would prefer dslstats to include the graph and the info below.
Yes, snapshots only cover the graphs themselves, not the other material. I'll have a look at the possibility of making it an option to snapshot the entire window, but it will have to take its place at the end of the queue.
-
It seems to be recording as follows:-
... etc
I'll have a look at it later today.
Try this one (executable only): http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip
-
Hi Eric,
Just a minor one from me. DSLStats keeps reporting the 'system uptime' incorrectly. It's currently saying system uptime is 2 hours, and the ADSL uptime is 30 days. The router has been on longer than the DSL connection so not sure if that's just my router or the program.
No big deal, just thought you might want to know :)
I also get quite a lot of 'No stats received' messages in the log
*EDIT*
Access violation is still occurring unfortunately :(
-
Can you copy the contents of Telnet data --> Connection stats to me please, so I can try to find what's going wrong.
-
Can you copy the contents of Telnet data --> Connection stats to me please, so I can try to find what's going wrong.
It's okay now, it seems to display the wrong time for the first couple samples, then displays the correct time. Do you still want the info?
-
Try this one (executable only): http://www.s446074245.websitehome.co.uk/files/dslstats.exe.zip
Lovely Jubbly thanks :thumbs:
U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
-
Can you copy the contents of Telnet data --> Connection stats to me please, so I can try to find what's going wrong.
It's okay now, it seems to display the wrong time for the first couple samples, then displays the correct time. Do you still want the info?
Yes please. I'm hoping it may help with diagnosing the access violations.
-
Lovely Jubbly thanks :thumbs:
U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
You're welcome. The only thing is that it's only supposed to copy that line when one of the values changes. Does it repeat every sample?
-
As it only records atten at startup and changes, theres only been that one sample so far. I will let you know if it continues to duplicate.
-
Thanks :)
-
I was out last nite and only just had chance to see what was going on
It would appear that its adding a new line each time it gathers stats
I have lots and lots of rows like this
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
-
I'm assuming you haven't currently changed the way errors are reported?
Also, telnet shows
Since Link time = 49 days 17 hours 2 min 46 sec
When actual Link Time is 58 Days 5 Hours and 24 Mins
-
I was out last nite and only just had chance to see what was going on
It would appear that its adding a new line each time it gathers stats
I have lots and lots of rows like this
I was afraid that might be the case, hence my question a few messages ago. It's clearly not extracting/recording the values correctly, so it thinks there's a change with every sample.
I'll get working on it.
-
I'm assuming you haven't currently changed the way errors are reported?
Also, telnet shows
Since Link time = 49 days 17 hours 2 min 46 sec
When actual Link Time is 58 Days 5 Hours and 24 Mins
I haven't changed the error reporting code since v3.6. When I see your telnet stats text I'll hopefully be able to make sense of the problems you've reported.
The link time issue is a bug in the Broadcom firmware - it stops incrementing the "Since link time" counter after 49 days and a few hours. What DSLstats does is, when the reported value gets over 49 days it switches over to reporting the AS (available seconds) value, which continues to increment properly.
-
I was out last nite and only just had chance to see what was going on
It would appear that its adding a new line each time it gathers stats
I have lots and lots of rows like this
Another one to try: http://www.s446074245.websitehome.co.uk/files/dslstats32W-3.73.zip
Don't just copy the executable. Copy all the files, because other things have changed. It would be best to start from a clean position, so either delete/rename dslstats.ini or copy this version to a different directory. You may even find that traffic monitoring works with this version if you select HG612 (VDSL2) in the traffic monitoring setup.
-
They're on page 1 I believe?
-
Another one to try: http://www.s446074245.websitehome.co.uk/files/dslstats32W-3.73.zip
Don't just copy the executable. Copy all the files, because other things have changed. It would be best to start from a clean position, so either delete/rename dslstats.ini or copy this version to a different directory. You may even find that traffic monitoring works with this version if you select HG612 (VDSL2) in the traffic monitoring setup.
ty eric
I moved all the old files out (aside from my logs), then started afresh with the new version.
Still getting this Im afraid
U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Line Attenuation(dB): 0.8 17.8 28.9 N/A 11.1 24.4 38.4
Also should there be a timestamp recorded for any changes?
-
Still getting this Im afraid
Oh dear, sorry about that.
Also should there be a timestamp recorded for any changes?
There should be really, yes, but I haven't provided it. I'll add it to the next version (when I find out what's causing the endless repetition :wall: ).
-
They're on page 1 I believe?
Sorry, I've done it again, mixing you up with someone else. I blame the heat and humidity. I think I'm going to go and cool down.
-
Eric,
After a few days and more tests I can't get the past days traffic saved in file with either a PC shutdown or a modem power down. However only a PC shutdown does not seem to matter as the full modem values pick up on PC startup and with only a modem shutdown the program seems clever enough to cope and not go to zero. It seems to be the combined PC and modem shutdown that is the issue.
Might the save action which occurs on program exit be allowed to occur with each sample. Perhaps via an option if it is a significant overhead. I guess that would be one fix.
-
After a few days and more tests I can't get the past days traffic saved in file with either a PC shutdown or a modem power down. However only a PC shutdown does not seem to matter as the full modem values pick up on PC startup and with only a modem shutdown the program seems clever enough to cope and not go to zero. It seems to be the combined PC and modem shutdown that is the issue.
Might the save action which occurs on program exit be allowed to occur with each sample. Perhaps via an option if it is a significant overhead. I guess that would be one fix.
What I was thinking of doing was save the traffic data once an hour, but perhaps more frequently would be appropriate. There's no significant overhead, so I can do it as often as needed. I'm splitting out the traffic data from the main dslstats.ini file, as I don't really want to be endlessly rewriting that for no reason.
-
syslog msgbuf show hist=enabled is included on my set up. For a period today therouter and computer were off ( all done properly to prevent DLM getting ideas!).
Looking at what the output from the command gave, I noticed that the dates are wrong
syslog msgbuf show hist=enabled
<85> Jan 1 00:00:08 FIREWALL has been enabled
<4> Jan 1 00:00:16 KERNEL Cold restart
<85> Jan 1 00:00:25 FIREWALL event (1 of 1): created rules
<85> Jan 1 00:00:25 FIREWALL event (1 of 1): modified rules
<82> Jan 1 00:00:32 UPnP framework disabled
<85> Jan 1 00:00:32 FIREWALL has been enabled
<82> Jan 1 00:00:35 UPnP framework disabled
<82> Jan 1 00:00:37 UPnP framework disabled
<82> Jan 1 00:00:42 UPnP framework enabled
<85> Jan 1 00:00:46 FIREWALL level changed to Standard.
<85> Jan 1 00:00:46 FIREWALL event (1 of 1): deleted rules
<148> Jan 1 00:00:46 DHCS server up
<173> Jan 1 00:00:54 xDSL linestate down
<3> Jan 1 00:01:02 [ANTI_SPOOFD] (err) llist_getobject_at for ENV.ANTI_SPOOFD's value failed
<173> Jan 1 00:01:24 xDSL linestate down
<37> Jan 1 00:01:46 LOGIN User admin logged in on [HTTP] (from 192.168.1.64)
<173> Jan 1 00:01:51 xDSL linestate up (ITU-T G.992.5; downstream: 6654 kbit/s, upstream: 811 kbit/s; output Power Down: 20.4 dBm, Up: 12.8 dBm; line Attenuation Down: 48.5 dB, Up: 26.9 dB; snr Margin Down: 6.1 dB, Up: 6.4 dB)
<38> Jan 1 00:01:52 PPP CHAP Receive challenge from rhost bras-red5.bs (Internet)
<38> Jan 1 00:01:54 PPP CHAP Receive challenge from rhost pcl-ag03 (Internet)
<38> Jan 1 00:01:55 PPP CHAP Receive success (Internet)
<132> Jan 1 00:01:56 PPP link up (Internet) [87.114.56.148]
<132> Jan 1 00:02:11 PPP link down (Internet) [87.114.56.148]
<38> Jan 1 00:02:16 PPP CHAP Receive challenge from rhost bras-red5.bs (Internet)
<38> Jan 1 00:02:17 PPP CHAP Receive challenge from rhost PCL-AG02 (Internet)
<38> Jan 1 00:02:17 PPP CHAP Receive success (Internet)
<132> Jan 1 00:02:18 PPP link up (Internet) [87.112.26.89]
<14> Jan 1 00:02:36 CONFIGURATION saved by TR69
<37> Jan 1 00:03:38 LOGIN User admin logged in on TELNET (192.168.1.64)
Is the incorrect dating something emanating from the router or a glitch in 3.7? I have seen it before, but only for ~3 lines, far fewer than in the example.
I understand most entries, but one Jan 1 00:01:02 [ANTI_SPOOFD] (err) llist_getobject_at for ENV.ANTI_SPOOFD's value failed. What the.....is that about! :-\ :)
My question on averages
How does the program deal with periods when there is no internet activity, i.e. computers etc /computers etc & router off?
My thinking is that if the seemingly "idle" periods' figures are included, there could be a false picture of performance.
But them I may have got my self in a twist. :o :)
-
Is the incorrect dating something emanating from the router or a glitch in 3.7? I have seen it before, but only for ~3 lines, far fewer than in the example.
Jan 1 00:00:00 is the router's default startup time. During its initialisation it tries to get the correct time from an internet source via NTP (Network Time Protocol). If it can't locate an NTP server, the time continues counting up from its default. It's not related to DSLstats (or any other monitoring program).
I'm afraid I have no idea what that line you quoted means.
Concerning the averages, on shutdown DSLstats saves the most recent values of the router's error counters, and tries to take appropriate action when it starts up again. As I've mentioned before, I need to give this area of the program some more attention because it doesn't always deliver correct results. This is on the todo list but not the highest priority at present.
-
Just wanted to say Eric, when I have been able to use the program, the traffic monitoring seems to have been working perfectly.
-
Thanks for that. There are some situations it doesn't cover properly, but I've been putting a lot of effort into improving it for the next release.
-
Eric I have a couple of minor niggles with a couple of graphs....
The max attainable rate on the speed graph still only shows at the default thickness of 1 pixel which does not show up clearly, can you make it so it displays at the same thickness as the main graph?
The FEC error graph is a bit tricky to know what to do, it does not seem to scale down once it reaches very high numbers, is it possible to scale it for the values actually displayed rather than the highest ever reached. It sits at 263470000 as the max value and with low FEC rates you get a flat line. A logarithmic scale shows it OK but with a max value of 100000000 (think that's the correct number of 0's). Maybe this happens when DSLStats is up for long periods, it did not reset when I power cycled the router.
Stuart
-
Stuart, those are fair points. The line thickness issue is an oversight on my part, and easily fixed.
I'm not entirely sure what to do about the FEC graph, because I think it's quite likely that the extremely high values you mention are themselves the result of a bug. Ryant704 reported some crazy values, and I believe that these may have been another instance of some values being too high for the type of variable I was holding them in. This is corrected in the next version. As to the general point, I don't really want to continually change the scaling to suit the range of values on view, because that would make horizontal scrolling a nightmare. With linear scaling you've got the option to clip the highest value, and perhaps I should retain the possibility of clipping when using a logarithmic scale?
-
Eric the FEC thing is manageable but would be good if you can find some way to improve it. I was wondering if those very very high values were real or as the result of a bug either in DSLStats or the router irmware.
Stuart
-
I'll do my best.
Concerning the line thickness issue, I think that this is actually a peculiarity of Windows (or maybe only on older versions of Windows?). Thick dotted lines display in DSLstats as you would expect on both my Linux systems (with KDE) but not on Windows. On Windows a dotted line 3 pixels wide is actually displayed as a series of little + shapes, whereas on Linux they are displayed as short thick dashes. I'm not sure what to do about this - I've tried different line styles, but none of them look good in Windows. Perhaps the thing to do on Windows is that when the line thickness is greater than 1 then the max attainable line is shown as a single thickness solid line. What do you think?
-
I'll do my best.
Concerning the line thickness issue, I think that this is actually a peculiarity of Windows (or maybe only on older versions of Windows?). Thick dotted lines display in DSLstats as you would expect on both my Linux systems (with KDE) but not on Windows. On Windows a dotted line 3 pixels wide is actually displayed as a series of little + shapes, whereas on Linux they are displayed as short thick dashes. I'm not sure what to do about this - I've tried different line styles, but none of them look good in Windows. Perhaps the thing to do on Windows is that when the line thickness is greater than 1 then the max attainable line is shown as a single thickness solid line. What do you think?
Eric I would not worry that much, I thought it would be a simple fix :no: blame Windows (2K in my case). I only mentioned it because I thought it would be easy. If it is better in XP or 7 (or 8 ) then leave well alone, dont mess it up because I have a dinosaur Windows.
Stuart
-
Thanks Stuart. I thought it would be a simple fix too. I'm using Win2K as well, in a virtual machine, to build and test the Windows version.
I'll see if I can find a way to improve this, but I won't spend too much time on it. :)
-
Minor colour scheme issue: Traffic stats graph.
I've changed my downstream graph colour from the default(red) to blue.
This change is not reflected in the newly added traffic stats graph which remains as red for the download.
If I change the upstream to say purple just as a test this change is not reflected either and the traffic stats upstream remains as green.
So the graphing function is not picking up any graph colour configuration change
This is Win XP F.Y.I.
-
Thanks for the report. It's corrected in the next version.