Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on February 26, 2017, 03:06:07 PM
-
This new release is functionally the same as the pre-release version 5.8.7, but this version directs all its internal website enquiries to the new site http://dslstats.me.uk. I'm not sure if the automatic notification of the upgrade will work properly during this changeover period, so it may be best to ignore it and go straight to the new downloads page.
Changes since the previous full release v5.8:
v5.9
- directs website references to new site http://dslstats.me.uk
- incorporates all changes in pre-release versions since v5.8
v5.8.7
- fixed incorrect naming of connection stats file in webserver
v5.8.6
- added event log entries to report dropped and restored connections
- corrected misreporting of G.INP state with Technicolor modems
v5.8.5
- adjusted the timing for uploading to MDWS to avoid the first 5 seconds of the
minute
- fixed error "24:0:0:0 is not a valid time specification" with some
snapshot timings
v5.8.4
- increased the telnet timeout, to try to deal with occasional modem slowness
to respond
- added an option to enter a custom command prefix in the login configuration
- the timing of snapshots can now be optionally set to a specific time sequence
- saving the stats summary text now saves the correct data
- removed unneeded event log entry for saving attenuation log text
v5.8.2
- corrected bug in displaying average errors over 10 days
- resetting today's values of average errors now works correctly
- graph snapshots can now be optionally scaled to a specified size
v5.8.1
- fixed duplication of autosaved average errors text
- changed filenames of average errors text to correspond with other snapshot
types
- when switching between locations of configuration files in Windows, the file
"traffic.txt" is now copied as well as "traffic.ini"
- traffic monitoring now works correctly with the Technicolor TG789vn (and
probably other Technicolor modems)
As I mentioned elsewhere, I'm intending to decommission the old website in the fairly near future, and for smooth running when that happens you do need to upgrade to this version.
http://dslstats.me.uk/downloads.html
-
Many thanks - now running 5.9 :)
ps. You may want to check the dates in the news section/homepage of your old website and perhaps mention 5.9 there as well (and you may need to look at the contact form on http://dslstats.me.uk/licence.html) :)
Thanks as always for all the work you put in to maintaining this software..
-
Thank you. I wasn't sure what you mean with the second point, but I see now that the licence page has a broken link to the contact page. I'll fix it immediately.
[Later] Now fixed.
-
Hi roseway
Many thanks for your continued work on dslstats.
I have updated without issue, and appears to be working lovely
The only issue was avast detected dslstats.exe as new, I submitted for further testing and it has now been accepted as clean, and added to avast update as clean. It took less then a minute to complete. Hopefully, no other user of avast should have this issue once sigs have been updated on their avast - circa about an hour or so for user program digs to update
Once again, many thanks
John
-
Thanks John.
-
There's a very minor cosmetic sizing issue - see attached.
-
Thanks. I assume that this is on Windows? I'll make an adjustment in the next release.
-
@ roseway
I'd like to add my thanks for your work on dslstats, the new 5.9 version is working well here on my raspberry pi.
There's is however one small issue I've been intending to bring to your attention for some time, I suspect this changed sometime after v 5.7.6.
At one time the bit loading graph showed the SNR line graph for both up and down tones. The last few versions of dslstats has only shown the SNR for downstream.
-
Does the separate SNR per tone graph show the upstream values? If not, then I suspect that your modem isn't reporting them.
-
Thanks. I assume that this is on Windows? I'll make an adjustment in the next release.
Sorry yes - Windows 10.
-
@jelv: I've had a look at this, and I can confirm the effect on Windows (any version apparently). It derives from the fact that the Windows implementation of the group box (the rectangle enclosing some controls) has to be about 20 pixels higher than the equivalent item in other OSs. The next release of DSLstats will have this correction.
-
Does the separate SNR per tone graph show the upstream values? If not, then I suspect that your modem isn't reporting them.
Looks like it's a router issue rather than a dslstats issue.
Anyone else seeing this with a VMG8924-B10A?
-
I suspect that it depends on the firmware version. I don't see the issue with my VMG8324-B10A which uses the rather old 6b1 firmware.
-
It's also OK on a VMG1312-B10.
-
my 8324 seems fine as a bridge modem on v14 firmware uploading with Pi3
thanks Roseway for your continued support.
-
Thanks again roseway, great piece of software. :drink:
-
Running v16 firmware on a VMG8924 and can only see bit loading on the bit loading graph and SNR on the SNR graph.
In fact until I had seen npr's screenshot, I wasn't aware that the SNR values were intended to be graphed on the bit loading graph (if indeed that is the intention)
-
Its a configuration option on the Items To Monitor page
-
My VMG8924-B10A shows SNR per tone on both down/up. I'm running V15 firmware on DslStats 5.9
-
Gone back to firmware 13C0 from 16C0 and still not getting the upstream SNR graph.
I'll try a different modem router later, but I'm beginning to suspect the problems I have with my upstream sync speed may be at the root of this issue. That and the obscure firmware (0xd086) my local ECI cabinets is running. :(
-
Its a configuration option on the Items To Monitor page
In which case it works for me on VMG8924 v16 firmware.
However on the Items to Monitor page I do need to resize the screen to see all the check boxes (running on an iMac under Wine).
-
Gone back to firmware 13C0 from 16C0 and still not getting the upstream SNR graph.
It mainly depends on whether the DSLAM is configured to send the upstream values to your router.
And thanks roseway for your work on DSLstats. v5.9 is running fine on the raspberry.
-
Anyone else using DSLStats with WD9970?
Seems that it will stop logging in for 10 minutes at a time then carry on as normal. This happened the other day and I rebooted the router, but tonight I left it and it resumed after 10 mins. The error was:-
26 Mar 2017 16:57:12 Unable to login to modem/router
26 Mar 2017 16:58:12 Unable to login to modem/router
26 Mar 2017 16:59:12 Unable to collect stats 3 or more times in succession
.
.
.
26 Mar 2017 17:10:12 Unable to login to modem/router
Anyone else.
Also I have enabled MyDSLWebstats upload and cant seem to change the sample rate from 60 seconds to 90 is this because of MDSLW?
-
MDWS expects the samples at 1 minute intervals, so DSLstats doesn't let you choose a different value when MDWS uploads are enabled.
-
Eric I have just switched to dslstats as I have been unable to resolve memory leak issues I got using BE's tool and since he isnt active anymore for support queries I have migrated over to see how things go.
I imported my username and password from hg612 stats, stopped the task for it as well, set dslstats to 60 sec intervals and started the recording.
Do I need to manually add dslstats to the windows startup folder?
Some feedback.
I like how you added alert features for excessive ES/hour etc.
Auto saving of data on exit is nice.
Live graphing is also nice.
Some suggestions.
Email ssl/tls uses the CBC3 cipher which by today's standards is old, can it be possible to use AES (ideally GCM).
When I first clicked test for the email nothing happened, then I thought I would tick the send email alerts box and then the test worked, but it wasnt immediately obvious that the send email alert option should be enabled to do a test, so maybe grey out the test button if the send alert option is disabled.
For the graphs they default to adsl1 frequency range, I know they can be adjusted which I have done, I dont know yet if the adjustment is remembered between restarts, but is it possible to add preset adjustments so e.g. adsl1/adsl2+ and VDSL2 17A
Thanks
-
Thanks for your comments.
DSLstats has no specific requirements for starting up. Most users (I think) start it manually, but if you want you can start it automatically and add the parameter "startrecording" to the command line. See the section "Using command line parameters" in http://dslstats.me.uk/installation.html . The executable needs to remain in the same directory as the other files it comes with, so you would need to put a link to it in the startup folder, not the executable itself.
Concerning email alerts, I have to admit that I struggled to get this working at all, as it's well outside my area of competence. I'll give some thought to your suggestions.
The compression/expansion of the graphs is remembered between runs, but a couple of presets sounds like a good idea. I'll try to add that in the next release.
-
Also forgot to mention I love the bitswaps per tone feature as well :) I see almost all my bitswaps are in D3 only, not spread out across alll tones. :)
Yes I did link to the binary, I didnt copy it to the startup folder :)
I ticked "autostart recording on program start" in misc settings, does this mean I dont need to add the parameter to the command?
-
I ticked "autostart recording on program start" in misc settings, does this mean I dont need to add the parameter to the command?
Yes, the two things are equivalent.
-
@ Chry Dslstats is also good as a early warning T/Storm live event viewer when the cell is 1 to 150 miles away you know the type the CRCs start to climb and fade as the storm gets close and then either dies or gets further away
-
I can confirm all is good on a reboot :)
-
quick question - this isn't specific to this version
how is the upstream RSCorr/RS (%): calculated as it bears no resemblance to the telnet figures
-
It's calculated from the delta values, that's to say the difference between the total values reported in the present sample and those in the previous sample.
-
is that the same sample frequency as the graph
this is the present example - nearly 25% seems rather silly - this is from a Billion 8800NL on FTTC
RSCorr/RS (%): 0.5530 24.6207
RSUnCorr/RS (%): 0.0000 0.0000 whereas the telnet values are RS: 1288091020 3233846
RSCorr: 574 4528
RSUnCorr: 0 0and the next set - only a few minutes after and even sillier
RSCorr/RS (%): 0.5523 235.0087
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0and another set RSCorr/RS (%): 0.5508 18539.0391
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0I just realised something - there are two sets of corrected errors - bearer 1 and bearer 2 is this relevant Counters
Bearer 0
OHF: 0 0
OHFErr: 350 31
RS: 4132625256 1007609
RSCorr: 22561717 772422
RSUnCorr: 0 0
Bearer 1
OHF: 214848124 765619
OHFErr: 0 19
RS: 1289088374 3901340
RSCorr: 574 4528
RSUnCorr: 0 0
-
Think I've found an oddity either with DSLstats or the Modem 8800NL once you go into modems GUI and select Stats/Statistics/xDSL and then reset the values in there the RPI running DSLstats uptime then resets and then MDWS thinks a retrain has occurred.
I'll try this again tomorrow and see if does the same thing.
-
I just realised something - there are two sets of corrected errors - bearer 1 and bearer 2 is this relevant
I think you mean Bearer 0 and Bearer 1. The figures on the Stats page refer to Bearer 0, which is the data channel. Bearer 1 is for G.Inp only, and has no relevance in this context.
-
5.9 keeps crashing for me at least once a day...
-
I'll need to know a lot more than that to make any useful response:
- What operating system?
- Exactly what do you mean by "crashing"?
- If an error message appears, what happens if you select the option to keep running and risk losing data?
- Is there any pattern, or do the crashes appear completely random?
-
I'll need to know a lot more than that to make any useful response:
- What operating system?
- Exactly what do you mean by "crashing"?
- If an error message appears, what happens if you select the option to keep running and risk losing data?
- Is there any pattern, or do the crashes appear completely random?
-Windows Server 2012 R2 Datacenter x64
-Crashing as in it stops responding and gives this error:
Faulting application name: dslstats.exe, version: 5.9.0.0, time stamp: 0x00000000
Faulting module name: dslstats.exe, version: 5.9.0.0, time stamp: 0x00000000
Exception code: 0xc0000090
Fault offset: 0x0024a8b3
Faulting process id: 0x88c
Faulting application start time: 0x01d2b308f8ab1908
Faulting application path: C:\dslstats32W-5.9\dslstats.exe
Faulting module path: C:\dslstats32W-5.9\dslstats.exe
Report Id: ef269098-1f6f-11e7-80db-000c2973fc7d
Faulting package full name:
Faulting package-relative application ID:
-There is no option to keep the program running after it stops responding with an error; it automatically closes
-Random times but occurs at least once a day it seems.
12/04/2017 12:05
11/04/2017 16:16
10/04/2017 20:11
5.8 worked well for me.
-
A few things come to mind:
You have DSLstats installed in a folder at the top level of the C: drive, and from time to time users have reported problems with this, which go away when it's installed in one of the user's own folders (under Program Files for example). If you had v5.8 installed in the same way, then this is probably a red herring, but if not then it might be worth moving it.
The fact that v5.8 worked well suggests that the problem relates to changes made since then. I'll investigate this, but nothing leaps out, and several people are using v5.9 on Windows without issues.
Someone who contacted me via my website with a somewhat similar issue found that reinstalling DSLstats and deleting its configuration files before restarting fixed the problem. The configuration files are by default saved in the AppData folder, which is the same as where snapshots are saved (unless you've changed this).
-
A few things come to mind:
You have DSLstats installed in a folder at the top level of the C: drive, and from time to time users have reported problems with this, which go away when it's installed in one of the user's own folders (under Program Files for example). If you had v5.8 installed in the same way, then this is probably a red herring, but if not then it might be worth moving it.
The fact that v5.8 worked well suggests that the problem relates to changes made since then. I'll investigate this, but nothing leaps out, and several people are using v5.9 on Windows without issues.
Someone who contacted me via my website with a somewhat similar issue found that reinstalling DSLstats and deleting its configuration files before restarting fixed the problem. The configuration files are by default saved in the AppData folder, which is the same as where snapshots are saved (unless you've changed this).
Thanks for replying. I now deleted the dslstats folder under appdata and extracted a fresh 5.9 ZIP into my D: drive instead.
Will report back if any crashes occur still.
-
It's been more than 24 hours and no crashes so far. :fingers:
-
Some suggestions.
Email ssl/tls uses the CBC3 cipher which by today's standards is old, can it be possible to use AES (ideally GCM).
When I first clicked test for the email nothing happened, then I thought I would tick the send email alerts box and then the test worked, but it wasnt immediately obvious that the send email alert option should be enabled to do a test, so maybe grey out the test button if the send alert option is disabled.
For the graphs they default to adsl1 frequency range, I know they can be adjusted which I have done, I dont know yet if the adjustment is remembered between restarts, but is it possible to add preset adjustments so e.g. adsl1/adsl2+ and VDSL2 17A
I've taken account of these comments in the version I'll be uploading later today. For the present I haven't changed the SSL/TLS cipher because I don't know how to. I use a simple mailing library which doesn't offer this option, so I've got some more learning to do. But I've corrected the non functioning of the 'Test' button when email alerts aren't enabled.
The compress/expand function for the tone referenced graphs is now handled by a popup which includes presets for the three main DSL types, and it controls all of the graphs with one adjustment. Some of the graphs have been slightly redimensioned so they all have the same x axis dimensions.
-
I've taken account of these comments in the version I'll be uploading later today. For the present I haven't changed the SSL/TLS cipher because I don't know how to. I use a simple mailing library which doesn't offer this option, so I've got some more learning to do. But I've corrected the non functioning of the 'Test' button when email alerts aren't enabled.
The compress/expand function for the tone referenced graphs is now handled by a popup which includes presets for the three main DSL types, and it controls all of the graphs with one adjustment. Some of the graphs have been slightly redimensioned so they all have the same x axis dimensions.
thanks eric :)
-
I've been using v5.9 on a Raspberry Pi 3 for a couple weeks with a CenturyLink Actiontec C1900A. I've been using the C2000A model setting, and the program has been working great. I love being able to see all the details on the FEC and CRC errors vs time. The only wrinkle is my service is a bonded connection, and the only way I could figure out how to see both lines was to run two instances of the program.
CenturyLink just gave me a new modem, the Technicolor C2100T. This is also a Broadcom-based modem, with the same xdslctl0/xdslctl1 command set as the C1900A. I can't seem to get DSLstats to work with the Technicolor modem though. I chose the Technicolor C2000T model. I keep getting the message, "No data returned in latest sample."
Is there any way to get DSLstats to work with this modem, or is the Technicolor not compatible? I'm using MDMstats for now, but I miss the details that DSLstats provides.
-
Manually login via telnet and check the commands work with that format. Perhaps post the results of the telnet window and Eric may be able to help further.
-
Thanks. I logged into the modem and ran "xdslctl0 info --stats" The output is pasted below.
I then ran "xdslctl0 info --SNR" and the telnet session and modem GUI both locked up. I noticed the modem also locked up when I tried using the C1900A settings in DSLstats. I suppose this behavior is related to the problem.
I have both modems still and I'm happy to collect more data if that helps.
> xdslctl0 info --stats
xdslctl0: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7527 Kbps, Downstream rate = 50613 Kbps
Bearer: 0, Upstream rate = 5598 Kbps, Downstream rate = 47298 Kbps
Link Power State: L0
Mode: VDSL2 Annex A
VDSL2 Profile: Profile 8a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.9 7.5
Attn(dB): 25.8 0.0
Pwr(dBm): 17.5 8.6
VDSL2 framing
Bearer 0
MSGc: 17 104
B: 237 31
M: 1 1
T: 64 64
R: 16 10
S: 0.1602 0.1803
L: 12688 1864
D: 199 47
I: 254 42
N: 254 42
Counters
Bearer 0
OHF: 19559711 1163180
OHFErr: 8 5
RS: 1251821508 23093
RSCorr: 3275 54090
RSUnCorr: 29 0
Bearer 0
HEC: 7 0
OCD: 0 0
LCD: 0 0
Total Cells: 281704167 0
Data Cells: 4529403 0
Drop Cells: 0
Bit Errors: 0 0
ES: 3 5
SES: 0 0
UAS: 0 0
AS: 50327
Bearer 0
INP: 1.00 1.00
INPRein: 0.00 0.00
delay: 8 2
PER: 2.57 14.47
OR: 71.52 60.78
AgR: 47369.98 5658.65
Bitswap: 86/86 22/22
Total time = 13 hours 58 min 47 sec
FEC: 3275 54090
CRC: 8 5
ES: 3 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 13 min 47 sec
FEC: 357 836
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 87
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 13 hours 58 min 47 sec
FEC: 3275 54090
CRC: 8 5
ES: 3 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 13 hours 58 min 45 sec
FEC: 3275 54090
CRC: 8 5
ES: 3 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
The --stats output looks quite normal, but the fact that the modem locks up with the --SNR command is a bit of a puzzle. Normally, if a CLI option is missing you would expect to get a "command not available" type of response, so it looks as though there's a bug in the firmware.
I suggest that you try "xdslctl0 info" without any final parameter. This should give you a summary of all the available options. Maybe there's some way round this problem, but if not you could possibly run DSLstats with only the available working options ticked under "Items to monitor".
-
Thanks. Below is the output of "xdsctl0 info" and just "xdslctl0"
Looks like --SNR is supposed to be supported.
I hadn't thought of running with only a few options ticked. Good idea. I will try that.
> xdslctl0 info
xdslctl0: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7466 Kbps, Downstream rate = 50676 Kbps
Bearer: 0, Upstream rate = 5598 Kbps, Downstream rate = 48611 Kbps
> xdslctl0
Usage: xdslctl0 start [--up] <configure command options>
xdslctl0 stop
xdslctl0 connection [--up] [--down] [--loopback] [--reverb]
[--medley] [--noretrain] [--L3] [--diagmode] [--L0]
[--tones <r1-r2,r3-r4,...>] [--normal] [--freezeReverb] [--freezeMedley]
xdslctl0 configure/configure1 [--mod <a|d|l|t|2|p|e|m|M3|M5|v>] [--lpair <(i)nner|(o)uter>]
[--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
[--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
[--Ginp <0xBitMap-UsDs>] [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
[--profile <0x00 - 0xFF>|<"8a |8b |8c |8d |12a |12b |17a |30a">] [--us0 <on|off>]
[--dynamicD <on|off>] [--dynamicF <on|off>] [--SOS <on|off>] [--maxDataRate <maxDsDataRateKbps maxUsDataRateKbps maxAggrDataRateKbps>]
[--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
xdslctl0 bert [--start <#seconds>] [--stop] [--show]
xdslctl0 afelb [--time <sec>] [--tones] [--signal <1/2/8>]
xdslctl0 qlnmntr [--time <sec>] [--freq <msec>]
xdslctl0 inm [--start <INMIATO> <INMIATS><INMCC><INM_INPEQ_MODE><INM_INPEQ_FORMAT>] [--show]
xdslctl0 snrclamp [--shape <shapeId>] [--bpshape [bpIndex-bpLevel,]]
xdslctl0 nlnm [--show ] [--setThld <Thld_Num_Tones>]
xdslctl0 diag [--logstart <nBytes>] [--logpause] [--logstop] [--loguntilbufferfull <nBytes>] [--loguntilretrain <nBytes>] [--dumpBuf <sizeKb>]
[--mediaSearchCfg <0xBitMap >]
Bits
[0] PHY Switch: 1=Disabled, 0=Enabled
[1] Media Search: 1=Disabled, 0=Enabled
[2] Force new PHY/line configuration as defined in bits 3, 4 and 5
[3] PHY Type: 1=Single Line, 0=Bonded
[4-5] AFE: 1=external, 0=internal
[6] Save Preferred Media: 1=Disabled, 0=Enabled
xdslctl0 info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
[--24hrhiststat]
[--retrains]
[--pbParams] [--linediag] [--linediag1] [--reset] [--vendor] [--cfg]
xdslctl0 profile [--show] [--save] [--restore]
xdslctl0 --version
xdslctl0 --help
>
-
It looks as though all the normal options are there, including --SNR, so that really does look like a firmware bug.
-
I would manually try each of the commands DslStats uses and see which ones cause the modem to hang. Then simply uncheck those items in DslStats.
I agree it sounds like a firmware bug, are you running the latest version available. Unfortunately it's not a device I think many on the forums have used.
-
I would manually try each of the commands DslStats uses and see which ones cause the modem to hang. Then simply uncheck those items in DslStats.
I agree it sounds like a firmware bug, are you running the latest version available. Unfortunately it's not a device I think many on the forums have used.
That's what I will try. It will probably require a lot of reboots though. :)
I am using the latest firmware.
I guess not many are using the C2100T because it's one of CenturyLink's newest modems, and they mostly deploy them with the Prism TV service or Gigabit connections.
I've got a 100 Mbps bonded VDSL service. The Technicolor has been synching at 5-10 Mbps faster than the Actiontec, and it has dual-band wifi and a 4x4 5 GHz radio, so it seems like a decent box.
-
I got it working with the C2100T modem by un-ticking several things under "Items to Monitor." I am still using the C2000A model setting.
Thanks for the help.
Screenshot attached.
-
Hi
Just wondered if there are any issues with 5.9.3 with regards to sending alerts when being used on pi3. I have 2 x pi3's - one works fine from dsl stats and will send alerts. I set up the second one with the same details and installed ssmtp and can send messages from a command line using the same account and it works fine. The log in dslstats shows "Failed to sent email alert - SSL error: TSendMail" - I have doubled checked the settings and the pi3 does send outbound messages using ssmtp with the same authentication details but it wont from the stats program.
Any help appreciated
thanks
-
You may need to install libssl-dev on the troublesme Pi.
sudo apt-get install libssl-dev
-
Many thanks Vic - now works a treat ! ;)
-
can you check how error secs are calculated on the 8800nl
from this image it never gets above 29 error secs but the stats show
ES/hour: 3.29 36.9
-
The ES values are calculated in the same way for all modems. The values shown in the Stats should match the values shown on the error averages page, and should be a reasonable looking average of the values in the ES/hour graph. If you check the values for previous days (you can go back up to 10 days on both the graph and the averages) do the values match up on the earlier days?
-
they don't
latest figure is 221 error seconds per hour
could it be the effect of putting the computer into sleep mode over night
where do I see the average for previous dates
-
Look at Errors --> Averages. Under the table there's a box labelled "Show values for:"
It's possible that having the PC go to sleep is what causes the inaccuracy. It's something I've never successfully dealt with.
-
and it is more or less the same but seems to be unrelated to other errors