Unusual estimated completion time?

[ixfd64]

I recently installed Prime95 on a new quad-core machine, and the first four assignments were double-checks. However, one showed an estimated completion time of over a year.

Sending expected completion date for M52553161: Sep 11 2019
Sending expected completion date for M52563461: Aug 31 2020
PrimeNet success code with additional info:
WARNING: Estimated completion date is more than one year away. The assignment may be reassigned to another user after one year.
Sending expected completion date for M52580747: Sep 11 2019
Sending expected completion date for M52600741: Sep 11 2019

It went back to normal the next time Prime95 contacted the server.

Any idea what could have caused this? Could it be a Prime95 bug?

[Prime95]

Originally Posted by ixfd64

Any idea what could have caused this? Could it be a Prime95 bug?

No and yes.

[ixfd64]

Just curious, are estimated completion times based on CPU rolling average or the CPU's current performance?

If it's the latter, then it's possible there was another process that was slowing that worker down.

[Prime95]

It is based on the cpu type and speed as well as the rolling average.

Something went very wrong in the calculation of the estimated completion date. I've seen this before. I've scoured the relevant code and cannot come up with a plausible explanation.

[LaurV]

Overrunning counters?

(in our daily work, a 32-bits counter that keeps internal system ticks and it is incremented by hardware every millisecond, will overflow every ~49.7 days, so if you count the time "deltaT" spent by some function by subtracting the former stored value from the current value, and store the current value and the deltaT in unsigned variables - this is the normal process everybody does, the overflow is ignored and the result is still correct after that, because that's how the binary arithmetic in two's complement works, cycling through the register when it overflows - but then, in very unhappy cases you may end with strange timings, and special precautions need to be taken to avoid those situations; of course, this may not apply to your case, but a crazy idea may give you the right idea...)

[axn]

Originally Posted by Prime95

It is based on the cpu type and speed as well as the rolling average.

Something went very wrong in the calculation of the estimated completion date. I've seen this before. I've scoured the relevant code and cannot come up with a plausible explanation.

What happens if the system clock is updated (synced with timeserver) in the middle of the calculation? Time can jump forwards or backwards by a few seconds/minutes. I have seen this affect iteration times & ETA calculations during normal running.

[ric]

Originally Posted by Prime95

I've seen this before. I've scoured the relevant code and cannot come up with a plausible explanation.

I also notice this behavior when I add new exponents (to be registered) via worktodo.add: the initial estimate is weird (even by many months), but the first update resets the ETC to a more reasonable one.

TL;DR: as it solves spontaneously with the nearest server update, i just consider it a hiccup-estimate