Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: NewtronStar on September 11, 2013, 05:35:01 PM
-
I am getting the Retrain Reason 8000 on HG612 it was at 0 four hours ago and internet is faster up & down but SNR margin has gone down from 6.3 to 3.2, I have forgotten what the 8000 code meens.
-
I can't recall if we ever determined the origin for that numeric reason but if you put the string 'Retrain Reason' into the 'Search' box (above at right hand side) and click on 'Search' it will show you five pages of results. You won't need to read them all . . . probably just the first 6 - 8. :-\
-
but if you put the string 'Retrain Reason' into the 'Search' box (above at right hand side) and click on 'Search' it will
I have been searching on the Web for 8000 but most of them seem to ADSL related, and the search box on Kitz forum only shows two post ;) my post and your reply ???
-
Ok it looks like a normal retrain reason 2 but 8000 is retraining you to a lower SNR margin to see if your line can go faster and remain stable during this stage.
or it looks like reason 2 is a loss of framing which is I believe something to do with the equipment at the exchange.
-
I was using this thread to make note of any retrain reason codes (http://forum.kitz.co.uk/index.php/topic,12504.0.html) that Id experienced, theres some info in there from Asbo which may explain it
-
It's understood that those codes are values for bitwise left shift operations.
e.g.
1<<15 (or 2^15) is 0x8000 (Retrain Reason: G992 Failure)
1<<13 (or 2^13) is 0x2000 (Retrain Reason: DSL Start Physical Layer Cmd)
cheers, a
EDIT: so combining 0x8000 and 0x800 ((1<<15) & (1<<11)) suggests a G992 Failure because of a Tone Ordering Exception.
Could be wrong though :blush:
Cheers Kitz for the link but still don't understand after the HG612 went 8000 speeds are faster but SNR Margins are halved so it may be a short term speedup until the next retrain ! I have only saw this happen twice in 14 months on BT FTTC 40/10
and wonder if anyone can help me with the stats layout on 4.1 here is a 3 day log but as you can see you cannot read the bottom the time logs it all seems squashed.
[Moderator edited to fix a broken link.]
-
speeds are faster but SNR Margins are halved so it may be a short term speedup until the next retrain !
You may be right. How long it will remain at 3dB for is anyones guess. Looking at your graphs daily variance looks to be around 1.5dB, so it may hang in there but experience lots of errors. atm it certainly doesnt look like you'd get that speed again now if you rebooted.
Your DS FECs have certainly increased.
Id keep an eye on the DS Err Seconds though, because if they continue to be high then the DLM is going to cut in anyhow. How many over the past 24hrs I cant tell from the graph
If so, Im wondering if you perhaps just call it quits, and realise that the DLM is likely to notice - In fact it looks like its already done so - Ive just noticed the increased interleaving depth. :(
----------
As regards to the graphs, not seen anything like that before. Are your dailies like that, or just the 3 day run
From the missing blocks in the interleaving and uptime, it doesnt look like its been recording all data.
-
In fact it looks like its already done so - Ive just noticed the increased interleaving depth. :(
----------
As regards to the graphs, not seen anything like that before. Are your dailies like that, or just the 3 day run
From the missing blocks in the interleaving and uptime, it doesnt look like its been recording all data.
Thanks Kitz you noticed the interleaving has gone up to it's not a massive jump like 6 months ago when it went upto 1600, what I am going to do is leave it and not reboot the HG612 and see what happens but I know how it's going to end up.
and the Stats with V4.1 on Vista has given me hassle since day one was gonna go back to V1.1 but some stats will be lost, BE1 done his best to find whats causing this it looks ok if you do a 30 day log but it do a 20 day 7 day 3 day 1 hour the times are squished :(
-
gonna go back to V1.1 but some stats will be lost,
If you find the file modem_stats.log in the HG612_Modem_Stats\Ongoing_Stats folder. Make a copy of it and drop it into the other version and it should retain the data for you.
Thanks Kitz you noticed the interleaving has gone up to it's not a massive jump like 6 months ago when it went upto 1600,
What concerns me is that from the information we are gathering about the FTTC DLM (http://forum.kitz.co.uk/index.php/topic,12896.0.html), it will be recording the increase in your error seconds and will have noticed it already. Once your 'poor count' reaches a certain level then its going to be increasing your interleaving and start capping the speed anyhow.
I only suggested it because I think if it was my line, I'd probably resync now.. knowing that its not going to last. That way at least Ive lessened the chance of it applying more interleaving.. which could take a while to get rid of. :/
-
gonna go back to V1.1 but some stats will be lost,
If you find the file modem_stats.log in the HG612_Modem_Stats\Ongoing_Stats folder. Make a copy of it and drop it into the other version and it should retain the data for you.
Thanks Kitz you noticed the interleaving has gone up to it's not a massive jump like 6 months ago when it went upto 1600,
What concerns me is that from the information we are gathering about the FTTC DLM (http://forum.kitz.co.uk/index.php/topic,12896.0.html), it will be recording the increase in your error seconds and will have noticed it already. Once your 'poor count' reaches a certain level then its going to be increasing your interleaving and start capping the speed anyhow.
I only suggested it because I think if it was my line, I'd probably resync now.. knowing that its not going to last. That way at least Ive lessened the chance of it applying more interleaving.. which could take a while to get rid of. :/
I hear you loud and clear i'll reboot the HG612 now and again thanks.
Ah well I have lost 5 megs down and 1 up but it was not going to last long anyway then move me to a higher interleave depth which I don't want, so I am back to 433 interleave depth and SNR Margin is also back into the 6's ;D
-
I had to do quite a bit of horizontal scrolling to view your latest montage. :-X That's the reason why the No Feathers software also produces a portrait version of the montage . . . posting to fora, for the use of.
Your QLN & SNR graphs are extremely 'ragged' and I'm not too sure what to make of them. :-\
I am very surprised that you do not see the five pages of search results as I do . . . ??? I've attached a 'screen scrape', below.
-
Just to confirm.. I also see 5 pages of results ^. I didnt try earlier and went straight to the thread where I knew it was being discussed.
-
I had to do quite a bit of horizontal scrolling to view your latest montage. :-X That's the reason why the No Feathers software also produces a portrait version of the montage . . . posting to fora, for the use of.
Your QLN & SNR graphs are extremely 'ragged' and I'm not too sure what to make of them. :-\
I am very surprised that you do not see the five pages of search results as I do . . . ??? I've attached a 'screen scrape', below.
I will keep that in mind when attaching montage ;) the horizonal looks good to me on the widescreen moniter (photo gallery) but may not look so good via the forum page.
the search box seems to working for me to-day so i'll plod though them to-night.
I wonder if you know were I could get my hands on the older version of the HG612 Stats program to see if it fix's my odd stats currently using V4.1 so looking for v1 or V1.2
-
I wonder if you know were I could get my hands on the older version of the HG612 Stats program to see if it fix's my odd stats currently using V4.1 so looking for v1 or V1.2
I believe the BE may be away atm, but if you give me a couple of mins, I'll zip and upload v1.1 somewhere for you
---
http://kitz.co.uk/downloads/HG612_Modem_Stats.Programs-r1.1.rar
-
I believe the BE may be away atm
I think it was a year ago when someone was given a severe pecking by Mrs Eagle as a result of forgetting their wedding anniversary! I believe that a significant financial sum has been spent this year . . . :-X
-
I believe the BE may be away atm, but if you give me a couple of mins, I'll zip and upload v1.1 somewhere for you
cheers kitz, the times and dates at the bottom have become unreadable all bunched up I don't know if there are any settings in V4.1 to adjust the fonts, in one of the older versions it was Graph6.bat file you could adjust this for Vista, so going to see if the older one fix's it.
-
I believe the BE may be away atm
I think it was a year ago when someone was given a severe pecking by Mrs Eagle as a result of forgetting their wedding anniversary! I believe that a significant financial sum has been spent this year . . . :-X
:o he will never hear the end of it ;)
-
A sudden thought by me. ::)
Are you running the data 'harvesting' utility constantly? Or do you start and stop the data gathering? ???
If the latter is true, that may well account for the mangled X-axis of your latest graphs . . .
-
oh dear... that is bad!. I take it that BE would have been in bad books for quite a while!
Hopefully though this year, by getting out his wallet and choosing somewhere nice.. all will be forgiven.
Hopefully too the BE has learnt a lesson that the female of the species gets upset if certain things are overlooked. Its far better & easier (and cheaper in the long term) not to ignore certain matters ;D
-
A sudden thought by me. ::)
Are you running the data 'harvesting' utility constantly? Or do you start and stop the data gathering? ???
If the latter is true, that may well account for the mangled X-axis of your latest graphs . . .
...or just thought... could happen if the PC is switched off.
-
A sudden thought by me. ::)
Are you running the data 'harvesting' utility constantly? Or do you start and stop the data gathering? ???
If the latter is true, that may well account for the mangled X-axis of your latest graphs . . .
...or just thought... could happen if the PC is switched off.
Yes I turn off the PC at night and I know it should be on 24/7 but it's been a pain in the bleep with 4.1 it seems to log ever random minute, yet I have removed V4.1 and installed V2.0 and backed up logs and put the logs back onto V2.0 and it seems its logging away ever minute.
I will show you later on after say 5 hours of harvesting the difference between V4.1 and V2.0 on my vista, what ever it is my PC does not like V4 or V4.1.
-
I don't need to leave for five hours as you can see in my logs just after installing V2.0 at 18:28 you will see its recording ever minute, and look at V4.1 from 16:57 to 17:38 thats my problem here.
-
I've seen it and appreciate what you say. :) Unfortunately I can not explain it. :(
I suspect it is something that you will need to discuss with Bald_Eagle1, upon his return.
-
Without knowing what interval NewtronStar was trying to plot, may I venture to suggest an explanation?
The way that Ongoing stats plots works (graphpd.exe) is that it translates the requested plotting interval into the equivalent number of 1 minute samples. So, with the 1day default, it is looking for 1440 samples. If your modem hasn't been 'up' full time, then this sample interval may span several days.
I can't say for sure that this is what has happened here, but I have certainly seen the same 'bunching' occurring in my own plots when, for example, I was away for several days and everything was powered down. A 1d plot then spanned the interval back to before I went away.
The explanation I have suggested is the very same explanation given to me by our most revered feathered friend.
Here are his very own words:
at the moment there is no way to specify a date range other than copying & pasting an extract from modem_stats.log to a new file.
graphpd.exe works backward & plots the latest x number of samples from the default modem_stats.log.
e.g. every sample is assumed to be 1 minute so :-
Specifying nothing at all assumes the latest 1 day period is required (the latest 1440 minutes/samples).
30 m is assumed to be the latest 30 minutes. It is actually the latest 30 samples.
16 h is assumed to be the latest 16 hours. 16 hours multiplied by 60 minutes = 960, so the latest 960 samples SHOULD BE plotted.
3 d is assumed to be the latest 3 days. 3 days multiplied by 1440 minutes = 4320, so the latest 4320 SHOULD BE plotted.
-
I've seen it and appreciate what you say. :) Unfortunately I can not explain it. :(
I suspect it is something that you will need to discuss with Bald_Eagle1, upon his return.
I really do appreciate all the help you guys have given in this thread 8)
-
I don't need to leave for five hours as you can see in my logs just after installing V2.0 at 18:28 you will see its recording ever minute, and look at V4.1 from 16:57 to 17:38 thats my problem here.
If you're refering to missing 1min samples, then if the v1.1 that Kitz has posted for you was BE's 'original' v1.1, then you may also be experiencing the problems with that, detailed here (http://forum.kitz.co.uk/index.php/topic,12844.0.html)
-
Without knowing what interval NewtonStar was trying to plot, may I venture to suggest an explanation?
The way that Ongoing stats plots works (graphpd.exe) is that it translates the requested plotting interval into the equivalent number of 1 minute samples. So, with the 1day default, it is looking for 1440 samples. If your modem hasn't been 'up' full time, then this sample interval may span several days.
I can't say for sure that this is what has happened here, but I have certainly seen the same 'bunching' occurring in my own plots when, for example, I was away for several days and everything was powered down. A 1d plot then spanned the interval back to before I went away.
The explanation I have suggested is the very same explanation given to me by our most revered feathered friend.
Here are his very own words:
at the moment there is no way to specify a date range other than copying & pasting an extract from modem_stats.log to a new file.
graphpd.exe works backward & plots the latest x number of samples from the default modem_stats.log.
e.g. every sample is assumed to be 1 minute so :-
Specifying nothing at all assumes the latest 1 day period is required (the latest 1440 minutes/samples).
30 m is assumed to be the latest 30 minutes. It is actually the latest 30 samples.
16 h is assumed to be the latest 16 hours. 16 hours multiplied by 60 minutes = 960, so the latest 960 samples SHOULD BE plotted.
3 d is assumed to be the latest 3 days. 3 days multiplied by 1440 minutes = 4320, so the latest 4320 SHOULD BE plotted.
the HG612 modem is on 24/7 it has been in sync for 46 days until 1 day ago until I hit the retrain 8000 code and SNR margin halved so did a reset, the PC is on 8 hours a day I am still at a loss as to why the latest 4.1 stats is now bunching up the times when 2.0 never did
I have 3 months of logs to date but as you can see in I am loseing 3-4 mins per 10 mins of logging data so then I may have only have 2 weeks of data in the Modem Stats file :o
-
Yes, sorry, I really meant to say the PC (rather than the modem) up, as it is that which is running the 1min harvesting. My mistake, although if the modem had been down, then it can't be sampled then either.
I'm afraid I don't recognise the version numbers that you refer to, but that's just my faulty recollection. v1.0 was BE's first 'compiled' version of the package, and v1.1 was a more recent update to that. I cannot recall what version number I had previously when it was the .bat files.
So, yes, a combination of switching off the PC, the harvesting issues with v1.1, and the not-immediately-obvious semantics of the Ongoing stats plotting, may well result in it searching a 'sparse' modem_stats.log file for the required number of samples, resulting in the bunching that you are seeing.
I appreciate that this does not fully explain why 'it worked before', but then, it didn't have this harvesting issue then either. I think therefore your conclusion is probably correct. :(
If you can find & download Textpad, or some other similar editor that can give you record numbering, you should be able to find out exactly how many real samples you have in your file.
HTH :)
-
Yes, sorry, I really meant to say the PC (rather than the modem) up, as it is that which is running the 1min harvesting. My mistake, although if the modem had been down, then it can't be sampled then either.
I'm afraid I don't recognise the version numbers that you refer to, but that's just my faulty recollection. v1.0 was BE's first 'compiled' version of the package, and v1.1 was a more recent update to that. I cannot recall what version number I had previously when it was the .bat files.
So, yes, a combination of switching off the PC, the harvesting issues with v1.1, and the not-immediately-obvious semantics of the Ongoing stats plotting, may well result in it searching a 'sparse' modem_stats.log file for the required number of samples, resulting in the bunching that you are seeing.
I appreciate that this does not fully explain why 'it worked before', but then, it didn't have this harvesting issue then either. I think therefore your conclusion is probably correct. :(
If you can find & download Textpad, or some other similar editor that can give you record numbering, you should be able to find out exactly how many real samples you have in your file.
HTH :)
Many thanks ColinS you have given a path which I never though of until are last two posts (how many real samples do I have) brillent idea ;D
and unfortunatley the way the versions are named or unnamed is confusing me I know a V4.1 because it says it on the stats screen but the upload says r1.1 :(
here are my stats on what I call V2.0, again if i go over 3 hours the times look squashed but then I have been using 2.0 for over three hours, something is not right with 4.1 for me and it's a bloody good program and I just wish it would work for me !
-
and unfortunatley the way the versions are named or unnamed is confusing me I know a V4.1 because it says it on the stats screen but the upload says r1.1 :(
Ah, I see now! You have been far more observant than me! It does indeed say that on the plots, so v1.0=v4.0, and v1.1=v4.1.
[Edit] and the .bat v0.4=v2.0
here my stats on what I call V2.0, again if i go over 3 hours the times look squashed but then I have been using 2.0 for over three hours, something is not right with 4.1 for me and it's a bloody good program and I just wish it would work for me !
It may well be the same problem, and you're almost there ...
at the moment there is no way to specify a date range other than copying & pasting an extract from modem_stats.log to a new file.
when you go back >~3hrs, given the missing samples, you may have less than 180 records in that real time interval. Say you had just 10 missing (I appreciate that it is probably much more than that). It would continue to look further back in the log for them. If it finds any (<=10), then it will use the earliest date it has found to start the plot, and the last date to end it, resulting in it bunching up again.
Try copying the complete log temporarily elsewhere, and remove all the records except those for a continuous period (ignoring missing ones) of say 3 hours (but not any from an earlier time). Then I think that if you asked it even to plot 1 day, it would assume there were no earlier samples, and simply plot the data from those 3 hours as the last 3 hours of the 24hr period. It's safer to stop logging using the setting editor while you do that & start it again afterwards. You can run graphpd from there too.
Does that make any sense?
[Edit]PS: the thread I mentioned in reply #25 above has some replacement modules provided by BE to try to overcome the harvesting issue with v1.1/4.1. Try those. They work for me. :)
-
Does that make any sense?
[Edit]PS: the thread I mentioned in reply #25 above has some replacement modules provided by BE to try to overcome the harvesting issue with v1.1/4.1. Try those. They work for me. :)
It does make sense the way you put it but now i'll have to put it into practise but I am still using V2.0 or upload version 0.4 and I am happy to go back to V4.1 if you have link to those replacement modules as upbove and your posts are very helpfull indeed ;)
-
If you're willing to try BE's v4.1 again, apply the 3 files below in order to the Scripts subdirectory. Files 2 & 3 replace earlier ones in File 1. Afterwards you should have:
Set_HG612_Date_and_Time.exe dated 30/08/2013_17:11
HG612_Current_Stats.exe dated 04/09/2013_06:19, and
HG612_Stats.exe dated 04/09/2013_22:01
If you also run DSLStats, you should use v3.95 (see reply #112 in http://forum.kitz.co.uk/index.php/topic,12844.msg244301.html#new (http://forum.kitz.co.uk/index.php/topic,12844.msg244301.html#new)), and the synchronise with HG612 option, or (using the Windows Time Clock), start v3.94 manually at about 35s past the min.
[edited] to reflect Roseway's latest changes.
In my last post about copying the modem_stats.log: The copy is to preserve your data for restoration later. You will then have to edit the modem_stats.log in situ as this is where graphpd.exe expects to find it. Alternatively, I believe that you can edit the copy elsewhere and then manually drag & drop it onto graphpd.exe, which should then open in a command windows and ask you about the desired plotting interval.
Good luck if you decide to try it, but I would understand if you decided to wait for BE's return instead. ;)
-
The way that Ongoing stats plots works (graphpd.exe) is that it translates the requested plotting interval into the equivalent number of 1 minute samples. So, with the 1day default, it is looking for 1440 samples.
Thanks for that info.. I wasnt aware thats how it calculated the daily stats.
That would explain why I saw some weirdness plotting graphs over the periods when HG612_stats hadnt been recording for periods due to the stuck multiple instances in task manager.
I wonder if a slight default modification could be made to graph.exe by calling the equivalent of Date.getTime() to work out the periods to graph.
Obviously I dont have access to the source to say for sure -nor know which language its programmed in - but perhaps a small function could be added so that each day could be graphed correctly. I suppose the hardest part would be finding the correct date/time to read back from the file, and if theres a lot of dates with missing data, would this slow things down?
-
I wonder if a slight default modification could be made to graph.exe by calling the equivalent of Date.getTime() to work out the periods to graph.
I had already decided to email BE to suggest something similar. :) He'll love that to come back to! :-X
I suppose the hardest part would be finding the correct date/time to read back from the file, and if theres a lot of dates with missing data, would this slow things down?
I'll leave that to BE to decide, but I know that he is already concerned that a 'normal' daily plot takes almost 2mins on my (admittedly slow) server, which has caused 1-2 of the normal harvesting samples to be missed at that time. While it does seem simple in principle, no doubt it will be more tricky with large logs (say months & months), and any arbitrary plotting interval (of days, hours or minutes). I think you could say that this part of it is still a work in progress (since e.g. you can't give a date range, and have to make an extract from the modem_stats.log). :)
-
He'll love that to come back to!
I bet! Wonder if we will see him for a while or if he'll hide :lol:
While it does seem simple in principle, no doubt it will be more tricky with large logs (say months & months), and any arbitrary plotting interval (of days, hours or minutes).
Yes thats what concerned me.. the theory is simple, but the downside of going through a large log with several months of data to slow things down may not be such a good idea. Perhaps a half way house solution that existing method is used for the daily ongoing stats so it doesnt clog things up. But with a more detailed get.Time option for say up to so many days, that is disregarded for periods over a month? I dunno.. BE knows how his prog works, so is in the best position to say what he can and cant do. At the end of the day he puts a lot of time into it as it is.. and Im grateful for what we do get now.
-
If you're willing to try BE's v4.1 again, apply the 3 files below in order to the Scripts subdirectory. Files 2 & 3 replace earlier ones in File 1. Afterwards you should have:
Set_HG612_Date_and_Time.exe dated 30/08/2013_17:11
HG612_Current_Stats.exe dated 04/09/2013_06:19, and
HG612_Stats.exe dated 04/09/2013_22:01
If you also run DSLStats, you should use v3.95 (see reply #112 in http://forum.kitz.co.uk/index.php/topic,12844.msg244301.html#new (http://forum.kitz.co.uk/index.php/topic,12844.msg244301.html#new)), and the synchronise with HG612 option, or (using the Windows Time Clock), start v3.94 manually at about 35s past the min.
[edited] to reflect Roseway's latest changes.
In my last post about copying the modem_stats.log: The copy is to preserve your data for restoration later. You will then have to edit the modem_stats.log in situ as this is where graphpd.exe expects to find it. Alternatively, I believe that you can edit the copy elsewhere and then manually drag & drop it onto graphpd.exe, which should then open in a command windows and ask you about the desired plotting interval.
Good luck if you decide to try it, but I would understand if you decided to wait for BE's return instead. ;)
Have done all that to-day but V4.1 is still missing 4 mins samples per 10 mins I doubled checked and triple checked the task manager and it only shows 1 task called HG612 stats program and it repeats every 1 minute but some samples don't get through using Microsoft Windows security essentials but I very much dought thats the cause, CPU is dual core 3.20GHZ so thats not the problem but V2.0 harvest's every minute but V4.1 keeps missing 4 mins out of 10
I have to point the finger at the software also have a fresh install of windows 8 and it does the same or could it be my hardware ?
This is a fresh log using V4.1 ->
-
Thank you for trying that for us NewtronStar.
Could I possibly ask you to zip up the following files & post them here for us, if possible. I will then, in BE's continuing abscence, attempt to take a look at them to see if I can spot anything that might give us a clue about what's going on.
First of all, all of these files will be in use, so please disable all logging using the settings editor while you make copies of them. Thank you.
the files that would be useful to see are:
In the Ongoing Stats subdirectory -
ERROR.LOG_file_ERROR.TXT
ERROR.LOG
and an extract of the modem_stats.log file from when you started running with these debugging modules earlier today
In the Scripts subdirectory,
Login_events.txt
Do you ever have any files in the Scripts subdirectory with filenames like ONGOING-ISRUNNING-172044-106.TXT?
If so could you zip those too please?
Can't promise to spot the problem, but I can promise to look carefully at it for you.
HTH :)
-
Thank you for trying that for us NewtronStar.
Can't promise to spot the problem, but I can promise to look carefully at it for you.
HTH :)
OMG that's a big list ;D I'll do my best !
1. logging disabled
2. Error.Log file from Ongoing stats attachment below
3. Modem_Stats.log file/login_events.txt attachment below
and thanks for looking into this for me as I have nearly given up hope after 3 months.
edit here is the Error.txt file below
-
Hi NewtronStar,
I have sent you a PM with the full analysis of what I could see, but briefly, here are the conclusions:
It seems that you are missing samples because HG612_modem_stats is occasionally failing to read data from the modem leading it to believe that the modem has resync'ed. It's not possible yet to tell why that is happening, and it may require BE's return to resolve it fully, but I have asked you for some additional information in case I can spot anything else.
I attach your plot. :)
-
It seems that you are missing samples because HG612_modem_stats is occasionally failing to read data from the modem leading it to believe that the modem has resync'ed. It's not possible yet to tell why that is happening, and it may require BE's return to resolve it fully, but I have asked you for some additional information in case I can spot anything else.
I attach your plot. :)
Hello ColinS
Many thanks for the PM and read every word it looks like I am in good hands here ;D
to-day I have disabled firewalls and security programs to see if it made any difference but no change, and it still remains a fresh log as I don't see any point merging old & new logs until we find the cause of the missing data.
Now it was my worry that for some reason the PC to Router (HH3) to Modem (HG612) may be causing some samples to be ignored , but it did work fine in V2.0 (older stats software) and nothing in that Hardware department has changed in 14 months.
Very much appreciated for looking into this odd issue.
-
Very much appreciated for looking into this odd issue.
Edit here is the other Plink log sorry had to split it up due to attachment limit
-
Thank you for that additional information NewtronStar. :)
Again, I have PM'ed you with the full analysis, but here is a summary:
As I concluded above, (far too often to be readily explainable) when hg612_stats.exe is calling xdslcmd info --stats, no data is being returned. This causes BE's code to detect a false positive resync event, which in turn causes it to take a post-resync snapshot ~7secs later in which it issues exactly the same xdslcmd info --stats, which this time works!
See here for an example:
14/09/2013 20:02:01.829 - About to reply(xdslcmd info --stats)
14/09/2013 20:02:01.829 - reply(xdslcmd info --stats) O.K.
14/09/2013 20:02:01.843 - ERROR - get_data() FAILED!!!! - exiting the program <<<<<---------- the smoking gun! from hg612_stats
14/09/2013 20:02:01.855 - Current sync speeds are DS 0 kbps US 0 kbps <<<<<---------- no data
14/09/2013 20:02:01.855 - Previous sync speeds are DS 0 kbps US 0 kbps
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2013.09.14 20:02:09 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats <<<<<----------- exactly the same modem command from graph6
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 6546 Kbps, Downstream rate = 32116 Kbps
Path: 0, Upstream rate = 6569 Kbps, Downstream rate = 27337 Kbps
The only time BE and I have seen this happen previously, we concluded (or assumed, as we couldn't prove it) that perhaps overlapping instances of xdslcmd info --stats calls had occured, and so only one of them got the data. ATM that's all I can think it is, but I can't quite see why this is happening, unless (and I have absolutely no idea and I am now clutching at straws) perhaps the HH3 queries the HG612 as well? Is that a possibility does anyone else know? :-\
Apart from that I don't think I can extract any more information from the available diagnostics, and we shall have to await the return of our much missed feathered friend. ;D
-
@ Colin S,
Speaking as a novice in these matters, perhaps we should note that dual-port access to a single resource is unlikely to have been fully tested by the manufacturers. It is conceivable that a "busy flag" check has been omitted.
Perhaps we should also record the types of router involved as well ?
Kind regards,
Walter
-
perhaps we should note that dual-port access to a single resource is unlikely to have been fully tested by the manufacturers. It is conceivable that a "busy flag" check has been omitted.
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.
Perhaps we should also record the types of router involved as well ?
Yes, that is a very good suggestion. If people reporting issues similar to NewtronStar's (regular missing samples) could do that, then perhaps a pattern could be established, yes. ATM, in the absence of anything else to be suspicious of, I have a mental query about the extent to which the BTr HH is aware of the modem. :)
-
Perhaps we should also record the types of router involved as well ?
Yes, that is a very good suggestion. If people reporting issues similar to NewtronStar's (regular missing samples) could do that, then perhaps a pattern could be established, yes. ATM, in the absence of anything else to be suspicious of, I have a mental query about the extent to which the BTr HH is aware of the modem. :)
I could directly connect the PC to HG612 and bypass the BT Home Hub 3 and see if it fix's the missing samples, PC is connected to lan port 4 on HH3 and Wan from HH3 is connected to HG612 lan port 1 and Hg612 Lan port 2 is then connected to HH3 lan port 3
So will it work if I connect PC directly to Lan port 2 on the HG612 ?
-
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.
-
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?
-
Right. I'm back now, from an enjoyable week in sometimes sunny Spain.
I hope you let your feathers down during the break :o you don't have any ah well as long as you relaxed thats the main thing ;)
-
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
-
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.
-
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.
-
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 :'(
-
and 4.1 Modem_stats
-
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?
-
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. :)
-
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
-
Slighty better but missing samples maybe 3 mins lost in 10 mins :(
anything else you need me to attach ?
-
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
-
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.
-
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 :thumbs:
-
Thanks for that.
I can now see where the get_data() function fails.
I have created another debugging version that will hopefully deal with that.
Basically, as it seems that another attempt to obtain the data after a couple of seconds pause is successful, I have built in a 2 second pause on failure before the program attempts to obtain the data again.
I'm afraid I have no idea why it occasionally fails on your system, other than the modem may be very busy doing something else at the time, but hopefully this version will deal with it.
If not, we could try a slightly longer pause or another retry or two to see if that resolves the issue.
I've asked ColinS to try it out on his system & if everything seems O.K. I'll attach it for you to try out at your end.
Neither ColinS or I suffer from this failure to obtain the data, so we are unable to actually test if this version actually deals with the issue adequately.
Hopefully, your feedback will confirm one way or the other.
Once everything is confirmed as O.K., I'll get rid of the various debugging files, just leaving the program to deal with any issues quietly.
-
O.K. Here's the latest version that will (hopefully) deal with whatever is causing the get_data() function to fail.
If you could test it & post the "GET_DATA_FAIL.TXT" file from the Scripts folder & the "ERROR.LOG_file_ERROR.TXT" from the Ongoing_Stats folder along with a relevant extract from modem_stats.log, we should be able to see if the workaround is effective or not.
If not, I could try increasing the pause when the function occasionally fails or increase the number of retries.
For curiosity, which version of the HG612 are you using, is it still using the original BLOB & have you made any changes to the default unlocked settings at all?
-
Cheers BE1
stopped the shedule and replaced the HG612_stats.exe file you attached and started up the schedule again from within the Hg612 settings editor and let it run and it's coming up with an error see pic below.
-
Bare with me BE ;)
I will post the stuff you require soon just want the stats to build up after installing the new HG612_stats file but it does look promising, it's just this error i now get every 5 to 10 minutes
and you can look at the event below.
I have not changed any settings on the HG612
-
Hi NS,
I seem to remember you saying that you don't use a password on the account that was needed to set up the task? Sorry if I have that wrong. However, I wondered if perhaps this problem you're having could have anything to do with Vista's UAC? If you don't need it, have you turned it off? Either way, perhaps you could toggle it, and see if it gets round the exception or not.
Control Panel > User Accounts > Turn UAC On or OFF.
Just something to eliminate while we wait for BE. :)
-
here are the files you require and maybe not as good as i first thought, and still those popups saying HG612_stats has failed but just hit the X button and it go's away.
PS I don't want to take up to much of your time BE1 :-[
-
Hi NS,
I seem to remember you saying that you don't use a password on the account that was needed to set up the task? Sorry if I have that wrong. However, I wondered if perhaps this problem you're having could have anything to do with Vista's UAC? If you don't need it, have you turned it off? Either way, perhaps you could toggle it, and see if it gets round the exception or not.
Control Panel > User Accounts > Turn UAC On or OFF.
Just something to eliminate while we wait for BE. :)
Will do that ColinS
-
Hi NS,
I seem to remember you saying that you don't use a password on the account that was needed to set up the task? Sorry if I have that wrong. However, I wondered if perhaps this problem you're having could have anything to do with Vista's UAC? If you don't need it, have you turned it off? Either way, perhaps you could toggle it, and see if it gets round the exception or not.
Control Panel > User Accounts > Turn UAC On or OFF.
Just something to eliminate while we wait for BE. :)
Will do that ColinS
Sorry CS UAC turned off and still the HG612_stats program comes up with failure
I am going to boot to Win 8.1 and re-install r1.1 just for testing but all of my post will be Vista SP2 findings and error logs
Cheers
-
Sorry to have to post early at this stage and I know I said it will be only Vista SP2 but this time Win 8.1 is working fine with the original r1.1 the Modem_stats logs are looking good and no missing samples and no exceptions popping up ;D
But with only 36 Mins of data I can see it's working fine under Windows 8.1 ;D
so my conclusion is Vista is the problem here and not the Stats Software, I'll just have to change the boot option on PC to make Windows 8.1 as the default OS
-
Would you mind trying this version?
The pause before retrying to obtain the data is now 15 seconds.
Going off your previous log files when resyncs were incorrectly reported (causing HG612_current_stats.exe to obtain the data & generate logs/graphs), there didn't appear to be a problem when issuing the xdslcmd info --stats command & obtaining the data via the get_data() function.
FWIW, I am now running the program as per usual via my Windows 7 PC wired into the router.
I am also running it staggered by 30 seconds on Mrs. Eagle's Vista Home Basic SP2 laptop - wireless connection to the router.
Both versions have been running for around 45 minutes without any issues.
-
Would you mind trying this version?
The pause before retrying to obtain the data is now 15 seconds.
Going off your previous log files when resyncs were incorrectly reported (causing HG612_current_stats.exe to obtain the data & generate logs/graphs), there didn't appear to be a problem when issuing the xdslcmd info --stats command & obtaining the data via the get_data() function.
FWIW, I am now running the program as per usual via my Windows 7 PC wired into the router.
I am also running it staggered by 30 seconds on Mrs. Eagle's Vista Home Basic SP2 laptop - wireless connection to the router.
Both versions have been running for around 45 minutes without any issues.
No problems I'll have to reboot to Vista and test this version will be back soon !
-
Would you mind trying this version?
The pause before retrying to obtain the data is now 15 seconds.
Going off your previous log files when resyncs were incorrectly reported (causing HG612_current_stats.exe to obtain the data & generate logs/graphs), there didn't appear to be a problem when issuing the xdslcmd info --stats command & obtaining the data via the get_data() function.
FWIW, I am now running the program as per usual via my Windows 7 PC wired into the router.
I am also running it staggered by 30 seconds on Mrs. Eagle's Vista Home Basic SP2 laptop - wireless connection to the router.
Both versions have been running for around 45 minutes without any issues.
No problems I'll have to reboot to Vista and test this version will be back soon !
Sorry BE1 booted back into Vista and replaced Hg612_stats file and still the same issue, I use Vista Home premium but I doubt there is much difference between Basic & Premium
it's looking like it's my Install of Vista that is causing this issue as Windows 8.1 looks good.
So it looks like a Backup of Vista files or full re-install of Vista but TBH I think i'll ditch it and use Windows 8 from now on :ouch:
also I will need to go back to original r1.1 Modem_stats file on Vista as the testing one's keep comeing up on the screen as HG612 Stats failure every so often.
-
Sorry BE1 booted back into Vista and replaced Hg612_stats file and still the same issue, I use Vista Home premium but I doubt there is much difference between Basic & Premium
it's looking like it's my Install of Vista that is causing this issue as Windows 8.1 looks good.
I kept the Vista version running & it eventually failed a couple of times.
I saw the same issue as you, but I was at least then able to actually see what was wrong with the code & I am now fairly confident that I have fixed it to deal with this particular issue.
I have attached another version that ran overnight & dealt with each failure properly.
Would you mind a final test with this version?
The pause before retrying is now just 2 seconds, which worked every time at this end.
The relevant files to post are "GET_DATA_FAIL.TXT" from the Scripts folder & "ERROR.LOG_file_ERROR.TXT" from the Ongoing_Stats folder.
It would also be handy if you could post a relevant section from "modem_stats.log" - to cross-reference where any data is still missing and/or to confirm that the bug fix is actually working as intended.
Hopefully, this will now be the last time that testing is needed before I remove the need for the various detailed (& quite large) debugging logs.
-
I kept the Vista version running & it eventually failed a couple of times.
I saw the same issue as you, but I was at least then able to actually see what was wrong with the code & I am now fairly confident that I have fixed it to deal with this particular issue.
I have attached another version that ran overnight & dealt with each failure properly.
Would you mind a final test with this version?
The pause before retrying is now just 2 seconds, which worked every time at this end.
Hopefully, this will now be the last time that testing is needed before I remove the need for the various detailed (& quite large) debugging logs.
Bald_Eagle I think you have cracked it :clap:, because it's not missing any samples (minutes) in the modem_stats log and have not seen any failure popups.
Going to let this run for a few hours and post the files you require this evening
and many thanks.
-
Bald_Eagle I think you have cracked it :clap:, because it's not missing any samples (minutes) in the modem_stats log and have not seen any failure popups.
Here's :fingers:
Going to let this run for a few hours and post the files you require this evening
and many thanks.
And thank you also for persevering with all the testing & posting logs etc.
-
Here's :fingers:
And thank you also for persevering with all the testing & posting logs etc.
It's working 100% here ;D , I have 3 hours worth of stats built up and not one missing minute.
heres are the three relevant files for you to look at ->
:congrats: BE!
-
It's working 100% here ;D , I have 3 hours worth of stats built up and not one missing minute.
heres are the three relevant files for you to look at ->
That looks much better now (apart from the gap between 15:12 to 15:25 inclusive).
What happened there?
If the program was still supposed to be logging during that period, it looks like there are other issues to deal with.
If you had turned off the logging or had switched off the PC, ignore it.
If it was still supposed to be logging during that period, the "Login_events.TXT" log from the Scripts folder or the "ERROR.LOG" log from the Ongoing_Stats folder may give us some clues as to any other areas that need attention.
The montage of the graphs generated for all 209 samples from the modem_stats.log file are attached, clearly showing the gap.
-
That looks much better now (apart from the gap between 15:12 to 15:25 inclusive).
What happened there?
If the program was still supposed to be logging during that period, it looks like there are other issues to deal with.
If you had turned off the logging or had switched off the PC, ignore it.
If it was still supposed to be logging during that period, the "Login_events.TXT" log from the Scripts folder or the "ERROR.LOG" log from the Ongoing_Stats folder may give us some clues as to any other areas that need attention.
The montage of the graphs generated for all 209 samples from the modem_stats.log file are attached, clearly showing the gap.
You are Eagle Eyed ;) that was due to the PC going into sleep mode :-[ as it's set at 3 hours, I can see that in my graphs to , this is working very well indeed and i still have the older V4.1 stats logs from July but i am not going to merge those as it would look messy do you agree ?
edit post
I have attached a Full Monty over 5 Hours to show all is working correctly.
-
It's definitely looking good! :angel:
:drink:
-
It's definitely looking good! :angel:
:drink:
Yeah BC a big thankyou go's out to all the members and especially Bald Eagle & ColinS & Burakkucat for the "C" code if it were not for them I think i would be bald by now and Big Thanks to Kitz for making this possible :o geez it sounds like a Hollywood Oscar speech :lol:
-
i still have the older V4.1 stats logs from July but i am not going to merge those as it would look messy do you agree ?
edit post
I have attached a Full Monty over 5 Hours to show all is working correctly.
The thing to bear in mind is that the program assumes logging has been continuous.
i.e. 5 hours should normally equate to 300 minutes or 300 samples.
Looking at the start time of 13:41 & graph creation time of 18:54, (& assuming you generated the montage on the fly via graphpd.exe, 5 hours back from then should have started at 13:54, not 13:41 (13 minutes adrift).
The missing data from when the PC went into sleep mode equates to those 13 missing minutes/data samples (from 15:12 to 15:24 inclusive).
So, to plot a full day's worth of data, when the PC has not been logging for 1/2 the time, it would need to be plotted for 12 hours rather than 24 hours.
i.e. 720 minutes (i.e. data samples) or 12 hours rather than the 1440 samples that would equate to a full day of continuous logging.
I agree that merging the data from July might look messy & unless there has been a significant change in sync speeds and/or large differences in errors per minute, I personally wouldn't bother.
You could always try it to see what it looks like & unmerge it again if necessary.
-
The thing to bear in mind is that the program assumes logging has been continuous.
I fully understand that BE1 it would be nice to have a Rasberry PI running the stats 24/7 if I had one but this is all i have at the moment i can't afford to run the Desktop PC 24/7 at 120 watts per hour as every kilowatt Hour is expensive at 17.5p
-
Glad you got to the bottom of this and its all working now.
:)