Print

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

[roseway]

No new features, but several detailed fixes and improvements.

Changes since v3.94:

- fixed issue whereby a right-click on the bitloading chart selected wrong tone when the value
  of pixels per tone was set to 1 or 2
- fixed issue whereby compressing the horizontal scale of the bitswaps per tone graph didn't reveal
  data to the right of the graph
- fixed issue which resulted in the first hour of the day not displaying any errored seconds data
- fixed issue which occasionally resulted in "List index (256) out of bounds" error with some routers
- made some changes to the handling of Thomson routers to improve and extend compatibility
- added Thomson TG589vn v3 to the "compatible" list

Changes already included in v3.95 (not generally released):

- errored seconds chart data is now automatically saved once an hour
- the bitswaps per tone chart can now be expanded / compressed by a variable amount

[Remaining changes apply to Windows version only, for users of HG612-Modem-Stats]
- the "synchronise" option has been moved to the Misc section and renamed "HG612-Modem-Stats co-operation"
- the above option now does the following:
  - sets sample repetition to 1 minute
  - delays recording start as necessary so it starts between 35 and 40 seconds after the minute
  - checks before each sample to see if one of the HG612-Modem-Stats programs is running, and if so
    that sample is aborted and an entry is made in the event log

http://dslstats.plainroad.me.uk

[ColinS]

Implemented, thank you Eric.

[roseway]

My pleasure

[burakkucat]

Downloaded to The Cattery . . . and now being tested. 

[roseway]

Purrfick

[broadstairs]

Running fine here on W2K ...

Stuart

[roseway]

Thanks Stuart.

[burakkucat]

I have a minor 'mishap' to report. 

Having configured the utility to save the Traffic and Error Seconds graphs on closure, I was pleased to see that both were duly present in the Snapshots directory.

However the name given to the Traffic graph file does not look as if it is quite what it should be. 

[roseway]

Ah yes, that doesn't look quite right.

(Later) Fixed in next version

[ColinS]

Eric,

Some good news ... your coexistence strategy is working well.  See here:
20 Sep 2013 12:56:05   Option "HG612-Modem-Stats co-operation" was set
20 Sep 2013 12:56:06   Average errors saved as 'errors54.txt' in snapshot directory
20 Sep 2013 12:56:06   Average error data reset
20 Sep 2013 12:58:53   Recording started

20 Sep 2013 12:59:54   IP address is now ....
20 Sep 2013 13:00:51   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-06
20 Sep 2013 13:00:51   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-07
20 Sep 2013 13:00:51   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-08
20 Sep 2013 13:00:51   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-09
20 Sep 2013 13:00:51   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-10
20 Sep 2013 13:00:52   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-11
20 Sep 2013 13:00:52   Deleted snapshots in folder F:\DSL_Stats\DSL_Snapshots\2013-09-12
20 Sep 2013 23:58:35   1 instance(s) of HG612_stats.exe running, sample missed <<<----
20 Sep 2013 23:59:46   1 instance(s) of HG612_stats.exe running, sample missed <<<----
21 Sep 2013 00:59:52   Auto snapshots taken

I can put both missed samples down to the fact that at this time the daily ongoing stats 23:58 scheduled report is running on my old & slow server.  BE's hg612_modem_stats misses two harvesting samples at the same time for the same reason - it takes about 2 mins to run on my machine.

So, this all seems to be working well now.

[roseway]

That's good, thanks for letting me know, Colin.

[c6em]

Scratches head
See attached graph of the bitswaps/tone graph
Graph appears to actually be the bit loading one?
This is a Dlink 2640B - which does not report the bitswaps number in its output.

It didn't used to do this
Can't remember but I recall previously one of the bitswaps graphs was blank (Think it was bitswps/minute) because the number is not reported and the other one was populated as I assume it will come from the changing bitloading data the program collects.
I've no idea if this pecularity is only on the latest versions or was introduced earlier and I didn't happen to spot it.

The true bits per tone (bitloading) graph is perfectly OK.....

If I reset the data it simply comes back as is at the next sample point

[roseway]

Yes, sorry c6em, that's a bug which appeared when I recoded the bitloading section to deal with another issue.

It's fixed now, and I'll try to upload the fixed version shortly.

[kitz]

Sorry Ive not downloaded this yet as my desktop looks like a bombs hit it.  I notice there will be a bug fix released soon, so I will wait for that.

Thanks eric

[roseway]

Corrected version 3.97 now available.

http://dslstats.plainroad.me.uk