mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2004-01-02, 01:23   #1
GSV3MiaC
 
Jan 2004
Shropshire, UK

24 Posts
Default 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.
GSV3MiaC is offline   Reply With Quote
Old 2004-01-02, 14:46   #2
Cruncher
 
Dec 2003
Canada

1102 Posts
Default

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.
Cruncher is offline   Reply With Quote
Old 2004-01-03, 00:23   #3
QuintLeo
 
QuintLeo's Avatar
 
Oct 2002
Lost in the hills of Iowa

26·7 Posts
Default

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
QuintLeo is offline   Reply With Quote
Old 2004-01-07, 14:09   #4
Danath
 
Danath's Avatar
 
May 2003
Republic of Moldova

23·5 Posts
Default

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
Danath is offline   Reply With Quote
Old 2004-01-07, 14:35   #5
GSV3MiaC
 
Jan 2004
Shropshire, UK

24 Posts
Default

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).
GSV3MiaC is offline   Reply With Quote
Old 2004-01-07, 14:46   #6
Reboot It
 
Reboot It's Avatar
 
Aug 2002
London, UK

7×13 Posts
Default

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!
Reboot It is offline   Reply With Quote
Old 2004-01-07, 20:53   #7
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2·43·83 Posts
Default

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?
Prime95 is offline   Reply With Quote
Old 2004-01-07, 22:54   #8
GSV3MiaC
 
Jan 2004
Shropshire, UK

24 Posts
Default

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.
GSV3MiaC is offline   Reply With Quote
Old 2004-01-07, 23:48   #9
markhl
 
Apr 2003
California

22·23 Posts
Default

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!
markhl is offline   Reply With Quote
Old 2004-01-08, 20:39   #10
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

1BE216 Posts
Default

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.
Prime95 is offline   Reply With Quote
Old 2004-01-08, 21:08   #11
GSV3MiaC
 
Jan 2004
Shropshire, UK

24 Posts
Default

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

Thread Tools


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

All times are UTC. The time now is 19:03.

Sat Oct 24 19:03:20 UTC 2020 up 44 days, 16:14, 0 users, load averages: 1.79, 1.67, 1.77

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, 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.