Prime95 Client problem

GSV3MiaC · 2004-01-02, 01:23

Just in case nobody has previously reported it, the latest client (and several previous versions) takes absolutely no account of the 'hours per day' number that you have fed in, when calculating completion dates.

If you =change= the hours/day, ir recalculates the completion data roughly correctly. If it gets a new exponent to test, and hours/day is already set to <24, it appears to completely ignore it, and gets surprised every day when it hasn't done 24 hours work.

The result is a typical software project schedule - slips 12 hours every 24.

Cruncher · 2004-01-02, 14:46

Interesting, I hadn't noticed that (never changed that setting), but I had noticed something related, that I would think would be easy to fix.

My machine at home follows a fairly predictable cycle as far as usage goes, but because the calculation for completion dates seems to be concerned solely with the current iteration times with maybe a short average taken (correct me if I'm wrong), I'm constantly sending new completion dates to the server. I would think that if the iteration times were averaged even over as short as a two-day period more accurate completion dates could be acheived, no? Of course, the longer the period you average over, the more accurate it should become, provided the machine does follow a periodic pattern (as most machines would over time, I suspect).

I thought this might be a good way to help reduce traffic to the server, not that that's necessarily a problem. Call it a feature request, if I may be so bold.

QuintLeo · 2004-01-03, 00:23

New Completion Dates get sent at every "checkin" - by default every 28'd day, though it can be set at low as once a day .

Scott has indicated that the server loading is generally very low - I wouldn't worry about additional server load due to this.

Prime95/mprime/sprime/etc normally only sends a couple hundred bytes at most to the server a *day* - perhaps as much as a thousand if you're doing a lot of trial factoring work - for 60,000 machines (appx. current count). Realistically, most of those machines are checking in every 28 days, so the actual daily count would be more like 2000 - perhaps 3000 after accounting for folks that kick the checkin time down.

Contrast this with the distributed.net client, which by default sent 128 (appx) byte for every block, and could easily achieve 100 blocks A DAY on a typical fairly-fast machine (almost 200 for the then-fastest Athlons, almost a THOUSAND on the fastest G4's). Then factor in that d.net at it's RC5-64 peak had something on the order of 500,000 machines. THAT is a lotta server load.

8-)

Danath · 2004-01-07, 14:09

I guess the problem here is with the "RollingAverage" setting in local.ini file (which is automatically created and changed by Prime95 client). Initially it has a value of 1000. But over time it grows (in my case it constantly grows over 2000). As I know, this setting means something like "the efficiency the system has at the moment, compared to the initial feeling about this, that the client had at the beginning (when the parameter was set to 1000)"; so that 2000 means that the system is twice as efficient as the client thought it was at the beginning.

When calculating completion dates, the client uses the value of this setting. That's why when this value is (for example) 2000, the completion date is about twice shorter than it should be. Note that when you change the "Hours per day" setting the "RollingAverage" setting is reset to 1000. That's why when you change the "Hours per day" setting (you may change it, for example, from 9 to 8, then back to 9 - for just to reset the "RollingAverage" setting), the client shows a much more reasonable completion date.

I don't know why this setting permanently grows so much above the initial setting (note that this value will drop if Prime95 gets less CPU time than before); I don't make considerable changes to the configuration of my system, and Prime95 gets about the same amount of CPU time as before.

BTW, where was a thread concerning the same topic - http://www.mersenneforum.org/showthr...=&threadid=789

GSV3MiaC · 2004-01-07, 14:35

Thanks for the comments. Yes, that may be the problem - I'll go look on my '12 hours a day' machine and see what that value has crept up to.

The machine normally runs for 12-14 hours a day, but whenever it gets a new exponent the completion date seems to be calculated on the basis of 24 hours/day, even if the machine has never run 24/7 in its life.

I was sort of hoping George (or someone) would know what the bug was (or even better, fix it).

Reboot It · 2004-01-07, 14:46

One thing I have noticed with the rolling average value is that it seems unable to exceed 4000 - that appears to be a hard limit. So if you have entered less than 6 hours per day (24 * 1000 / 4000), the predictions will probably never be right if the machine is in fact left on for 24 hours every day!

Prime95 · 2004-01-07, 20:53

The expected completion date is computed from CPU speed, Cpu hours per day, and the rolling average.

Historically, there have been several bugs in accurately computing the rolling average. If you are seeing problems, I suggest looking there first. Reset the rolling average to 1000 and watch it over the next week. Does it get seriously out-of-whack?

GSV3MiaC · 2004-01-07, 22:54

Yep, 'rolling average' was 1824, old rolling average was 1630, the machine was set to 12 hours/day, and is generally on for 12-14 .. certainly not for more than 16 hours per day except once in a blue moon.

Guess the calculation for 'rolling average' is still broken.

I have caused it to reset to 1000 (by telling it 13 hours/day) and will see how it changes over time.

markhl · 2004-01-07, 23:48

Quote:

Originally posted by Prime95
Reset the rolling average to 1000 and watch it over the next week. Does it get seriously out-of-whack?

I have done that in the past, by changing the CPU hours / day. The true value is close to 16, and that is what I put in Prime95. RollingAverage always settles to a value between 1350-1450, depending on the exact load and how often it has been on recently. This is below 4000, so that is not the issue.

However the expected completion date still assumes that the PC is on 24 hours!

Prime95 · 2004-01-08, 20:39

Quote:

Originally posted by markhl
However the expected completion date still assumes that the PC is on 24 hours!

I can't reproduce that on Prime95 v23.4. I set hours to 24 and the last exponent I have is May 3. I change it to 10 and the last exponent I have is Oct 10. This is on both the Test/Status dialog and the dates reported to the server.

GSV3MiaC · 2004-01-08, 21:08

That works just dandy every time you make a change to the hours/day, but as I said (way, way, upthread) the problem arises the next time a new exponent is assigned by the server - at that point the new completion date seems to get calculated assuming 24 hours/day (unless you change the hours/day again).

Never seems to be a problem with the exponent that was being worked on when the hours/day was set/changed (or even one which was already downloaded and is in the local queue) .. =subsequently= assigned/added exponents always seem to come out wrong (looks like they are based on 24 hours/day).

fwiw, the system that I 'zeroed' to rollingaverage of 1000 yesterday has now (after 9 hours off, 12 hours on) got to a value of 1044. Interesting, but not wildly wrong (compared to the 1800+ that it was at before I zeroed it).

2004-01-02, 01:23	#1
GSV3MiaC Jan 2004 Shropshire, UK 2⁴ Posts	Prime95 Client problem Just in case nobody has previously reported it, the latest client (and several previous versions) takes absolutely no account of the 'hours per day' number that you have fed in, when calculating completion dates. If you =change= the hours/day, ir recalculates the completion data roughly correctly. If it gets a new exponent to test, and hours/day is already set to <24, it appears to completely ignore it, and gets surprised every day when it hasn't done 24 hours work. The result is a typical software project schedule - slips 12 hours every 24.

2004-01-03, 00:23	#3
QuintLeo Oct 2002 Lost in the hills of Iowa 2⁶×7 Posts	New Completion Dates get sent at every "checkin" - by default every 28'd day, though it can be set at low as once a day . Scott has indicated that the server loading is generally very low - I wouldn't worry about additional server load due to this. Prime95/mprime/sprime/etc normally only sends a couple hundred bytes at most to the server a day - perhaps as much as a thousand if you're doing a lot of trial factoring work - for 60,000 machines (appx. current count). Realistically, most of those machines are checking in every 28 days, so the actual daily count would be more like 2000 - perhaps 3000 after accounting for folks that kick the checkin time down. Contrast this with the distributed.net client, which by default sent 128 (appx) byte for every block, and could easily achieve 100 blocks A DAY on a typical fairly-fast machine (almost 200 for the then-fastest Athlons, almost a THOUSAND on the fastest G4's). Then factor in that d.net at it's RC5-64 peak had something on the order of 500,000 machines. THAT is a lotta server load. 8-) Last fiddled with by QuintLeo on 2004-01-03 at 00:26

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
64-bit lnx vs win client, Prime95.exe under Wine?	xorbe	Software	13	2009-03-18 07:22
split a prime95 queue & client installation	joblack	Information & Answers	1	2009-01-06 08:45
Prime95 client stuck?	edorajh	Software	7	2003-11-08 17:38
client problem	cameloid	Software	1	2002-10-16 14:30
Linux mprime client v22.8 problem	Prime Monster	Software	6	2002-08-29 11:14

