Print

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

[roseway]

Maybe you can fix this little things:

- Save the "Autoscale Y axis" setting to the config file.

Yes, the option to scale manually was originally conceived as a temporary option rather that a permanent switch, but I agree that it should be saved.

- Remove the "List index (0) out of bounds" error if the dslstats.ini isn't existent (windows only).

As this is Windows only, I think I can see where to look for the cause.

On the last line of the pbParams data some additional characters are displayed. On the linux version I saw an error in the log about malformed pbParams data. It seems not to cause any problems but I want to let you know about it. This affects version 4.53 too.

As I don't have VDSL2 yet, I won't be able to reproduce this, but I'll see if I can find where these characters are coming from.

[roseway]

Eric maybe spoke too soon about per minute vs per sample. I had a spike showing about 66 CRCs per sample max with just a some either side and the event log showed 66 CRCs per minute but when I switch to per minute graph it shows over 270 CRCs per minute at this time. Should the event log always show the alert as per minute or will it show what ever you have selected to display?

Stuart

I hadn't thought about the alerts reflecting the state of this option, but obviously they should do so. Concerning the wrong conversion of the spike, I can't explain this at present; I'll have another look at the scaling/plotting calculations.

[broadstairs]

I hadn't thought about the alerts reflecting the state of this option, but obviously they should do so. Concerning the wrong conversion of the spike, I can't explain this at present; I'll have another look at the scaling/plotting calculations.

I'm not sure if the sums add up or not, it is not easy to see all the sample point in that minute on the graph as I sample now every 15 seconds so there could be potentially up to 5 samples in a minute and there was at least one with 66 CRCs but there were others each side but it is not possible to see their values with a 1 hour graph span.

This might be a difficult suggestion but another program I use (for a different thing) allows the user to select a piece of the graph with the mouse and then expands it to fill the entire graph - it auto resets on the next update. Would the graphing component allow such a thing? If it did it would be possible to see values under these circumstances.

Stuart

[NewtronStar]

OK, thanks. I can see that you're right, and I didn't save that setting. I'll check out the HG612 myself a bit later, and I'm sure I can resolve this.

Had a chance to run DSLstats V4.54.7 on Windows 8.1 to-day and it's working fine even after reset login config, no incorrect username & password issues and no need to tick (not HG622 type)so me thinks this more to do with my Vista OS 

What do you think Eric.

[roseway]

I'm not really sure. I've installed an HG612 here, and it's been running since about 10:45. In that time it's run without problems except for two samples at different times, which wrongly identified it as an HG622 and therefore failed to log in. I'm tentatively coming to the conclusion that the HG612 (and no doubt some other models) sometimes takes longer to respond to telnet logins. The (equally tentative) solution would be to increase the timeout time for the first response.

[roseway]

I'm not sure if the sums add up or not, it is not easy to see all the sample point in that minute on the graph as I sample now every 15 seconds so there could be potentially up to 5 samples in a minute and there was at least one with 66 CRCs but there were others each side but it is not possible to see their values with a 1 hour graph span.

This might be a difficult suggestion but another program I use (for a different thing) allows the user to select a piece of the graph with the mouse and then expands it to fill the entire graph - it auto resets on the next update. Would the graphing component allow such a thing? If it did it would be possible to see values under these circumstances.

The per-minute values are calculated on a sample by sample basis - the per-sample values are multiplied by 60 and divided by the number of seconds since the previous sample, to give a per-minute rate for that sample only. The values of neighbouring samples don't come into it.

I could do it differently, by using actual numbers of CRCs (or FECs) over a one minute period. But of course it's possible to set a sample time which isn't a sub-multiple of 60 seconds, or which is over 60 seconds, so this would still involve some approximation.

I'll give this some more attention soon, but for the moment I'm going to concentrate on getting the present arrangement to deliver accurate results.

Concerning the possibility of a zoom function, that's an interesting suggestion and I'll have a think about it.

[broadstairs]

Eric I do now understand how your current calculation works for the per minute. However I'm not sure it is truly representative of what is happening, it only shows what would be the number of CRCs if that number happened every second of the minute. I think that in a program such as yours the purpose is to show accurately what is in fact happening. In my case the actual rate might be say 60 for a minute (with a single spike) but your per minute rate would be 240 with a 15 second sample time. I understand the issues of the sample times but in my view it would be better to sum the actual number of errors in that whole minute. I accept that there could be a certain amount of approximation but the per minute rate given would, I think, still be much closer to the actual than the current method.

Stuart

[roseway]

Fair enough, Stuart, I'll take a serious look at that.

[broadstairs]

Fair enough, Stuart, I'll take a serious look at that.

Thanks Eric. Perhaps one way to simplify things right now would be to allow the user to select per sample alerts instead of per minute, I realise that there may be more alerts that way but in cases like mine it would be helpful.

Stuart

[roseway]

Thanks Stuart, yes, that's what I'll do at this stage. I've had a look at what's involved in changing the basis of the per-minute values, and it's quite substantial. What I'd like to do is just clean up the present arrangement so I can release this version, then change the per-minute calculations next time.

[broadstairs]

Thanks Stuart, yes, that's what I'll do at this stage. I've had a look at what's involved in changing the basis of the per-minute values, and it's quite substantial. What I'd like to do is just clean up the present arrangement so I can release this version, then change the per-minute calculations next time.

Eric whatever you decide is fine by me....

Stuart

[NewtronStar]

What I would love is a Stats Movie player so I can see how my SNRM wax's and wane's over a year, I did try this a few months ago using Windows Movie maker but it turned out like a slow slide show 

[roseway]

I fear that one will be beyond me.

[roseway]

Summary of situation so far:

(NewtronStar) - HG612 wrongly detected as HG622 - I've increased the timeout time for auto-detection, and DSLstats has now been running for 36 hours with an HG612 with no login errors. The HG622 override settings are now saved between sessions.

(Broadstairs) - Message re HG622 detection repeated every sample - this event log message is now shown only once per recording session.

        - Alert triggers for CRC and FEC don't correspond with per-sample / per-minute option - when setting up the alerts for these values you can now opt for the triggers to be per-sample or per-minute. More work on CRC and FEC graphs to be done later as discussed above.

(morphium) - "Autoscale Y axis" setting not saved - this setting is saved now.

        - "List index (0) out of bounds" error when dslstats.ini doesn't exist (Windows only) - I can't reproduce this, but I've found one possible cause, which is now corrected.

        - Spurious characters at end of last pbParams line - now corrected.

[NewtronStar]

When can we expect the pre-release version of 4.54.8 have had to go back to 4.54.4 as 4.54.7 was doing my head in