Print

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

[NewtronStar]

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.

[NewtronStar]

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 . . . 

  he will never hear the end of it 

[burakkucat]

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 . . .

[kitz]

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 

[kitz]

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.

[NewtronStar]

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.

[NewtronStar]

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.

[burakkucat]

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.

[ColinS]

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.

[NewtronStar]

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)

[ColinS]

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

[NewtronStar]

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 

[ColinS]

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 

[NewtronStar]

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 

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 !

[ColinS]

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.