mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Hardware > GPU Computing

Reply
 
Thread Tools
Old 2011-06-06, 17:47   #947
xilman
Bamboozled!
 
xilman's Avatar
 
"π’‰Ίπ’ŒŒπ’‡·π’†·π’€­"
May 2003
Down not across

101010000111002 Posts
Default

Quote:
Originally Posted by Xyzzy View Post
This morning we discovered that two of our eight workers had transferred all of their remaining worktodo.txt contents to their results.txt files and thus were idle.

Yeah, I get that all too often. The GPUs chew through work at such a frightening rate that even though I ask for 200 assignments at a time there's still a risk of running dry.

My other system, the one with a C1060, was upgraded to Fedora 15 a few days ago, which killed the CUDA installation. Also


Until it's fixed it will be reduced to running msieve.


Paul
xilman is offline   Reply With Quote
Old 2011-06-06, 18:03   #948
Xyzzy
 
Xyzzy's Avatar
 
"Mike"
Aug 2002

2·23·179 Posts
Default

We usually reserve 500 or more assignments per core.

What we mentioned above is that the client actually moved the worktodo.txt assignments directly to the results.txt file, without doing them. (The results.txt file looked like a worktodo.txt file.)

We are not sure if you are agreeing that the client moves stuff around which causes your queue to run dry or if you are just saying that your queue is running dry because the GPU is so fast. Or both?

Xyzzy is offline   Reply With Quote
Old 2011-06-06, 19:11   #949
xilman
Bamboozled!
 
xilman's Avatar
 
"π’‰Ίπ’ŒŒπ’‡·π’†·π’€­"
May 2003
Down not across

22·5·72·11 Posts
Default

Quote:
Originally Posted by Xyzzy View Post
What we mentioned above is that the client actually moved the worktodo.txt assignments directly to the results.txt file, without doing them. (The results.txt file looked like a worktodo.txt file.)

We are not sure if you are agreeing that the client moves stuff around which causes your queue to run dry or if you are just saying that your queue is running dry because the GPU is so fast. Or both?

I misunderstood the point you made in your first quoted para. I've never seen that behaviour. My queue does indeed run dry too often because the GPU is so fast.
xilman is offline   Reply With Quote
Old 2011-06-06, 19:30   #950
Xyzzy
 
Xyzzy's Avatar
 
"Mike"
Aug 2002

2·23·179 Posts
Default

FWIW, Fish1 is investigating the possibility of a user error in this situation.

Snake1: They are going to blame me for this mess!
Xyzzy is offline   Reply With Quote
Old 2011-06-06, 21:35   #951
TheJudger
 
TheJudger's Avatar
 
"Oliver"
Mar 2005
Germany

11·101 Posts
Default

XYZZY, please let me know if it was a layer 8 problem or not.

Oliver
TheJudger is offline   Reply With Quote
Old 2011-06-06, 22:40   #952
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101Γ—103 Posts

231328 Posts
Default

Quote:
Originally Posted by xilman View Post
Yeah, I get that all too often. The GPUs chew through work at such a frightening rate that even though I ask for 200 assignments at a time there's still a risk of running dry.
</shame>Try running some of the expos in the 100M digit range up to 80 or 81 bits.<shame>

Last fiddled with by Uncwilly on 2011-06-06 at 22:46
Uncwilly is online now   Reply With Quote
Old 2011-06-07, 02:04   #953
Christenson
 
Christenson's Avatar
 
Dec 2010
Monticello

5·359 Posts
Default

Just bump up your bit level...by 1 will keep you busy, by 10 will keep you busy all year!
Christenson is offline   Reply With Quote
Old 2011-06-07, 09:41   #954
xilman
Bamboozled!
 
xilman's Avatar
 
"π’‰Ίπ’ŒŒπ’‡·π’†·π’€­"
May 2003
Down not across

1078010 Posts
Default

Quote:
Originally Posted by Uncwilly View Post
</shame>Try running some of the expos in the 100M digit range up to 80 or 81 bits.<shame>
I take what the server gives me. The organizers of the project are much more likely to know better than I what my resources should be doing.

Paul
xilman is offline   Reply With Quote
Old 2011-06-07, 12:41   #955
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101Γ—103 Posts

2·4,909 Posts
Default

Quote:
Originally Posted by xilman View Post
I take what the server gives me. The organizers of the project are much more likely to know better than I what my resources should be doing.
The PrimeNet settings don't take your GPU hardware into consideration. If you want to work on the expos that PrimeNet is handing out, then I would suggest that you do the following:
a) get an allotment from the server,
b) find out how far they are normally to be taken (http://mersenne-aries.sili.net/factorbits.php)
c) add 2 to that number,
d) replace, in your worktodo, the stop bit is that you were handed out to the new number.

That is effectively what George says is ok for GPU's and should make you worktodo last much longer.
Uncwilly is online now   Reply With Quote
Old 2011-06-07, 12:46   #956
Christenson
 
Christenson's Avatar
 
Dec 2010
Monticello

111000000112 Posts
Default

Quote:
Originally Posted by xilman View Post
I take what the server gives me. The organizers of the project are much more likely to know better than I what my resources should be doing.

Paul
I thought, to some degree, you were a project organizer....
However, IMO, the project is advanced by maximizing the number of exponents eliminated for minimum effort....even if there is some disagreement on how best to measure that effort.

I'm running about 1 in 30 successful TFs right now, taking perhaps an hour apeice on the wall clock. So for my one or two day's compute effort, I eliminate approximately one exponent. This compares quite favorably with my P-1 efforts, that take 50-60GHz days to eliminate an exponent, and significantly more than a day to get those 60GHz days of work in on a CPU.

We are working, slowly, on the automatic interactions....
Christenson is offline   Reply With Quote
Old 2011-06-07, 15:15   #957
xilman
Bamboozled!
 
xilman's Avatar
 
"π’‰Ίπ’ŒŒπ’‡·π’†·π’€­"
May 2003
Down not across

22×5×72×11 Posts
Default

Quote:
Originally Posted by Christenson View Post
ISo for my one or two day's compute effort, I eliminate approximately one exponent. This compares quite favorably with my P-1 efforts, that take 50-60GHz days to eliminate an exponent, and significantly more than a day to get those 60GHz days of work in on a CPU.
That's roughly what I'm doing, though the rate is probably closer to two factors a day.
Quote:
Originally Posted by Christenson View Post
We are working, slowly, on the automatic interactions....
Good! The sooner it arrives the better. I'd much rather prefer a fire-and-forget solution than have to remember to do all the baby sitting. If I also have to faff around editing input files to compensate for a present inadequacy of the task allocation strategy then it's quite likely that my GIMPS contribution will fall to zero. Of course, if uncwilly would rather have no contribution if favour of his desired pattern of contribution ...


Paul
xilman is offline   Reply With Quote
Reply



Similar Threads
Thread Thread Starter Forum Replies Last Post
mfakto: an OpenCL program for Mersenne prefactoring Bdot GPU Computing 1676 2021-06-30 21:23
The P-1 factoring CUDA program firejuggler GPU Computing 753 2020-12-12 18:07
gr-mfaktc: a CUDA program for generalized repunits prefactoring MrRepunit GPU Computing 32 2020-11-11 19:56
mfaktc 0.21 - CUDA runtime wrong keisentraut Software 2 2020-08-18 07:03
World's second-dumbest CUDA program fivemack Programming 112 2015-02-12 22:51

All times are UTC. The time now is 13:18.


Mon Aug 2 13:18:50 UTC 2021 up 10 days, 7:47, 0 users, load averages: 2.02, 2.03, 1.98

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