Print

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

[WWWombat]

We've been suffering power problems since Friday, with our main RCD tripping out - and haven't managed to fix things properly.

As you'd expect, this causes mayhem to all manner of things:
- The computer crashes, of course. If I've been brave enough to turn it on.
- Broadband drops - and DLM has been altering the G.INP configuration settings as a consequence.
- HG612 Modem Stats has stopped being able to harvest stats, and crashes every time it runs.
- DSLstats runs (after manual startup), but doesn't get to the point of saving any snapshots.

On top of this, while the Billion 8800NL re-connects just fine, it seems to get its knickers in a twist after a while, and stops responding. At this point, the LANn and WLAN lights flash extremely quickly, as does the internet light. The only option is to power-cycle the router/modem. Even more outages...

On previous re-syncs, the INP value had been creeping up, but I'd kept to an 80/20 sync. This has now changed, and I'm currently at 74/19, with attainables of 105/35 still, so presumably banded in some way.

Obviously a UPS needs to be considered, but I'd also like to figure why HMS has stopped working. If it were able to run, I'm sure it would have captured some great stats along the way!

I've attached the details from the crash report...

Any ideas?

[WWWombat]

Hmmm. I just moved "modem_stats.log" out of the way, and things started working again.

I'll have to try to combine things back together later...

[burakkucat]

If I was experiencing such intermittent but regular power outages, I would have disconnected the modem from the VDSL2 circuit and left it disconnected until such time as the electricity supply problem was resolved. 

[Bald_Eagle1]

Hmmm. I just moved "modem_stats.log" out of the way, and things started working again.

I'll have to try to combine things back together later...

I think you've found the answer.

There is probably one or more corrupt, blank or partially blank row(s) in modem_stats.log (probably the very last row).

The cause is likely to have been that the computer running HG612 Modem Stats went off just as either data was being harvested or during the period it writes data to modem_stats.log



In order to calculate delta values, HG612_stats.exe reads the last row from modem_stats.log to compare against the newly harvested data.

if some data is missing or the whole row is blank, this can't be done & thus the program crashes.

With a brand new modem_stats.log, it is known that a previous data row will not be present, therefore HG612_stats.exe doesn't attempt to read one & thus normal service is resumed.


I'll look into trapping this sort of issue & flag up a warning rather than have a program crash.

We do experience occasional power cuts where I live (maybe 3 or 4 per year), but I must have just been lucky so far for them to occur between data harvests as I haven't seen this issue here.



EDIT:

If it's not too late (i.e. if you haven't already deleted any duff rows from your original modem_stats.log), could you please email or post a snippet of the last few rows for me to (hopefully) work out what I need to do to deal with such issues?

[WWWombat]

If I was experiencing such intermittent but regular power outages, I would have disconnected the modem from the VDSL2 circuit and left it disconnected until such time as the electricity supply problem was resolved. 

Working from home makes for a tricky decision on this ... at least it did on Friday. The wife works on a laptop, so she survived any outages. But otherwise, I agree - attempts to isolate the power problem should (and, when possible, have been) done with the modem left turned off.

We were then away for Friday night, so the decision was easy - to just leave things off.

From return on Saturday afternoon, we've really only had the one power outage that was caused by the RCD - but the modem has then gone on to start acting weird all by itself.

The work problem will resume from tomorrow, so UPS solutions are in hand for then. I'll probably also fall back to a standalone HG612, so that resetting the router will not cause a resync. I'll make sure of a 30 minute break for that one.

[WWWombat]

There is probably one or more corrupt, blank or partially blank row(s) in modem_stats.log (probably the very last row).

That's the one. The last line seems to be made up of a lot of spaces (though may be null characters too).

If I remove the empty line, can I just merge the two files back together? I guess the delta counts will go askew in future graphs, but otherwise, things should be OK?

EDIT:

If it's not too late (i.e. if you haven't already deleted any duff rows from your original modem_stats.log), could you please email or post a snippet of the last few rows for me to (hopefully) work out what I need to do to deal with such issues?

I first tried copying the last few lines out using textedit, but it refused to cut text because of "null (code=0) characters". Then I had to cut all the other lines ... which took a while!

[boost]

I wonder if specifying maxrate for 80:20 via the command line might have some influence on your synch?

[Bald_Eagle1]

There is probably one or more corrupt, blank or partially blank row(s) in modem_stats.log (probably the very last row).

That's the one. The last line seems to be made up of a lot of spaces (though may be null characters too).

If I remove the empty line, can I just merge the two files back together? I guess the delta counts will go askew in future graphs, but otherwise, things should be OK?

EDIT:

If it's not too late (i.e. if you haven't already deleted any duff rows from your original modem_stats.log), could you please email or post a snippet of the last few rows for me to (hopefully) work out what I need to do to deal with such issues?

I first tried copying the last few lines out using textedit, but it refused to cut text because of "null (code=0) characters". Then I had to cut all the other lines ... which took a while!

I think I have resolved that now via HG612_stats.exe

The log will be rewritten without the NULLs & data harvesting/logging should continue as normal.

I just need to do a bit more testing & fine tuning before I release the updated program.

[WWWombat]

Excellent.

I'm now having some other problems, having dug myself into a whole heap of something smelly. Kitz' icon suits this

I went to combine the two modem_stats files together, to draw one set of graphs. The easiest way to day that (given my Linux knowledge ) was to use some of the *nix-based IO redirection within Cygwin . Unfortunately, that didn't like some of the access rights, so I adjusted those using traditional *nix commands. File updated really quickly, between harvests.

