Dates do not coincide.

Gerard · 2019-01-15, 14:39

I am using "Bp95v294b5.FreeBSD11-64.tar.gz" on a FreeBSD 12 amd64 machine.

Everything appears to be working correctly. However, I find this notation in the log files. The times change, but the general idea that the completion date is going to be earlier than the actual time does seem strange. Is this normal?

[Comm thread Jan 15 00:35] Updating computer information on the server
[Comm thread Jan 15 00:35] Sending interim residue 40000000 for M88304743
[Comm thread Jan 15 00:35] Sending expected completion date for M88304743: Feb 13 2019
[Comm thread Jan 15 00:35] Done communicating with server.

Thanks

GP2 · 2019-01-15, 16:16

Quote:

Originally Posted by Gerard

[Comm thread Jan 15 00:35] Updating computer information on the server
[Comm thread Jan 15 00:35] Sending interim residue 40000000 for M88304743
[Comm thread Jan 15 00:35] Sending expected completion date for M88304743: Feb 13 2019
[Comm thread Jan 15 00:35] Done communicating with server.

This is perfectly normal.

To test M88304743, the program has to do 88,304,743 iterations. It has just completed 40 million of them as of today, and expects to complete the full 88.3 million by February 13.

The program sends a status update every 10 million iterations, with an interim residue that summarizes the state of the calculations so far. In the future, when someone runs a double-check maybe ten years from now, their interim residues should match yours at every step of the way. If they don't, it will be an early sign of trouble with either your calculations or theirs.

Uncwilly · 2019-01-15, 18:47

It is not uncommon for the estimate to change or be off. If you told Prime95 that you will be running it 12 hours a day and run it more or less, your estimated time to finish will be too long or too short respectively.

kladner · 2019-01-16, 03:09

On my machine, Prime95 does not recognize that the CPU is running at 4300 MHz. It consistently reports 4008 MHz. I am pretty sure that assignments finish sooner than the estimated completion. This might relate to the POST report of 4000. If I run at 4400 MHz, the POST reports correctly. I have stayed away from that level of OC for a while, so I don't remember what P95 reported.

nomead · 2019-01-16, 04:05

And on my machine, Prime95 (sort of correctly) reports 3693 MHz, since the single core boost clock is 3.7 GHz. But when the workers start running, the processor will drop into the 3.5 GHz base clock. I guess this could skew the reported benchmarks a bit, but since the throughput benchmarks are done at 3.5 anyway, it shouldn't have much effect on projected end dates. Anyway even when the clocks are switched around this way (reported is higher than actual running speed), the assignments finish a bit sooner than projected. Some sort of safety margin, perhaps?

kladner · 2019-01-16, 04:19

The internal logic of completion dates is beyond me.

As far a boost frequency goes, I don't deal with it. I set the max multiplier to 43, with 'Sync all cores' set. Under load, it goes right to 4300 and runs there. At idle, it may drop intermittently to 800 MHz, with appropriate voltage drops.

Mark Rose · 2019-01-16, 20:44

If you look in local.txt, you'll see a RollingAverage= line, which I believe indicates how the actual speed of the system relates to the expected speed. I believe 1000 is expected speed, and above is faster and below is slower. Once the RollingAverage approaches its stable value you should see better time estimates.

kladner · 2019-01-17, 01:00

Quote:

Originally Posted by Mark Rose

If you look in local.txt, you'll see a RollingAverage= line, which I believe indicates how the actual speed of the system relates to the expected speed. I believe 1000 is expected speed, and above is faster and below is slower. Once the RollingAverage approaches its stable value you should see better time estimates.

First few lines of local.txt:

Code:

OldCpuSpeed=4008
NewCpuSpeedCount=0
NewCpuSpeed=0
RollingAverage=1273
RollingAverageIsFromV27=1

I am puzzled by the last line. Why not something more recent?
NewCpuSpeed=0 accepts no other value in my tests. I tried inserting 4300 and 1 but it always reverts to 0 on restart.
I will have to track RollingAverage for a while to see if it is stable.
Edit: My most recent DC finished this morning, 4 or 5 hours ahead of predicted.

