Print

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

[roseway]

Ok think Ive solved this dslstats.cfg now becomes dslstats.ini which is why it didnt come up when I searched.

You've been working too hard. It was always dslstats.ini.

Eric Im not sure if you want to add a note to this effect on your site for windows users, as they may like me have been lookin under app roaming.
The problem is though its likely to be different for XP
Likely c:\documents&settings\username\applicationdata\dslstats.  Can an XP user confirm this please.

It asks the operating system for a pathname to the correct directory for configuration files, so it very probably will vary between Windows versions. When you first run this version of DSLstats it copies the relevant files from the old position to the new (if they exist in the old) and adds an entry in the event log to show the new pathname. I'll do what you suggest and add a note about this on my site, and I could also display the pathname in DSLstats somewhere, so it can always be found.

(I made this change in response to a request from another user. It seemed to be the right thing to do, and it didn't occur to me that some users would prefer to keep the config files where they were.)

[c6em]

Under XP the .ini file is in.....

c:\Documents and Settings\username\Local Settings\Application Data\dslstats

[burakkucat]

I regret that I have to report yet another 'peculiarity' . . . 

Enter the utility. Configure --

Configuration ---> Snapshots and in the Autosave graphs: list, select ES per hour.

Start the utility. Stop the utility. Exit the utility.

Enter the utility. Check --

Configuration ---> Snapshots and in the Autosave graphs: list, ES per hour is found to be deselected. 

[roseway]

There's no need for regret. Bug reports are an essential part of development. Will be fixed in the next release.

[burakkucat]

Purrfect. Thank you. 

[ryant704]

A couple of questions, not sure you can answer them as of yet! but possibly!

Okie, 2 days ago my firmware was updated and I'm connected to an ECI Cabinet. Ever since my BitLoading is shown as 'Other Data' (Every single last bit! It's in blue!). See the screenshots, should explain my question!

Note: I've re-synced a couple of times and it still appears this way! Also, I still have the dip in the upstream, I will add it I think just so you can remember!

The QLN graph show's 1 US and DS band correctly but my connection isn't using one of these tones (bands), could be relevant. My Hlog graph is black (as in the line) and I've never used black to display anything.

I wonder if it's the program or the cabinet causing this? Is the real question!

[snadge]

is there any chance of showing the error averages (such as CRC / ES / FEC) using data from "since link time" as well as the current format which is since the app started recording the data... just this would help generate better averages for those who dont want to leave the computer on and running 24/7



my average CRC account from above stats would be about 8.6 CRC's per hour - but since I logged on today at 1pm (and left it running just so i could get a picture of average CRC's) it currently says 4.9 CRC's per hour (its now midnight)

basically I would love to know what my avg hourly CRC count is since link up time.

be great if you could implement this? if not guess I will have to use calculator 

[burakkucat]

Regarding your QLN graph.

Please remember that is it only measured once before the xDSL signal is applied to the pair. Basically the entire spectrum is 'swept', listening for any signal that may be present at each tone. It is meaningless to talk of usage of US and DS bands when considering the QLN data . . . for there are no such bands present, as there is no xDSL signal present on the pair.

The question that, therefore, comes to mind is Perhaps the QLN graph should be plotted using only one colour? That is quickly followed by the answer No, for the colours indicate where the different xDSL bands will be located . . . once the signal is applied to the pair.

I hope that makes sense. 

[ryant704]

Regarding your QLN graph.

Please remember that is it only measured once before the xDSL signal is applied to the pair. Basically the entire spectrum is 'swept', listening for any signal that may be present at each tone. It is meaningless to talk of usage of US and DS bands when considering the QLN data . . . for there are no such bands present, as there is no xDSL signal present on the pair.

The question that, therefore, comes to mind is Perhaps the QLN graph should only be plotted using one colour? That is quickly followed by the answer No, for the colours indicate where the different xDSL bands will be located . . . once the signal is applied to the pair.

I hope that makes sense. 

I understand that fully my point was the change of colour and to help him find all the bugs by this update.

In this picture (before firmware update) you can see the 'Other data' is the correct colour, so is the downstream. You can't see the upload but the colour was correct for it. That is one benefit of this update all the features are now working in DSL stats again! Just need to iron some bugs out!

[roseway]

The problem seems to be that, since the firmware update, DSLstats isn't detecting the band plan correctly. I'm guessing that the actual plotted data is correct but the colours are wrong. The band plan information is extracted from the output of the pbParams command, so if you could copy that data to me I'll try to find out what's going wrong.

[roseway]

@snadge: In principle I could do that, but quite a lot of modem/routers don't provide the "Since link time" data, so there would be some extra sorting out required. I'll put it on the todo list, but I'm afraid it will have to take its place in the queue.

[broadstairs]

Eric another thing perhaps for your list... could you add a timestamp on the output recorded for custom commands please? It would help to tie down when say an IP change happened.

Stuart

[roseway]

Yes Stuart, I can do that.

[broadstairs]

For now (and for anyone else who needs it) I also issue a date command which prints the routers date & time in the output.

Stuart

[broadstairs]

Another suggestion for the to-do list Eric. Could you add a tick box to custom commands which would cause it to write the output to the event log? This would mean that all the data would be in one place and captured by saving the event log.

Stuart