mersenneforum.org Dates do not coincide.
 Register FAQ Search Today's Posts Mark Forums Read

 2019-01-15, 14:39 #1 Gerard     Oct 2018 Stem, NC (USA) 32 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
2019-01-15, 16:16   #2
GP2

Sep 2003

1010000110012 Posts

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.

 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! 100111101011102 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 23×32×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.
2019-01-17, 01:00   #8

"Kieren"
Jul 2011
In My Own Galaxy!

2×3×1,693 Posts

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.

Last fiddled with by kladner on 2019-01-17 at 01:02

2019-01-17, 16:20   #9
chris2be8

Sep 2009

2·33·43 Posts

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

 Similar Threads Thread Thread Starter Forum Replies Last Post Fred PrimeNet 3 2016-02-20 08:30 wildrabbitt PrimeNet 3 2015-08-17 10:57 Yura Software 3 2012-11-13 19:45 heich1 Information & Answers 35 2011-12-02 01:12 Flatlander Twin Prime Search 12 2011-11-17 09:40

All times are UTC. The time now is 04:26.

Mon May 16 04:26:50 UTC 2022 up 32 days, 2:28, 0 users, load averages: 2.50, 2.83, 2.80