Print

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

[broadstairs]

Eric no problem I will experiment some more, I tried 0.0.38 but was not happy with the data. I'll keep trying and if I find a good setup I'll post back.

Stuart

[roseway]

Thanks Stuart.

[rhohne]

RE: HG622
When I used the HG622 the br0 and ppp256 TX Byte counts were all over the place eg 2237891741,2550858748,92021098,3475861248. This would of cause play havoc with any 4GB wrapround calculations.

The only interface to consistently increment the count was 0.0.38. Having said this after a couple of days, during which time the totals matched, the PlusNet and router daily totals were out by over 1GB. Never did get to the bottom of this because I reverted back to the netgear.

[broadstairs]

Its funny because on my HG622 currently the figures in ppp256 seem to me to be reasonable values but the totals shown at the bottom of the traffic screen seem to bear no resemblance to these totals. The today traffic stats are significantly more than I download in a month - over 40gb, the month figures are not unreasonable for this early in the month.

Eric can you explain the logic behind how you obtain the traffic estimates, this will allow us to make a judgement on what to expect from each of the possible interfaces.

Stuart

[roseway]

The logic is as follows. This happens with each sample:

1. Read the values of RX bytes and TX bytes for the selected interface.
2. Compare the values with those from the previous sample.
3. (a) If both have increased then add the differences to the daily and monthly totals (up and down)
    (b) If just one has increased then add its difference to the daily and monthly totals (up or down as appropriate). Assume that the other one has wrapped round, and add its new value to the daily and monthly totals (up or down as appropriate)
    (c) If both have decreased then assume a resync/reboot has occurred and add the new values to the daily and monthly totals (up and down). This would also apply if by coincidence both counters had wrapped round prior to the latest sample.
    (d) If both new values are zero, ignore this sample.

[kitz]

Replacement version 3.82 now available.

http://dslstats.plainroad.me.uk

Thank you eric 

Couple of questions please if I may.

1) I'm never quite sure when I can just replace the .exe file and ignore the other files.  Mostly I just replace the .exe as otherwise I have to re-do all my settings.

2) Im not sure if you are aware, but if the modem is disconnected from the line then DSLStats abruptly closes without saving any data.  This has happened several times now.  The last time it did this was when the engineer arrived and he just pulled the cable from the HG612 leading to the master socket, which caused DSLstats to crash. 

It last did an auto-save at 04:56, but I lost the data which I'd previously been able to see showing the kick-in of EMI like spikes which started at 5am, including the loss of 12dB of SRm when he called me at just before 8am to say he was on his way. 

I have the graph set to display 4hrs per page, so I lost practically the full 4hrs when he pulled the plug.  Is there a way to do a quick manual save of all graphs (like the take snapshot button) , or is the auto save totally linked in with the display time per page.

[broadstairs]

Eric my current values for today on 0.0.38 are 2329156706 downstream and 199598225 upstream and are incrementing slowly about inline with what I'd expect, although as you say they are reversed. Now the totals showing are 40GB down and 6GB up which in now way is correct for today. The month totals are similar and nothing shows on the month graph, although these values do show on the today graph.

Something is going wrong somewhere, and I have tried resetting the totals.

Stuart

[roseway]

@Kitz:

1) There are some supporting files which aren't essential to the functioning of the program but define the default settings which are applied when you select a router model from one of the drop-down boxes. These are routers.dat, specialrouters.dat and routertraffic.csv. You should make sure these are up to date. There's a summary of the various files at http://www.s446074245.websitehome.co.uk/installation.html .

2) No, I wasn't aware that DSLstats crashes if the modem is disconnected. It doesn't do it here. I'll check it out.
There's an option in the Graphs section of Configuration "Snapshot all active graphs on exit", so if you enable this option (and have the opportunity) you can just close DSLstats before pulling the plug. I could easily add a button to do this manually as well.

[roseway]

@Stuart:  OK, I'll see if I can find out what isn't working properly.

[kitz]

@Kitz:

1) You should make sure these are up to date. There's a summary of the various files at http://www.s446074245.websitehome.co.uk/installation.html .

Thank you, so in future all replace all files (except dslstats.ini, trafic.ine & errors dat).   I thought Id post, because if I was wondering then its likely that others could also not be sure.

DSLstats crashes if the modem is disconnected.

It doesnt do so if its a loss of sync, just if the connecting cable is pulled.   Obviously this shouldnt happen often..  but it does seem to be something the engineers do, and its also happened once when I was moving the modem.  At first I thought it may have been co-incidence but its happened a few times now.

[roseway]

Eric my current values for today on 0.0.38 are 2329156706 downstream and 199598225 upstream and are incrementing slowly about inline with what I'd expect, although as you say they are reversed. Now the totals showing are 40GB down and 6GB up which in now way is correct for today. The month totals are similar and nothing shows on the month graph, although these values do show on the today graph.

Something is going wrong somewhere, and I have tried resetting the totals.

Stuart, I think I've worked this out now. The problem isn't in the collecting and plotting of the data, it's the fact that the monthly reset doesn't work properly.

Could you close down DSLstats if it's running, delete or rename dslstats.ini and traffic.ini, and restart DSLstats. You'll have to set it up again of course, for which I apologise. Hopefully, after that the traffic monitoring will report proper results with interface 0.0.38 and RX/TX reversed.

I'm sorry for this imposition, but at present it's the only way to clear the incorrect data.

[broadstairs]

Eric I've done what you suggested and then a bit of testing (which requires deleting and restarting but hey that's what testing is about    ). Anyway at least for me the 0.0.38 interface for me shows the best approximation of my real traffic. For some reason ppp256 interface seems to be in cloud cuckoo land as far as traffic is concerned - at least on my HG622. BTW 0.0.38 is not reversed as you said. Anyway with my test 0.0.38 seems best so now I'll let it run a few days  and see what happens.

Stuart

[broadstairs]

I've been thinking about this some more and doing some reading up. The more I look into it the more I feel it should be PPP256 which is monitored however my tests so far have not proved it reliable. I used to run a router with SNMP so I have an idea of what my normal usage should be. I am thinking that I'll give the 0.0.38 a few days to see what it's like before the next test. What I am thinking is to power cycle the router which should clear all the counters and start DSLStats monitoring at that start up using ppp256 and see if the figures tally with what I expect, that way everything starts form the same point.

Stuart

[roseway]

Thanks for doing these tests, Stuart. I was a bit unsure about whether the 0.0.38 interface should be reversed, as I've received slightly conflicting information from two sources. I just hope that one of these had been doing a lot of uploading, which might account for the higher value for TX.

[krypton]

I figured out that the reported traffic values from /proc/net/dev sometimes are unreliable. Most time they count up correctly but suddenly the download counter jumps backwards.
This causes dslstats to display much more traffic.
Maybe I am not the only one who is affected because the ifconfig command uses the same values.
You could implement a plausibility check and print a warning if inconsistent values are received.