Print

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

[Bald_Eagle1]

I suppose that's entirely possible Walter.  I'll pass on the observation to BE if he doesn't get round to reading it here.  Working around it is the key.  Coexistence between HG612_modem_stats and DSLstats seems to be there now, so that has been >90% of the problem for both him & Roseway.  People just may need to be aware if they are manually telnet-ing into the modem.

Right. I'm back now, from an enjoyable week in sometimes sunny Spain.

There's a lot to read through here, which I'll try to do a.s.a.p.

In the meantime, here are a few comments:-

The release of HG612 Modem Stats 1.1 included compatibility for HG622 modems.
That seems to have caused a few issues on some systems, so the debugging versions that ColinS has referred to have temporarily disabled HG622 compatibility.

There was an also issue with clashes with DSLStats - both programs competing to access the modem at the same time.
That now seems to have been resolved by Roseway detecting any instances of HG612_stats.exe & HG612_current_stats.exe still running & pausing DSLStats accordingly.

My debugging versions now detect how many simultaneous modem login events are being attempted & either timeout or exit if too many instances are found.

A recent issue (possibly coincidental) of occasionally more than one instance of Windows Task Scheduler starting HG612_stats.exe each minute has been dealt with by checking for more than one instance & exiting one or other of the duplicated instances.
Very occasionally, when 2 instances start very close to each other, both instances exit, meaning the data from that minute's sample is lost.

I use AVG antivirus program & despite setting it to run at lowest priority, that does slow the PC down significantly when a full daily virus scan is running.
This can very occasionally cause data harvesting to take more than 1 minute, so the check for multiple instances of HG612_stats kicks in & causes one instance to exit.

The effect of that can be seen in the attached graphs, although the gaps in data harvesting are nowhere near the extent as seen in NewtronStar's graphs.

Thre does seem to be a bit of an issue with Windows 8, where Task Scheduler seems to simply stop running for no obvious reason after a few hours or days.
v 1.1 of HG612 Modem Stats attempted to deal with that, but I don't have a Windows 8 system to test it on.



I'll take a close look at the various eror logs etc. that have been posted, to see if anything stands out as a possible cause, but it might be a while before I respond as there's so much other work related stuff to also catch up on over the next few days.

[ColinS]

So will it work if I connect PC directly to Lan port 2 on the HG612 ?

Yes, I think it should, as long as you don't mind not being connected to the internet from that PC while you test it? But given how often the problem was happening to you, it shouldn't take you very long to see if it is still missing samples.

Just check the DHCP server is on in the modem - Basic/Lan/DHCP serve/DHCP server Enable ticked?

[NewtronStar]

Right. I'm back now, from an enjoyable week in sometimes sunny Spain.

I hope you let your feathers down during the break  you don't have any ah well as long as you relaxed thats the main thing 

[NewtronStar]

I have done some H/W stuff by unplugging all devices and Reset the HH3 to factory defaults and then plugged each device in one by one, what I have noticed is the HG612 is not showing up as as a physical connection on the HH3 under Home network devices as it used to 6 months ago, But HG612 is visible and working fine using 192.168.1.1

[ColinS]

I'm afraid I have no experience of the HH3 to be able to comment sensibly on it.  However, it does not show up as a LAN device on the TG582n FTTC Home Network.***  Nor IMO, would I expect it to normally, because the FTTC modem is operating in Bridge Mode, and so any LAN packets sent in its direction would simply be bridged onto the BTOR GEA VDSL link AFAIK.  So I can't explain why you did see it 6 months ago either. I think that's why the second port on the HG612 had to be opened up, so that the HG612 itself could be accessed (via that second port).

***[Edited to clarify] It doesn't appear as the bridged modem (i.e. LAN4 port on the TG582n to LAN port 1 on the HG612), but it does appear as a device when hacked (i.e. LAN3 port on the TG582n to LAN port 2 on the HG612), simply because in that case ARP needs to translate the 192.168.1.1 IP address to an Ethernet MAC address.

[Bald_Eagle1]

