mersenneforum.org  

Go Back   mersenneforum.org > New To GIMPS? Start Here! > Information & Answers

Reply
 
Thread Tools
Old 2019-07-25, 19:33   #1
ssybesma
 
"Steve Sybesma"
May 2012
Brighton, CO USA

89 Posts
Default 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
ssybesma is offline   Reply With Quote
Old 2019-07-26, 02:29   #2
axn
 
axn's Avatar
 
Jun 2003

23×233 Posts
Default

Quote:
Originally Posted by ssybesma View Post
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.
axn is offline   Reply With Quote
Old 2019-07-26, 05:52   #3
ssybesma
 
"Steve Sybesma"
May 2012
Brighton, CO USA

89 Posts
Default

Quote:
Originally Posted by axn View Post
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
ssybesma is offline   Reply With Quote
Old 2019-07-26, 06:00   #4
axn
 
axn's Avatar
 
Jun 2003

14EF16 Posts
Default

Quote:
Originally Posted by ssybesma View Post
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?
axn is offline   Reply With Quote
Old 2019-07-26, 13:59   #5
ssybesma
 
"Steve Sybesma"
May 2012
Brighton, CO USA

1318 Posts
Default

Quote:
Originally Posted by axn View Post
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
ssybesma is offline   Reply With Quote
Old 2019-07-26, 14:13   #6
ssybesma
 
"Steve Sybesma"
May 2012
Brighton, CO USA

89 Posts
Default

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!)
ssybesma is offline   Reply With Quote
Old 2019-07-26, 16:56   #7
axn
 
axn's Avatar
 
Jun 2003

23×233 Posts
Default

Quote:
Originally Posted by ssybesma View Post
I looked everywhere and didn't see that info on the server
My Account > CPUs. Drill down to the specific machine.
axn is offline   Reply With Quote
Old 2019-07-26, 19:30   #8
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

22×1,619 Posts
Default

Quote:
Originally Posted by ssybesma View Post
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.
kriesel is online now   Reply With Quote
Old 2022-05-12, 18:35   #9
mrk74
 
Jan 2020

2×29 Posts
Default

Quote:
Originally Posted by kriesel View Post
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?
mrk74 is offline   Reply With Quote
Old 2022-05-12, 18:47   #10
slandrum
 
Jan 2021
California

17F16 Posts
Default

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.
slandrum is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Announcement: New server coming online (estimated 2017-08-11) Madpoo PrimeNet 43 2017-09-06 04:19
Estimated relations Factmsieve cimpresovec Msieve 21 2016-01-17 15:58
Question about Estimated Days to Complete Mark Rose GPU to 72 5 2013-10-04 06:12
Estimated completion dates Yura Software 3 2012-11-13 19:45
ECM Takes far longer than estimated time Rhyled PrimeNet 31 2011-02-06 16:46

All times are UTC. The time now is 22:08.


Sat May 21 22:08:55 UTC 2022 up 37 days, 20:10, 0 users, load averages: 1.62, 1.62, 1.50

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