2004-01-02, 14:46	#2
Cruncher Dec 2003 Canada 6₁₆ Posts	Interesting, I hadn't noticed that (never changed that setting), but I had noticed something related, that I would think would be easy to fix. My machine at home follows a fairly predictable cycle as far as usage goes, but because the calculation for completion dates seems to be concerned solely with the current iteration times with maybe a short average taken (correct me if I'm wrong), I'm constantly sending new completion dates to the server. I would think that if the iteration times were averaged even over as short as a two-day period more accurate completion dates could be acheived, no? Of course, the longer the period you average over, the more accurate it should become, provided the machine does follow a periodic pattern (as most machines would over time, I suspect). I thought this might be a good way to help reduce traffic to the server, not that that's necessarily a problem. Call it a feature request, if I may be so bold.

2004-01-07, 14:09	#4
Danath May 2003 Republic of Moldova 101000₂ Posts	I guess the problem here is with the "RollingAverage" setting in local.ini file (which is automatically created and changed by Prime95 client). Initially it has a value of 1000. But over time it grows (in my case it constantly grows over 2000). As I know, this setting means something like "the efficiency the system has at the moment, compared to the initial feeling about this, that the client had at the beginning (when the parameter was set to 1000)"; so that 2000 means that the system is twice as efficient as the client thought it was at the beginning. When calculating completion dates, the client uses the value of this setting. That's why when this value is (for example) 2000, the completion date is about twice shorter than it should be. Note that when you change the "Hours per day" setting the "RollingAverage" setting is reset to 1000. That's why when you change the "Hours per day" setting (you may change it, for example, from 9 to 8, then back to 9 - for just to reset the "RollingAverage" setting), the client shows a much more reasonable completion date. I don't know why this setting permanently grows so much above the initial setting (note that this value will drop if Prime95 gets less CPU time than before); I don't make considerable changes to the configuration of my system, and Prime95 gets about the same amount of CPU time as before. BTW, where was a thread concerning the same topic - http://www.mersenneforum.org/showthr...=&threadid=789

