What is Rolling Average?
 

Started my first assignment - double checking a LL exponent - nearly 2 weeks ago. After watching the data files I would like to know what the RollingAverage is and means in the local.ini file. I've watched it as a 4-digit number gradually increase to 4000 where it has remained for the last few days. Is it something to do with the amount of time that mprime is running?

It is a fudge factor to calculate the ETA. mprime/Prime95 initially makes the estimate based on the processor type & clock speed. However, sometimes the estimate ends up wrong. To compensate for it, it uses the RollingAverage setting (updated twice a day as per the documentation). It will increase this value (default is 1000, i think) if it finds that it has been overestimating the time (i.e. underestimating the processor capability), and decreases it otherwise.

So a RollingAverage of 4000 means your processor can run mprime 4x faster than what the software initially assumed.

[PS:- Posting this from memory. Maybe someone (George himself?) can verify it?]

EDIT:- You can refer to [URL="http://www.mersenneforum.org/showthread.php?t=789&highlight=RollingAverage"]this thread[/URL] for some more details

[QUOTE]So a RollingAverage of 4000 means your processor can run mprime 4x faster than what the software initially assumed.[/QUOTE]

Thanks for your reply. It makes sense because I underestimated the number of hours per day I would have the computer running. I did this deliberately because I wanted to prevent my assignment becoming overdue and being given to someone else, but since then it's clear to me from reading this forum that this will not happen provided my computer is able to contact the server once every number of weeks to report progress. So maybe I will increase the CPUHours line in local.ini - or maybe this really doesn't matter.

But I must say that 4X faster than the estimate (or even more - I note from your link that 4000 is the highest value for RollingAverage) is too optimistic. The original estimated time for completion was 58 days as communicated to the server. Based on the progress up to now it will be about 30 days total. Does 4000 really mean 4x as fast?

[QUOTE=Brian-E;110078]Does 4000 really mean 4x as fast?[/QUOTE]

Yes. But if you told prime95 that you'd be running the computer 2 hours a day and instead are running it 20 hours a day, then even a 4x rolling average will make the estimate correct.

Go to Options/CPU and enter the proper hours per day. This will reset the rolling average back to 1000.

[quote] Go to Options/CPU and enter the proper hours per day. This will reset the rolling average back to 1000.[/quote]

Changed the hours from 4 (as originally given) to 7 (more accurate estimate) using the menu and the rolling average indeed reads 1000 now.
Thanks for the help. :smile:

Update
 

[quote=Brian-E;110109]Changed the hours from 4 (as originally given) to 7 (more accurate estimate) using the menu and the rolling average indeed reads 1000 now.
Thanks for the help. :smile:[/quote]

Meanwhile the Rolling Average has gradually increased from 1000 to 1669 despite the fact that I've been running mprime slightly under the newly-estimated 7 hours per day and will probably not quite make the newly estimated finish date. Does anyone have any possible explanation for this behaviour of RollingAverage? Are there extra subtleties?

[quote]...and will probably not quite make the newly estimated finish date...[/quote]
Don't worry about it. The work will get done when it gets done. You won't lose any work.

[quote=Xyzzy;110720]Don't worry about it. The work will get done when it gets done. You won't lose any work.[/quote]

Thanks, though I'm still interested in the finer points of how the clients interact with the primenet server to make estimates of time of completion.

It looks to me now as if the Rolling Average never decreases unless you alter some parameters yourself. It returned to 1000 when I re-estimated my hours per day from 4 to 7 as recommended, but since then it has sporadically increased. I think probably that comes from the fact that I have the computer on very irregularly. Often only 2-3 hours in a day, occasionally as many as 14 hours. The last time it was on for 14 hours the rolling average increased to 2009 where it has since stayed despite running only about 3 hours per day in recent days. Towards the end of that 14 hour run the client contacted the server for new work and gave an estimated completion date for the new exponent which would be about right if mprime was running 14 hours every day - far too optimistic.

I guess these observations are not very important. The work allocation clearly works well in any case. But the mechanics of it do interest me. Does anyone know if there's a better way for me to operate given that the number of hours per day that the client runs on my machine fluctuates wildy?

You could feed it work manually. On several of our boxes we do so.

Our RollingAverage is [I]always[/I] less than 1000. Our computers are on all the time but other processes steal cycles and end up giving Prime95 less than a day's worth of work per day.

For example, the box we are typing this message on has a RollingAverage of 983.

We like to think of it as a percent. This box gives Prime95 98.3% of its available cycles. (This thought process only works when you run it all the time.)

George: Why don't you make it a percent?

[quote=Xyzzy;111080]You could feed it work manually. On several of our boxes we do so.[/quote]

Thanks, I might try that should the optimistic predicted dates prove to be any problem.

Thanks for all the help.

After about 3 months of running mprime version 24.14 on my linux platform I'm now convinced that the Rolling Average doesn't work as it should when mprime runs irregular hours. Possibly my limited number of hours per day is a bit unusual so that this bug hasn't been obvious before - or maybe it's already known but not considered a priority problem?

In any case for what it's worth: My computer is on roughly 6 hours per day on average (this varies between 0 on some days and about 14 hours on others). My observations of Rolling Average is that it is never adjusted downwards unless I change the CPUHours setting in local.ini when it reverts to 1000. It does however get nudged gradually upwards on days when the computer is on for longer than average. Therefore it heads forever upwards - now on 3200+ when it should be around 1000 - and the server is theredore given estimated completion dates which are too optimistic.

As stated by others above, it isn't really a serious problem. However maybe the bug might be addressed in future versions of the client software?