I have done some H/W stuff by unplugging all devices and Reset the HH3 to factory defaults and then plugged each device in one by one, what I have noticed is the HG612 is not showing up as as a physical connection on the HH3 under Home network devices as it used to 6 months ago, But HG612 is visible and working fine using 192.168.1.1

As ColinS has mentioned, the HG612 also shows as a device physically attached to my Netgear WNR1000v3 router but it is not shown on my home network (the Netgear router itself is shown on my home network though).

If you are willing to test things out with me, I'll be happy to keep chipping away at this issue until we find a workaround.

I am not aware of any other users experiencing this particular issue, so for the moment, I'll assume it is not directly caused by the v 1.1 software, rather it could be something at your end.

It could simply be that the modem needs a full power off & on to clear things out, the modem COULD have an intermittent fault (not noticed in normal internet use), there is 'something else' running at your end that interferes with v 1.1's data harvesting or even possibly a PC issue.


Looking at your various logs, it seems that the "xdslcmd info --stats" command is accepted by the modem & that the get_data() function occasionally fails.

The get_data() function contains a loop where the data is obtained in chunks, until the '#' symbol is received.
The '#' symbol should only ever be received when all the data has been obtained.

If data is unobtainable at any of the runs through the loop, a 'failure' message is received & the software then moves on to the exit function.

The exit function contains the resync detection code that firstly causes the modem's clock to be reset, then moves on to obtaining the new stats after the resync has completed.

I have now amended that code to avoid spurious resync detection & generation of a Plink log & optional graphing when sync speeds were shown as zero (as would be the case when the get_data() function had failed).

I have also included a bit more debugging code in the get_data() function to hopefully identify exactly at which stage the failure to obtain data occcurred.

This is reported in the "ERROR.LOG_file_ERROR.TXT" file.
It should look something like this when data has been successfully obtained:-

19/09/2013  6:21:17.91 - In get_data(), *** recv() SUCCEEDED *** numbytes = 1023
19/09/2013  6:21:17.93 - In get_data(), this was included in data received:-  xdslcmd info --stats
19/09/2013  6:21:18.11 - In get_data(), *** recv() SUCCEEDED *** numbytes = 850
19/09/2013  6:21:18.13 - In get_data(), this was included in data received:-  xdslcmd info --stats
19/09/2013  6:21:18.16 - ONGOING-ISRUNNING-062116-058.TXT - After xdslcmd info --pbParams(), ERROR.LOG status = 1
19/09/2013  6:21:18.18 - In get_data(), *** recv() SUCCEEDED *** numbytes = 25
19/09/2013  6:21:18.19 - In get_data(), this was included in data received:-  xdslcmd info --pbParams
19/09/2013  6:21:18.39 - In get_data(), *** recv() SUCCEEDED *** numbytes = 991
19/09/2013  6:21:18.41 - In get_data(), this was included in data received:-  xdslcmd info --pbParams

ColinS & I have tested this, but have both been unable to cause the get_data() function to fail, leading us to think the issue has to be something at your end.

I use Windows 7 for logging & ColinS uses a server version of Windows.
I don't think it's a Vista specific issue, but I can't actually rule that out, yet.

A different message should appear in the "ERROR.LOG_file_ERROR.TXT" file on failure.
Also, if for some reason the 'wrong' data is obtained, whatever that data happened to be should be recorded in the "ERROR.LOG_file_ERROR.TXT" file.


I have attached another debugging version to this message that covers the aspects mentioned above.
I would be most grateful if you could try it out & provide feedback/copies of various logs etc.


I have to ask though, is it all possible that you have 'other' software and/or scripts/tasks running that might occasionally clash with v 1.1's data harvesting just at the wrong time?
Windows 7 has the option to display 'hidden' tasks. Maybe Vista also has that option?

Whenever the same xdslcmd info --stats is sent a few seconds later, it always appears to have allowed the get_data() function to obtain the data as expected, again leading me to think someting else at your end is causing the issue, but only within the first few seconds of the every minute task starting.

It does seem quite odd that the old & much slower script version works O.K. for you though.
It might just be that on your system(s) a pause here & there is needed to avoid the software attempting to obtain data before the modem is ready to provide it.

