mersenneforum.org how Estimated Completion works
 Register FAQ Search Today's Posts Mark Forums Read

 2019-07-25, 19:33 #1 ssybesma   "Steve Sybesma" May 2012 Brighton, CO USA 1318 Posts how Estimated Completion works Question came to me because I notice after a number is 3.4% completed in only 4 days that it says I have a lot more than what I would calculate (around 130 days) as the number of days to go to complete it. It says 582 days but that seems WAY more than what it will end up being at the end. The number of days to go does reduce each day by much more than 1. This particular exponent started with over 600 days to complete. Would it be reasonable to assume that if left alone uninterrupted that this will really complete when I think it will (in about 4 months)? I know because it gives you only 60 days to test each exponent that you have to extend them 60 more days, so I've been doing that for the ones I'm testing. Thanks, Steve Sybesma Last fiddled with by ssybesma on 2019-07-25 at 20:25
2019-07-26, 02:29   #2
axn

Jun 2003

538710 Posts

Quote:
 Originally Posted by ssybesma Would it be reasonable to assume that if left alone uninterrupted that this will really complete when I think it will (in about 4 months)?
No need to assume anything. Take the reported iteration time, (average it out if there is variation), multiply by the remaining iteration, and voila!, you have your remaining time projection.

2019-07-26, 05:52   #3
ssybesma

"Steve Sybesma"
May 2012
Brighton, CO USA

89 Posts

Quote:
 Originally Posted by axn No need to assume anything. Take the reported iteration time, (average it out if there is variation), multiply by the remaining iteration, and voila!, you have your remaining time projection.

OK and I actually have a believable answer from just looking at the output of mprime for this device I named CS07:

[Work thread Jul 25 23:44] Iteration: 2882500 / 91598807 [3.14%], ms/iter: 101.684, ETA: 104d 09:50

However the webpage says it will be 593 days to go:

CS07 0 M91598807 LL LL, 3.10% 4 593 60 2021-03-10 2019-07-26 2019-07-26

Not sure why the webpage shows over 5 times more days than the ETA of mprime's output. Weird.

Last fiddled with by ssybesma on 2019-07-26 at 05:56

2019-07-26, 06:00   #4
axn

Jun 2003

10101000010112 Posts

Quote:
 Originally Posted by ssybesma Not sure why the webpage shows over 5 times more days than the ETA of mprime's output. Weird.
What are your "Hours per day" and "CPU rolling average" settings for that CPU, according to the server?

2019-07-26, 13:59   #5
ssybesma

"Steve Sybesma"
May 2012
Brighton, CO USA

5916 Posts

Quote:
 Originally Posted by axn What are your "Hours per day" and "CPU rolling average" settings for that CPU, according to the server?
I looked everywhere and didn't see that info on the server but I can tell you I run this 24 hours a day with the same high priority and level of RAM (512MB) used all the time.

The info exists in the local.txt file on my machine though.

This is what I have:

Memory=512 during 7:30-23:30 else 512
...
RollingAverage=1122

This is what I'm changing to, exiting and restarting mprime after the change to see if Estimated Completion changes on the website:

Memory=512 during 0:00-23:59 else 512
...
RollingAverage=1000

Last fiddled with by ssybesma on 2019-07-26 at 14:09

 2019-07-26, 14:13 #6 ssybesma   "Steve Sybesma" May 2012 Brighton, CO USA 10110012 Posts Went from 582 days to 652 days so I'm doing something wrong with the rolling average I guess. Maybe should be a lot higher since going down to 1,000 increased the days? Sole purpose of these devices (have 12 but 8 currently running) is to run mprime and nothing else is needed (other than my ability to remote into the device using TeamViewer since they're not connected to a KVM - wasn't able to get any other remote app to work). So I'm devoting all resources to it and I set the priority (nice) to -20. The device has 1GB of RAM and a 1GB swap file set to swappiness of 10. It has an Intel Atom Z3735F @ 1.33GHz running at 1567 MHz. Update: Setting rolling average in local.txt to the max (4,000) gets the Estimated Completion days a lot closer to what it will be (still almost 50% higher but a lot better than it was). The devices seem to progress at about .8 percent per day. Some of them I had offline for a while to rebuilt the Linux image I was using to make it more efficient. Last fiddled with by kriesel on 2019-07-26 at 19:19 Reason: (errant edit instead of quote; liberal use of back arrow to paste back to Steve's 9:43 content; Sorry for mess!)
2019-07-26, 16:56   #7
axn

Jun 2003

5,387 Posts

Quote:
 Originally Posted by ssybesma I looked everywhere and didn't see that info on the server
