Print

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

[xreyuk]

Hi Roseway,

I'm still new to Linux and was wondering if you could help.

How would I go about getting dslstats to start automatically on boot?

I'm currently running debian.

Thanks

[roseway]

Hi xreyuk,

For a GUI program like this, autostarting a program is a desktop function, so the method depends on what desktop you use. With KDE it's easy - there's a folder <your home directory>/.kde/Autostart and all you have to do is put a link to the executable in that folder. I'm afraid I don't know about other desktops, but you might find the answer in the Debian user forums http://forums.debian.net/ .

[roseway]

Thanks Colin. I'd still like to validate the averages, and I think I can do that, but it will take 24 hours.

Actually, there's nothing much to validate here. The averages are calculated directly from the totals reported by the router at the start and end of the averaging period, and there's little scope for error in the normal running situation. A check over the last 24 hours confirmed that the averages were correct. Where errors could arise is when there's a re-sync or some other event which resets the totals. I think I've properly covered that situation (unless somebody reports otherwise).

[ColinS]

Thanks Eric.

Just for my education, by

the totals reported by the router at the start and end of the averaging period

are you referring to the 15min and 1day periods of the router stats, or e.g. a 24hr period from the start of DSLstats? 

[roseway]

I'm referring to the cumulative totals reported by the router:

Code: [Select]

Path 0
SF: 9890971 516400
SFErr: 950 566
RS: 573676243 1769321
RSCorr: 32667 1668
RSUnCorr: 8472 0

RSCorr = FEC
SFErr = CRC
etc.

While DSLstats is running it takes a note of these totals at 24-hour intervals and uses the difference between the totals at two successive 24-hour points to calculate the error rates for that period.

[ColinS]

  Thanks.

[xreyuk]

Hi xreyuk,

For a GUI program like this, autostarting a program is a desktop function, so the method depends on what desktop you use. With KDE it's easy - there's a folder <your home directory>/.kde/Autostart and all you have to do is put a link to the executable in that folder. I'm afraid I don't know about other desktops, but you might find the answer in the Debian user forums http://forums.debian.net/ .

Thanks Eric.

I though it would have to be done in command line, but I've just added it to the GNOME startup applications.

[roseway]

Excellent.

[xreyuk]

Also I forgot to ask, I'm assuming a disconnect will show in the event log?

I also don't know if you remember the problem I was having with an access violation whilst this program was still rsux? I had the same problems with DSLStats, but changed the permissions on my config directory from 775 and 777 and this seems to have fixed it.

Thanks again!

[roseway]

Yes, there should be an entry in the event log when the connection drops. Normally it will say "No DSL connection" possibly more than once, depending on how long it takes to reconnect. If the connection drops while it's in the middle of sampling you may see other log messages.

Regarding the permissions on your config directory, it has to be writeable for the user running DSLstats. I'll add a check to warn the user if there's a problem with writing there.

[Bald_Eagle1]

I'm referring to the cumulative totals reported by the router:

Code: [Select]

Path 0
SF: 9890971 516400
SFErr: 950 566
RS: 573676243 1769321
RSCorr: 32667 1668
RSUnCorr: 8472 0

RSCorr = FEC
SFErr = CRC
etc.

While DSLstats is running it takes a note of these totals at 24-hour intervals and uses the difference between the totals at two successive 24-hour points to calculate the error rates for that period.

I have no idea how other modems/routers operate, but the HG612 does reset a number of its stats to zero once the integer limit has been reached, so that MAY just skew the use of averages over a 24 hour period.


I believe this is the HG612's limit before resetting stats (e.g. RSCorr/FEC errors) back to zero:-

2^32 or 4,294,967,296

That seems a huge cumulative total, but I have seen it exceeded within much less than 24 hours on a number of connections, particularly when a HG612 is connected to an ECI VDSL2 DSLAM.

 

[roseway]

Thanks, I wasn't aware of that. I'll check the code again to make sure that it's handled properly, but I think it is (if DSLstats sees a cumulative total value which is less than the previous value, it assumes that a reset has taken place, unless the value is exactly zero, in which case it's ignored as a missing sample).

(Later) I've checked the code, and I see that I've been storing these values in signed integers (maximum positive value 2^31) so there's a possibility of wrong values being reported when FEC rates are very high. I've now corrected this by storing the values in unsigned integers (maximum value 2^32). Apart from that, the program does handle resets of these values correctly, by saving the current error data as a text file and resetting the error data.

[c6em]

Not too sure if this is intentional/a feature whatever

My tones plot graph is constantly re-scaling back and fro between samples
So on one sample the LHS scale is up to 22 bits and the RH up to 66 SNR
Then at a next sample the scale swaps to 24 bits/72 SNR as a max on the scale (max SNR is actually 19
and so on - its not changing every single time methinks but is does quite a bit, so the whole graph is moving from sample to sample.
I only noticed this as I was looking for which tone was changing by spotting the jump and discovered I couldn't really do it as the entire graph jumped when it re-scaled the plot between samples.

[roseway]

It shouldn't rescale unless the data requires it to do so, so it looks as though you've uncovered a bug. Fairly recently I changed the scaling of that graph so that the SNR and the bitloading are properly proportional (3 dB SNR corresponds with 1 bit) and I may have got the rescaling slightly wrong at that time. I'll check it out.

[c6em]

I looked a bit closer and I think I know why its re-scaling.
My router has some sort of bug that it doesn't on some/regular occassions report the upstream SNR values - they are just zero.
This U/S SNR peak is the highest value - so it is the scale determinator.
So when the data returned DOES include the U/S SNR value then it re-scales it to 24 bits max/72 SNR
But when the data returned does NOT include the U/S SNR the max is SNR in the data is lower so it scales it lower to 22 bits/66 SNR.
Hence the back/fro swapping.

If I opt not to include the SNR value on the bitloading data graph then the bit loading data scaling does not change from graph to graph: - its always scaled upto 24 bits.
Ironically the now separate SNR/tone graph is scaled up to 60 SNR regardless of whether the U/S section is there or not!
The problem only occurs when they are both plotted on the bits/tone graph.

OK, so it is router bug causing the scaling to flip flop --------