Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on April 23, 2013, 02:56:40 PM
-
Changes since v2.8:
- added support for Thomson/Technicolor modem/routers
- now takes account of Annex M tone bands
- if an update is detected when the program is running minimised, it now restores itself
- fixed issue whereby max attainable speed values were always zero with some routers
- improved the handling of misreported CRC and FEC errors (negative values trapped)
- improved the handling of router error conditions (router switched off, disconnected etc.)
- squeezed a little more data into the status bar
- changed the scaling of SNR per tone when included with bitloading so it equates with 3 dB/bit
-
Problem still persists, shows negative values in CRC and FEC errors. Also when going on Y axis still forces the program to crash... going to try something quickly.
Also when you put a number in to the averages it now defaults it to 1.
Nice to see an update though :)
-
Problem still persists, shows negative values in CRC and FEC errors. Also when going on Y axis still forces the program to crash
I'm sorry about that, it's supposed to be fixed. I'll check again.
Also when you put a number in to the averages it now defaults it to 1.
Sorry, but what do you mean by that? The averages shouldn't be editable.
-
All running well on annex m. Nothing else to report! :) .
I have not been following the "negative values" but I only get them if I have rebooted the modem with rsw running. In which case it seems best and reasonable to restart rsw if you don't like negatives.
I am still puzzled over my upstream errors but it is the modem output and not your program that is puzzling me.
-
Thanks Les.
-
I've still got problems - just the same.....only just started running v2.9 now.
see attached
This is on linear - swap FEC plot to log - instant program failure
Sorry to be the bearer of bad news.......
Edit: just to say I choose the default correction in the graphs setup tab ie Negative FEC/CRC --->zero
-
I can see where I went wrong - I only did half a job. :-[
I will sort this out as quickly as possible.
-
It is running well. I saw no errors, crashes or negative values since v2.8 even if it ran more than 30 hours continuously.
I have a little suggestion: It would be more consistent if the same options were available on the CRC and FEC Error tabs.
-
I have a little suggestion: It would be more consistent if the same options were available on the CRC and FEC Error tabs.
Yes, I suppose it would. The reason I didn't do so was that FECs tend to have a far wider range of values than CRCs, so the option of a logarithmic scale was useful for FECs but not for CRCs. Perhaps the simplest and most practical arrangement would be to make both of them logarithmic.
-
thanks for the update Eric and scaling the SNR graph to 3db/1bit :)
where are you pulling the uptime from? because ive noticed the Total Time always says 1 Day 'x' hours in the stats? - but then I found out that AS is the uptime in seconds, so divide by 60 for minutes and again for hours - I was using that in DMT Tool to get my uptime from, do the division, the divide my CRC by uptime for the per hour result...a bit of a faff
-
where are you pulling the uptime from?
I've lost a fair amount of hair over this question. Some routers report the uptime directly in a line starting "Since link time = ..." and if that line exists I get the uptime from there. For the remainder I convert the AS value as you suggest. But unfortunately the AS value doesn't equate with DSL uptime in all routers, so I just label it "AS uptime".
What router do you use, and what exactly does the program show for the two uptimes on the status bar?
-
its reporting the correct time for both System and AS - Iam using Netgear DG834N (DG Team 1018)
when I said the "total time" is always 1 day + x hours I meant the telnet stats...nothing to do with your program, my HG612 and 2504N were the same... but the HG612 displayed "since link time" at the bottom as you mention, the DG834N doesnt and I cant remember if the 2504N did or not, I only just recently learned of the AS value and its meaning because the 834N actually has (uptime) next to AS lol... and I thought "ahh.. that must be the link time in seconds"
I hope you dont mind but Ive got some more idea's, suggestions etc :D
1) the bottom part of the GUI that never changes whatever section your looking at, what if it had a 3rd line of data too possibly include, Vendor Chipset, Down Line attenuation, Up Line Attenuation & INP..? and also including the Interleave Depth value next to the Interleave stats, e.g. Interleave: ON (128) - it could be layed out like so:
System Uptime - Down Speed - Up Speed - Interleave OFF/ ON (Value)
AS Uptime - Down SNRM - Up SNRM - INP OFF/ON (Value)
Vendor ID - Down Atten - Up Atten - ES/Hour
These quite important diagnostics stats are immediatley available all together at all times, one could argue Vendor ID is not an important stat (which I suppose it isnt) but its one you dont see included in any other router tool as information readily available in the GUI, and I think its good to know when helping someone to try and determine which router (chipset) would be best for their line by also suggesting the possibility of matching it too their ISP's DSLAM/MSAN.
2) What about switches for i24k, CoMinMgn, PhyRE etc? - with all the warnings for noobs of course, maybe on the Tweak section as they could be executed along with the SNRM Tweak, and/or a shell with selectable commands for users to fire off themselves like DMT Tool has?
3) Showing the amount of traffic corrected (RSCorr) and uncorrected (RSUnCorr) in 'percentages' in relation to the total traffic (RS), I normally work this out myself (with difficulty) so I can see how much of an impact different Noise Margins I test are having on my line (aswell as using CRC's as a gauge)... e.g. with 7db Noise Margin I get about 0.05% corrected traffic - with 3db Noise Margin it can be 1-2% corrected traffic... I can better 'gauge' the effect of noise on my line...if I was to turn on one day knowing I was on my usual 7db Noise Margin and seen really high percentages of FEC then I would know something aint right.
4) What about a section that includes information about the router its monitoring? specs etc.. like chipset (xdsl, Lan, Wifi) and LAN, Wifi speeds etc?
5) I notice in the averages window there just enough white space to include a column "since link time" hehehehe ;) - no but really i just want to say a massive thanks for everything youve done on this... I really appreciate the effort :)
I dont think there is any reason to keep DMT Tool now?
-
Thanks for all those comments snadge. :)
They're all good suggestions, and I'll look seriously at them shortly. At the moment my main task is to properly nail down the remaining bugs (particularly the issue with negative CRC/FEC values) before I add any more significant features. But I'll come back to it very soon.
-
You probably don't want anymore suggestions for the moment, (snadge has got some good ones) but......
On the snapshot saved graphs there is nothing to say from what programand version they have come from.
When testing out V2.9 vs v2.8 yesterday I was being ultra careful which graph I saved came from which edition.
This might be a good idea to have something like for example "program name V2.9" added some corner of the graph particularly if they are going to start being used by ISP's/forum users etc as evidence of a dodgy line.
-
That's a good suggestion, thanks.
-
Yes, I suppose it would. The reason I didn't do so was that FECs tend to have a far wider range of values than CRCs, so the option of a logarithmic scale was useful for FECs but not for CRCs. Perhaps the simplest and most practical arrangement would be to make both of them logarithmic.
I think it's alright to have the choice between linear and logarithmic.
The reason I had this suggestion was a burst of thousands of crc errors and because there is no option to disable clipping it cuts off the graph.
-
Oh I see, thanks. I've been thinking about this option in respect of CRCs. The issue that's bothering me is that a log scale can't have zero on it. This isn't a problem with FECs because on an interleaved connection the FEC values are quite high. In log mode, when a sample with a zero value comes along I quietly convert it to 1. Because the values of CRCs are normally much lower this strategy won't work. Perhaps a minimum value of 0.1 for the CRC graph in log mode would be OK.
-
Thank you very much eric for adding the TG582n to the working routers. :thumbs:
I can confirm that an earlier test version has been running fine here on an Annex_M connection for the past 5-6 days.
My line is fairly static though with little errors and I dont seem to have run into any problems yet.
However, this afternoon Zoe jumped up on top of the PC and hit the off switch - causing a loss of all data which unless Im missing something I cant recover. Therefore it would be useful if there was some sort of a .dat file which could perhaps be used in the event of power offs/ power cuts etc.
-
Therefore it would be useful if there was some sort of a .dat file which could perhaps be used in the event of power offs/ power cuts etc.
I guess I could automatically back up all the graphical and other data periodically and provide a means of restoring it, but it would add quite a bit of complexity to the program and would need a lot of thinking about. I'll put it on the todo list but I don't promise to have it working very soon.
In the meantime there's already the option to take periodic automatic snapshots of any or all of the graphs, which will at least keep a graphical record of everything that's happened.
-
Thankyou