My Account > CPUs. Drill down to the specific machine.

2019-07-26, 19:30   #8
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

22·32·5·37 Posts

Quote:
 Originally Posted by ssybesma Went from 582 days to 652 days so I'm doing something wrong with the rolling average I guess. Maybe should be a lot higher since going down to 1,000 increased the days?
Rollingaverge as I understand it is 1000 times your system's throughput while active, divided by the throughput while active of a typical system with the same specifications. So 1125 means a system is 1/8 faster than usual; 500 means half speed. The prime95 / mprime program recomputes this ongoingly and stores it in local.txt. So your manual changes to the rollingaverage entry will be modified by future program activity.
Quote:
 Some of them I had offline for a while to rebuilt the Linux image I was using to make it more efficient.
Down time affects the program's estimated completion date of assignments in progress provided by prime95 Test, Status or the mprime menu equivalent.
A manual calculation, of time per iteration times number of iterations to go, will give an ETA assuming 100% duty cycle for the duration.
Test, Status seems to allow for the historical duty cycle being less than 100%.
If you leave rollingaverage alone, at what prime95 sets it as, and maintain high duty cycle, the two ways of estimating completion time will converge as the exponent nears completion, and be reflected in a better match between the two ways for the next exponent(s). I have a PRP DC running in prime95 on a thermally challenged laptop. To keep the system BIOS or Windows thermal protection from shutting it down, I run it throttled, and even then stop the prime95 computation sometimes to let some other compute-heaavy task proceed with less chance of thermal shutdown. So its duty cycle is maybe 1/4, probably less. The worker window estimate of ETA fluctuates from 75 to 120 days currently, based on iteration timings and iterations remaining, as in the manual calculation, but the Test, Status estimate is October 2020, more than a year away, due to duty cycle. Its rollingaverage is 704. Perhaps because it's a dual-core but I run it on a single core for thermal load reasons.

2022-05-12, 18:35   #9
mrk74

Jan 2020

22×3×7 Posts

Quote:
 Originally Posted by kriesel Rollingaverge as I understand it is 1000 times your system's throughput while active, divided by the throughput while active of a typical system with the same specifications. So 1125 means a system is 1/8 faster than usual; 500 means half speed. The prime95 / mprime program recomputes this ongoingly and stores it in local.txt. So your manual changes to the rollingaverage entry will be modified by future program activity. Down time affects the program's estimated completion date of assignments in progress provided by prime95 Test, Status or the mprime menu equivalent. A manual calculation, of time per iteration times number of iterations to go, will give an ETA assuming 100% duty cycle for the duration. Test, Status seems to allow for the historical duty cycle being less than 100%. If you leave rollingaverage alone, at what prime95 sets it as, and maintain high duty cycle, the two ways of estimating completion time will converge as the exponent nears completion, and be reflected in a better match between the two ways for the next exponent(s). I have a PRP DC running in prime95 on a thermally challenged laptop. To keep the system BIOS or Windows thermal protection from shutting it down, I run it throttled, and even then stop the prime95 computation sometimes to let some other compute-heaavy task proceed with less chance of thermal shutdown. So its duty cycle is maybe 1/4, probably less. The worker window estimate of ETA fluctuates from 75 to 120 days currently, based on iteration timings and iterations remaining, as in the manual calculation, but the Test, Status estimate is October 2020, more than a year away, due to duty cycle. Its rollingaverage is 704. Perhaps because it's a dual-core but I run it on a single core for thermal load reasons.

Admittedly I don't understand any of the technical stuff, so having a rolling average over 100% is normal/possible?

 2022-05-12, 18:47 #10 slandrum   Jan 2021 California 1B816 Posts The estimate that's on the webpage is often wildly inaccurate, especially for your first LL or PRP tests. After several LL or PRP tests, mprime will start sending better estimates to the server (assuming you are not wildly changing things like the amount of time that mprime runs, what else you run on the machine, how long it's on each day, etc.). If you change things on the system that mprime is running on, the time estimates can go way off again.

 Similar Threads Thread Thread Starter Forum Replies Last Post Madpoo PrimeNet 43 2017-09-06 04:19 cimpresovec Msieve 21 2016-01-17 15:58 Mark Rose GPU to 72 5 2013-10-04 06:12 Yura Software 3 2012-11-13 19:45 Rhyled PrimeNet 31 2011-02-06 16:46

All times are UTC. The time now is 21:06.

Fri Aug 12 21:06:33 UTC 2022 up 36 days, 15:53, 3 users, load averages: 1.90, 1.59, 1.35