If necessary, I could build in some pauses (rather defeating the object of compiled code to speed up the harvesting process) or maybe cause the get_data() function to retry a few times before exiting on failure.

[NewtronStar]

Now I have gone back to older version as nothing I do on PC side and H/W Router makes any difference with 4.1 missing samples have been spending many hours in the last week to see if I can find the cause but still missing 4 samples in 10 mins even been into the registy to see if one of the old ModemStats schedules is running hidden in the background.


Here is old version modem_stats started it fresh yesterday

Here is 4.1 version Modem_stats finished yesterday

You only need to see 10 minutes worth to see the difference between the two, you can clearly see V4.1 is missing samples ! I have wacked my head of a few walls (only joking) but if it's just me on Vista having this then it's not worth your time fixing a one off, but I do get the same problem on same PC H/W on windows 8.1 thats what is freaking me out as it looks like H/W issue in 4.1 but not in 2.0 

[NewtronStar]

and 4.1 Modem_stats

[Bald_Eagle1]

I do get the same problem on same PC H/W on windows 8.1 thats what is freaking me out as it looks like H/W issue in 4.1 but not in 2.0 

How are you running Windows 8.1 & Vista on the same PC?
Via a dual boot or some sort of emulator?

[ColinS]

You only need to see 10 minutes worth to see the difference between the two, you can clearly see V4.1 is missing samples !

Hi NS.

Nobody doubts for a moment that you are losing samples when running v1.1/4.1. And both BE and I can clearly see that the get_data() call from the modem is failing for you.

Both of us want to try to help identify the cause and to fix it for you and anybody else in a similar situation.  Unfortunately atm neither of us can reproduce your circumstances.  Which is why BE has provided an updated diagnostic hg612_stats.exe for you to run.  If you could possibly bear with us and try that out, then perhaps the additional evidence it might provide may help us all resolve this infuriating issue for you.

I shall try myself tomorrow to run it on Vista and report, good or bad, the results.

Please, try to continue to be as patient as you already have been, and hopefully a resolution will be forthcoming.

[NewtronStar]

You only need to see 10 minutes worth to see the difference between the two, you can clearly see V4.1 is missing samples !

Hi NS.

Nobody doubts for a moment that you are losing samples when running v1.1/4.1. And both BE and I can clearly see that the get_data() call from the modem is failing for you.

Both of us want to try to help identify the cause and to fix it for you and anybody else in a similar situation.  Unfortunately atm neither of us can reproduce your circumstances.  Which is why BE has provided an updated diagnostic hg612_stats.exe for you to run.  If you could possibly bear with us and try that out, then perhaps the additional evidence it might provide may help us all resolve this infuriating issue for you.

I know I and understand your are helping me find the cause or cure to this 

Its not looking good here but it's only up and running using r1.1 in the last 10 minutes, done the usual stopped old version schedule and then deleted the C:\Hg612_Modem_stats folder and rebooted then installed r1.1 into C:\HG612_Modem_stats, the old version when starting the schedule gave me 2 options Vista/Win 7 (1) or XP ! this 4.1 version pops up in a screen -> when setting up a schedule it's very normal as I have don't have password as I am the sole user.

I will post the Modem_stats soon, and I am using the downloaded graph_stats file as above

[NewtronStar]

Slighty better but missing samples maybe 3 mins lost in 10 mins 
anything else you need me to attach ?

[NewtronStar]

I do get the same problem on same PC H/W on windows 8.1 thats what is freaking me out as it looks like H/W issue in 4.1 but not in 2.0 

How are you running Windows 8.1 & Vista on the same PC?
Via a dual boot or some sort of emulator?

Dual Boot

[Bald_Eagle1]

Slighty better but missing samples maybe 3 mins lost in 10 mins 
anything else you need me to attach ?

Yes, the ERROR.LOG_file_ERROR.TXT file (from the Ongoing_Stats folder).

That should at least indicate exactly where the get_data() function fails.

[NewtronStar]

Yes, the ERROR.LOG_file_ERROR.TXT file (from the Ongoing_Stats folder).

That should at least indicate exactly where the get_data() function fails.

here is the error.log_file.txt and will help in anyway I can to facilitate you further in finding whats causing my stats issue