chris2be8 · 2019-01-17, 16:20

Quote:

Originally Posted by Gerard

Everything appears to be working correctly. However, I find this notation in the log files. The times change, but the general idea that the completion date is going to be earlier than the actual time does seem strange. Is this normal?

[Comm thread Jan 15 00:35] Updating computer information on the server
[Comm thread Jan 15 00:35] Sending interim residue 40000000 for M88304743
[Comm thread Jan 15 00:35] Sending expected completion date for M88304743: Feb 13 2019
[Comm thread Jan 15 00:35] Done communicating with server.

Thanks

To check the obvious, you did notice the completion dates are different months?

Chris

2019-01-15, 14:39	#1
Gerard Oct 2018 Stem, NC (USA) 3² Posts	Dates do not coincide. I am using "Bp95v294b5.FreeBSD11-64.tar.gz" on a FreeBSD 12 amd64 machine. Everything appears to be working correctly. However, I find this notation in the log files. The times change, but the general idea that the completion date is going to be earlier than the actual time does seem strange. Is this normal? [Comm thread Jan 15 00:35] Updating computer information on the server [Comm thread Jan 15 00:35] Sending interim residue 40000000 for M88304743 [Comm thread Jan 15 00:35] Sending expected completion date for M88304743: Feb 13 2019 [Comm thread Jan 15 00:35] Done communicating with server. Thanks

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Expiration Dates	Fred	PrimeNet	3	2016-02-20 08:30
Expected completion dates for LL	wildrabbitt	PrimeNet	3	2015-08-17 10:57
Estimated completion dates	Yura	Software	3	2012-11-13 19:45
Production of Dates	heich1	Information & Answers	35	2011-12-02 01:12
Discussion about dates	Flatlander	Twin Prime Search	12	2011-11-17 09:40

2019-01-15, 18:47	#3
Uncwilly 6809 > 6502 """"""""""""""""""" Aug 2003 101×103 Posts 3·31·113 Posts	It is not uncommon for the estimate to change or be off. If you told Prime95 that you will be running it 12 hours a day and run it more or less, your estimated time to finish will be too long or too short respectively.

2019-01-16, 03:09	#4
kladner "Kieren" Jul 2011 In My Own Galaxy! 2·3·1,693 Posts	On my machine, Prime95 does not recognize that the CPU is running at 4300 MHz. It consistently reports 4008 MHz. I am pretty sure that assignments finish sooner than the estimated completion. This might relate to the POST report of 4000. If I run at 4400 MHz, the POST reports correctly. I have stayed away from that level of OC for a while, so I don't remember what P95 reported.

2019-01-16, 04:05	#5
nomead "Sam Laur" Dec 2018 Turku, Finland 317 Posts	And on my machine, Prime95 (sort of correctly) reports 3693 MHz, since the single core boost clock is 3.7 GHz. But when the workers start running, the processor will drop into the 3.5 GHz base clock. I guess this could skew the reported benchmarks a bit, but since the throughput benchmarks are done at 3.5 anyway, it shouldn't have much effect on projected end dates. Anyway even when the clocks are switched around this way (reported is higher than actual running speed), the assignments finish a bit sooner than projected. Some sort of safety margin, perhaps?

2019-01-16, 04:19	#6
kladner "Kieren" Jul 2011 In My Own Galaxy! 10011110101110₂ Posts	The internal logic of completion dates is beyond me. As far a boost frequency goes, I don't deal with it. I set the max multiplier to 43, with 'Sync all cores' set. Under load, it goes right to 4300 and runs there. At idle, it may drop intermittently to 800 MHz, with appropriate voltage drops.

2019-01-16, 20:44	#7
Mark Rose "/X\(‘-‘)/X\" Jan 2013 2³×3²×41 Posts	If you look in local.txt, you'll see a RollingAverage= line, which I believe indicates how the actual speed of the system relates to the expected speed. I believe 1000 is expected speed, and above is faster and below is slower. Once the RollingAverage approaches its stable value you should see better time estimates.