2004-01-07, 14:35	#5
GSV3MiaC Jan 2004 Shropshire, UK 16₁₀ Posts	Thanks for the comments. Yes, that may be the problem - I'll go look on my '12 hours a day' machine and see what that value has crept up to. The machine normally runs for 12-14 hours a day, but whenever it gets a new exponent the completion date seems to be calculated on the basis of 24 hours/day, even if the machine has never run 24/7 in its life. I was sort of hoping George (or someone) would know what the bug was (or even better, fix it).

2004-01-07, 14:46	#6
Reboot It Aug 2002 London, UK 135₈ Posts	One thing I have noticed with the rolling average value is that it seems unable to exceed 4000 - that appears to be a hard limit. So if you have entered less than 6 hours per day (24 * 1000 / 4000), the predictions will probably never be right if the machine is in fact left on for 24 hours every day!

2004-01-07, 20:53	#7
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2×4,127 Posts	The expected completion date is computed from CPU speed, Cpu hours per day, and the rolling average. Historically, there have been several bugs in accurately computing the rolling average. If you are seeing problems, I suggest looking there first. Reset the rolling average to 1000 and watch it over the next week. Does it get seriously out-of-whack?

2004-01-07, 22:54	#8
GSV3MiaC Jan 2004 Shropshire, UK 2⁴ Posts	Yep, 'rolling average' was 1824, old rolling average was 1630, the machine was set to 12 hours/day, and is generally on for 12-14 .. certainly not for more than 16 hours per day except once in a blue moon. Guess the calculation for 'rolling average' is still broken. I have caused it to reset to 1000 (by telling it 13 hours/day) and will see how it changes over time.

2004-01-08, 21:08	#11
GSV3MiaC Jan 2004 Shropshire, UK 2⁴ Posts	That works just dandy every time you make a change to the hours/day, but as I said (way, way, upthread) the problem arises the next time a new exponent is assigned by the server - at that point the new completion date seems to get calculated assuming 24 hours/day (unless you change the hours/day again). Never seems to be a problem with the exponent that was being worked on when the hours/day was set/changed (or even one which was already downloaded and is in the local queue) .. =subsequently= assigned/added exponents always seem to come out wrong (looks like they are based on 24 hours/day). fwiw, the system that I 'zeroed' to rollingaverage of 1000 yesterday has now (after 9 hours off, 12 hours on) got to a value of 1044. Interesting, but not wildly wrong (compared to the 1800+ that it was at before I zeroed it).