Print

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

[roseway]

Now replaced by v3.82

This version improves the traffic monitoring function in several ways. If you've been using this function in v3.7 the new version will reset the latest month's data, so you should snapshot the data before upgrading if you want to keep the information.

Full list of changes since v3.7:

- fixed "xxxx is not a valid integer" issue
- improved the way in which FECs and CRCs are recorded and graphed
- fixed bug which resulted in reported average error rates increasing when closing down  and restarting program
- improved the consistency of the traffic monitoring data under various conditions
- made some corrections to the traffic monitoring setup for some routers
- added option to reverse the RX/TX values for traffic monitoring (appears to be necessary with some modem/routers, such as HG622)
- traffic monitoring data is autosaved every 10 minutes
- added option to show maximum monthly allowance on traffic monitoring monthly graph
- added option to monitor signal attenuation values on VDSL2 connections
- corrected issue whereby the traffic monitoring chart didn't respond to colour changes
- fixed display malfunction on Connection speed graph when scrolling back to a paused section
- QLN and HLog graphs (if enabled) are now refreshed after a resync
- the IP address is now always refreshed after a resync

http://dslstats.plainroad.me.uk

[kitz]

Thank you Eric for releasing this.

I will install later, as previous version is atm nicely graphing my upstream SNRm having a bit of a hissy 

[burakkucat]

Thank you, Eric.

I shall be interested to see if sensible figures for the traffic are now recorded. 

[roseway]

I shall be interested to see if sensible figures for the traffic are now recorded.

I think they should be sensible, but they may not be accurate. I'm still unsure about the correct interface for the HG622 - this version sets it to ppp*** together with RX/TX reversal, but it perhaps should be 0.0.38, also with RX/TX reversal.

[burakkucat]

I am able to make a preliminary report.

Selecting 'Reverse RX/TX' option does, indeed, show things 'the right way round'. The actual data recorded is . . . phenomenal. I have not downloaded over 22 GB in a matter of moments! 

It appears that monitoring the 'ppp256' interface of a Huawei HG622 does not provide the correct data, although that is the only interface which has my external (public) IP address associated with it.

There also appears to be a problem with displaying the month and year on the traffic graph. Example images are attached, below.

[roseway]

Thanks for that report.

Concerning the interface, I'm in a rather similar position with the HG612: the interface which has my external IP address is ppp256, but I noticed that it under-reports the upstream data. I've changed over to using atm1, and this delivers results which match actual uploads and downloads which I've made experimentally.

Regarding the incorrect month and year, I can't explain this at the moment, but if you don't mind I would like to suggest that you close down the program, delete or rename dslstats.ini and traffic.ini, and restart the program (just to make sure that it isn't being confused by historical data).

[burakkucat]

The incorrect month & year issue has been resolved by moving the dslstats.ini file and allowing it to be re-created.

(Of course that meant that I had to respecify all my requirements . . .    )

[roseway]

Thanks for that, and sorry for the trouble.

[burakkucat]

'Tis no trouble. 

[roseway]

I've temporarily withdrawn this version, while I deal with the update issue discussed above.

My apologies to all.

[roseway]

Replacement version 3.82 now available.

http://dslstats.plainroad.me.uk

[xreyuk]

Hi Eric,

Just wanted to check regarding traffic monitoring, your DGN2200 profile is asking to check 'other' interface, but I on the previous version it was checking ATM0. Is this because you're using the custom firmware, or is this correct?

[roseway]

Just wanted to check regarding traffic monitoring, your DGN2200 profile is asking to check 'other' interface, but I on the previous version it was checking ATM0. Is this because you're using the custom firmware, or is this correct?

I don't really know what 'correct' is. Looking over the data I've got, it seems that Other / nas1 worked with my DGN2200 with the custom firmware, but your DGN2200 may not have that interface. So perhaps you need to go back to atm0. Sorry, but getting the right interface is proving very problematical.

[broadstairs]

Eric I have installed 3.82 and am having a problem with my HG622 finding anything which will give sensible values for downstream traffic, so I thought I attach my data for your perusal.

Code: [Select]

ifconfig
0.0.38    Link encap:Ethernet  HWaddr 04:C0:6F:E8:B8:49 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2119049 errors:616 dropped:0 overruns:0 frame:0
          TX packets:1614854 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2259028954 (2.1 GiB)  TX bytes:192873672 (183.9 MiB)

br0       Link encap:Ethernet  HWaddr 04:C0:6F:E8:B8:48 
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1042963 errors:0 dropped:0 overruns:0 frame:0
          TX packets:109050546 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:59444064 (56.6 MiB)  TX bytes:4015106034 (3.7 GiB)

eth0      Link encap:Ethernet  HWaddr 04:C0:6F:E8:B8:48 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1696694 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1595621 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:231454661 (220.7 MiB)  TX bytes:1066253214 (1016.8 MiB)
          Interrupt:40 Base address:0x6a00

eth0.5    Link encap:Ethernet  HWaddr 04:C0:6F:E8:B8:48 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1696694 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1595621 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:231454661 (220.7 MiB)  TX bytes:1066253214 (1016.8 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:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2496 (2.4 KiB)  TX bytes:2496 (2.4 KiB)

ppp256    Link encap:Point-to-Point Protocol 
          inet addr:92.20.126.188  P-t-P:92.20.112.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:453963 errors:0 dropped:0 overruns:0 frame:0
          TX packets:393381512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:42494524 (40.5 MiB)  TX bytes:3863206852 (3.5 GiB)

sar       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:966111 errors:0 dropped:0 overruns:0 frame:0
          TX packets:966111 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1398217905 (1.3 GiB)  TX bytes:1398218269 (1.3 GiB)
          Interrupt:50 Base address:0x5220

swc       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:452200 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:26202122 (24.9 MiB)  TX bytes:0 (0.0 B)
          Interrupt:42 Base address:0x6a40

#

The graph screen showed traffic totals as

Code: [Select]

today 1.26mb (1.21mb)     32.52gb (31.02gb)
month 1.43mb (1.43mb)     39.23gb (37.41gb)

note that these totals were written down before the telnet data was captured so they wont agree exactly with the ppp256 stuff above.

Stuart

[roseway]

Stuart, it's very difficult to decide from one snapshot of the ifconfig output. What matters is how the RX and TX values change over time, and it's complicated by the fact that the counters wrap round to zero when they get to 4 GiB.

Although the ppp256 interface seems to be the logical one to choose, it isn't necessarily the right one. On my HG612, for example, I was using ppp256 but I've recently established that the atm1 interface is the one which delivers figures which actually match up with known upload and download quantities. In the case of your HG622 it might be 0.0.38 (which doesn't need reversing) or br0 (which does).

I'm afraid the only solution is experiment - reset the monthly values, choose an interface, then upload and download some known volumes of data and see what happens to the reported figures.

Sorry that I can't give you a simple answer, but without lots more experiments with different routers there isn't a simple answer to give.