Unfortunately, then the HG612 harvesting stopped working, because it didn't like the new access rights on modem_stats. Using the *nix commands to put ACL back to the previous settings didn't work - so things stayed broken. At this point, it was just the harvesting that failed.

Not long after this, my PC blue-screened, and killed everything off (probably caused by something else). Upon restart, the HG612 GUI then told me that the "scheduled task" did not exist. When I try to create one, it didn't like the access rights for an XML file (presumably to create a task). More variations of ACL's to the files caused more variations of failures with the HG612 GUI.

Eventually I got the ACLs correct enough so that the HG612 harvesting worked, when started manually. At this point, I discovered that there is actually a regular task running once per minute - because the harvesting picked up immediately, even though the GUI still doesn't think a task exists.

I'll be back to it another day...

[Bald_Eagle1]

Did you manage to combine the 2 files minus the row containing the NULLs?

If that row is still somewhere in the combined log, it may cause a problem when generating graphs.


With hindsight, it may have been easier to have temporarily stopped the task via the GUI, using a Windows text editor, copy all the VALID data from the corrupted log and paste it into the new log immediately before the new log's data, ensuring no blank rows.

Regarding the GUI not acknowledging that the task is actually running, I would suggest that you could manually delete the task via Task Scheduler & then create a new task via the GUI (assuming permissions are indeed now back to normal).

[Ronski]

Make sure that the program is not installed to any of the system folders or you will get access problems. If the GUI is not detecting the task but it does exist then it means the name stored in the editor ini file doesn't match, simply close the GUI and then edit the editor ini file which is located in the editor directory and change the task name to match.

To merge two or more text files is very simple.

http://shanerutter.co.uk/2012/09/22/combine-multiple-files-into-one-using-windows-command-prompt/

Last time I did it I don't think I even used the /b switch.

[WWWombat]

Make sure that the program is not installed to any of the system folders or you will get access problems.

The files hadn't moved, and were still in C:\HG612_Modem_Stats\

If the GUI is not detecting the task but it does exist then it means the name stored in the editor ini file doesn't match, simply close the GUI and then edit the editor ini file which is located in the editor directory and change the task name to match.

I'll be doing this, and probably will move everything to a folder within my user folders. Something to restore ACLs properly.

But ... the GUI used to detect my task just fine, using the name "HG612-Mike" (which, according to the Task Scheduler, is still running). Now "Editor.ini" says the name is the default one. I certainly didn't edit anything

I note that Editor.ini has a timestamp for yesterday morning. I wonder if, in the course of me playing with ACL's, something has replaced the original file with a default one?

I note that HG612_stats.ini has a similar timestamp, but it isn't using default contents: it still has my MDWS configuration.

To merge two or more text files is very simple.

http://shanerutter.co.uk/2012/09/22/combine-multiple-files-into-one-using-windows-command-prompt/

Last time I did it I don't think I even used the /b switch.

Yup - pretty simple, and likely would have saved me a lot of hassle. The Linux equivalent is "cat newfile >> oldfile", which puts the new data onto the end of the old data.

[WWWombat]

Did you manage to combine the 2 files minus the row containing the NULLs?

If that row is still somewhere in the combined log, it may cause a problem when generating graphs.

I did indeed get rid of the duff data. Afterwards, generating the graph didn't turn out to be the problem, just getting logging to work again.

With hindsight, it may have been easier to have temporarily stopped the task via the GUI, using a Windows text editor, copy all the VALID data from the corrupted log and paste it into the new log immediately before the new log's data, ensuring no blank rows.

When I sent you the snippet, it took a long time to select/cut/paste the right stuff around with a text editor (textpad). When all I wanted to do was to merge two files, it seemed best to just use the OS-level commands. Hindsight, however, appears to be wearing better glasses than me 

Regarding the GUI not acknowledging that the task is actually running, I would suggest that you could manually delete the task via Task Scheduler & then create a new task via the GUI (assuming permissions are indeed now back to normal).

I'm not convinced that the ACLs are straight, so I'll be moving things around somewhat. Fingers crossed that when I delete the task, I can get a new one started!

[WWWombat]

I haven't had time to sort out the ACL's yet, but I have now generated the graphs that show the behaviour of DLM. Not so much in ramping up because of the problem (those were the stats that couldn't be harvested), but a little in the ramping down - at least while I dared to have the PC powered up.

[Bald_Eagle1]

I have seen similar stats from other connections that have been experiencing problems. i.e. Interleaving depths & sync speeds decreasing rather than in the pre-G.INP when they would have increased.

RxQueue/TxQueue & DS/US lookback also increased at the same time.

Did you initiate last night's resync yourself at around 23:22?



As an example of a usually very stable & pretty much error-free connection, I'd very much like to take a detailed look at your stats for say, the last 24 days or more as I have only really seen detailed stats from either higher speed, but problematic connections and my own stable, but long distance connection.

Your stats will hopefully clearly demonstrate how a connection should perform as best case scenario & also clearly demonstrate what changes when problems are experienced.

With that information, we may get much closer to understanding what to look for in terms of diagnosing faults/issues etc.

Could you please either post the zipped modem_stats.log or email it to me?



In the meantime, you may wish to try the attached graphpd.exe that combines all the most 'relevant' stats from Bearer 0, Bearer 1 & 'unspecified' Bearer into a 6 column wide montage (hopefully) to assist with our analysis of G.INP active connections.