GPU to 72 status... - Page 53

chalsall · 2012-02-14, 14:29

Quote:

Originally Posted by Dubslow

How hard would it be to count exponents assigned? I'm thinking that if you added that to the graph, then it'd be much easier to see 'where the wave is'.

It would be very expensive from the persepective of PrimeNet. The queries which reveal that information at the resolution Mersenne.info requires take a very long time, and put a heavy load on PrimeNet.

axn · 2012-02-14, 14:37

Eyeballing the work distribution map, I'd say that leading edge of LL is just past 59M.

Code:

  56000000 56105    | 35055     3  1731    12 19304 |   977   582 17771     1 |          47        1683 |
  57000000 55901    | 34877     1   408     2 20613 |  7348   333 12964       |           6         390 |
  58000000 55978    | 34535     1    51     4 21387 |  2303   482 11141       |        7533          49 |
  59000000 55801    | 34401           6       21394 |  1624   148    95       |       18792   737     5 |
 
  60000000 55930    | 34400           7       21523 |   240   484     4       |       18706  2090     6 |
  61000000 55555    | 33886          14       21655 |   822    21     1       |       20704   107    13 |
  62000000 55706    | 34136                   21570 |   798     1     3       |       20724    44       |

chalsall · 2012-02-14, 15:29

Quote:

Originally Posted by axn

Eyeballing the work distribution map, I'd say that leading edge of LL is just past 59M.

Actually, no. The leading edge is currently hovering around 58.3M (and is slowly backing down from there as GPU72 completes and releases work back to PrimeNet).

85 of the 95 LL assignments you see in 59M is actually Spidy. Remember that Spidy reserves the work as LL (or DC) for reasons I won't bore you with, and thus to get an accurate count of actual LL (or DC) assignments from PrimeNet you must subtract the related xxM Reserved from PrimeNet count from the GPU72 Available Assignments report.

chalsall · 2012-02-14, 18:16

Quote:

Originally Posted by nucleon

I only have 1x GTX460 doing DCTF currently. But over the course of the next 7days or so, the rest of the farm will migrate to DCTF work.

Post the CUDA4.1 upgrade of mfaktc I was doing 1800GHzdays/day (ish). (That's 1x460GTX with DCTF, the rest LLTF). 5 GMT day average based on figures taken from http://www.mersenne.org/results/

Once my whole farm is fully doing DCTF, it'll be interesting to see the GHZ-days/day output.

Indeed it will be interesting.

Because I'm sure everyone will be interested in the results, I've added a new graph to everyone's Individual reports -- GHz Days per Day.

It's still rough (or as I like to say, "Not painted yet"). For example, if someone has sparce results the X lables may skip days. And it doesn't seperate GPU from CPU work on different scales; it appears GD::Graph doesn't handle that well for cumulative bar graphs.

But, overall, it gives a good idea as to what everyone is up to on a day-to-day basis.

Dubslow · 2012-02-14, 18:17

Quote:

Originally Posted by chalsall

It would be very expensive from the persepective of PrimeNet. The queries which reveal that information at the resolution Mersenne.info requires take a very long time, and put a heavy load on PrimeNet.

Not from /assignments, but just from (say) report_exponent . If it's assigned it has a line that says "Assigned to _____ on ______" (and if it's not an LL assignment, it'll say "Assigned P-1 to ___ on ___").

chalsall · 2012-02-14, 18:28

Quote:

Originally Posted by Dubslow

Not from /assignments, but just from (say) report_exponent . If it's assigned it has a line that says "Assigned to _____ on ______" (and if it's not an LL assignment, it'll say "Assigned P-1 to ___ on ___").

Do you think I do not know that?

At the same time, do you not think I know how expensive such queries are?

Such queries involve an SQL "join" between (at least) two tables.

Dubslow · 2012-02-14, 20:06

Quote:

Originally Posted by chalsall

Such queries involve an SQL "join" between (at least) two tables.

I have no idea what that means, but point taken.

firejuggler · 2012-02-14, 20:14

each entry is table one is checked on each entry of table 2

LaurV · 2012-02-15, 04:18

@chalsall: man, the "work limit" is killing me, can't you set a "computing power" attribute to each user on gpu272 site? I can output almost 750 GHz-days per day if I only do TF/mfaktc. But I don't, my main work is LLDC and sometimes 1st time LL on the GPU, which does not give the "big credit" thing.

The point is that from time to time I do few days of LLTF. The reason is not only "credit oriented", it is also objective:

filling the GPUs with CudaLucas has the advantage that is letting the CPUs free to do other tasks (daily job, P-1, etc) but it has the disadvantage that it kills all the video power, the windozes move like in replay and there is no way to use any CAD software, so I use this mainly when my days a boring with programming jobs (or plenty of work in "text mode", word, excel, bla bla)
when my days are busy-boring with PCB or mechanical CAD work (or well, when I want few steps up in your top lists , if you insist), I prefer mfaktc. This is intensive killing the CPU resources, and P95 speed goes to half, but it has the advantage that - no matter how many copies I launch - it can not maximize the GPU. With 2 or 3 copies for each GPU, they'll be no more than 85-95% busy and the ~10% free is quite enough for my screen to move "reasonable" smooth in protel or acad.

A good compromise would be to have a CudaLucas switch to limit the GPU occupancy to 85%, but I have no idea how this can be realized practically. In that case, I won't need to "go for credit" :P

But as it is now, you see my problem, last 20 days I did CL only, almost zero GHz-days per day, and my "30-day average output power" decreased from 300 or 400 as it was on its maximum value 20 days ago, to almost zero. So, I reserved 100 assignments for my first card, it says I have work for 29 days, well, not yet 30, I can reserve another 100 for the second card, now I have "scheduled work for 58 days", based on my "30-days average output power", which is a big bullshit, and no way to reserve more. Everything I scheduled will be finished end of this week and I won't be around to reserve more, and I had to split each bunch of 100 in two bunches of 50, otherwise GPU 3 and 4 would stay empty.

So, my question was: can't you give to each user some attribute as "daily output power"? And if so, set mine to 700 or 750 GHz-days per day, so I would be able to reserve exponents for all cards for 30 days, when I have such cards available. Most of us do not put ALL the power ALL the days into GPU272 project. But occasionally, we want to do that, and we can not, because the system considers our "average output" to low for how many reservations we want.

chalsall · 2012-02-15, 04:43

Quote:

Originally Posted by LaurV

So, my question was: can't you give to each user some attribute as "daily output power"? And if so, set mine to 700 or 750 GHz-days per day, so I would be able to reserve exponents for all cards for 30 days, when I have such cards available. Most of us do not put ALL the power ALL the days into GPU272 project. But occasionally, we want to do that, and we can not, because the system considers our "average output" to low for how many reservations we want.

I currently don't have that ability designed into the system -- it's a simple heuristic based on past performance, with the option of exempting users from the limits test if I trust them enough.

I trust you (and several others) -- you are now at a trust level of three. I.E. as of five minutes ago you can allocate as much work as you'd like.

I didn't really want to have this limit sub-system at all, but a couple of users insist on trying to grab thousands of low candidates as they become available -- well beyond what they've demonstrated they can do in a month -- and only pledge to take them up one bit level.

Additionally, I'm afraid of a new user (or many new users ("Slashdot effect")) suddenly showing up on the scene and reserving thousands of candidates which then don't get any work done on them, thus wasting a month's time until they auto-expire.

I agree the heuristic is not optimal at the moment for users like you, and have been thinking about how to improve the intelegence of the algorithm. But for the time being (as it says on the reservation pages) just ask me if you wish to be exempted and I will (usually) oblidge.

LaurV · 2012-02-15, 04:59

Thank you very much for your very fast answer and action! Now let's raise a bit in the top... I was beginning to rust there... :D

2012-02-15, 04:18	#581
LaurV Romulan Interpreter Jun 2011 Thailand 22670₈ Posts	@chalsall: man, the "work limit" is killing me, can't you set a "computing power" attribute to each user on gpu272 site? I can output almost 750 GHz-days per day if I only do TF/mfaktc. But I don't, my main work is LLDC and sometimes 1st time LL on the GPU, which does not give the "big credit" thing. The point is that from time to time I do few days of LLTF. The reason is not only "credit oriented", it is also objective: filling the GPUs with CudaLucas has the advantage that is letting the CPUs free to do other tasks (daily job, P-1, etc) but it has the disadvantage that it kills all the video power, the windozes move like in replay and there is no way to use any CAD software, so I use this mainly when my days a boring with programming jobs (or plenty of work in "text mode", word, excel, bla bla) when my days are busy-boring with PCB or mechanical CAD work (or well, when I want few steps up in your top lists , if you insist), I prefer mfaktc. This is intensive killing the CPU resources, and P95 speed goes to half, but it has the advantage that - no matter how many copies I launch - it can not maximize the GPU. With 2 or 3 copies for each GPU, they'll be no more than 85-95% busy and the ~10% free is quite enough for my screen to move "reasonable" smooth in protel or acad. A good compromise would be to have a CudaLucas switch to limit the GPU occupancy to 85%, but I have no idea how this can be realized practically. In that case, I won't need to "go for credit" :P But as it is now, you see my problem, last 20 days I did CL only, almost zero GHz-days per day, and my "30-day average output power" decreased from 300 or 400 as it was on its maximum value 20 days ago, to almost zero. So, I reserved 100 assignments for my first card, it says I have work for 29 days, well, not yet 30, I can reserve another 100 for the second card, now I have "scheduled work for 58 days", based on my "30-days average output power", which is a big bullshit, and no way to reserve more. Everything I scheduled will be finished end of this week and I won't be around to reserve more, and I had to split each bunch of 100 in two bunches of 50, otherwise GPU 3 and 4 would stay empty. So, my question was: can't you give to each user some attribute as "daily output power"? And if so, set mine to 700 or 750 GHz-days per day, so I would be able to reserve exponents for all cards for 30 days, when I have such cards available. Most of us do not put ALL the power ALL the days into GPU272 project. But occasionally, we want to do that, and we can not, because the system considers our "average output" to low for how many reservations we want. Last fiddled with by LaurV on 2012-02-15 at 04:36

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Status	Primeinator	Operation Billion Digits	5	2011-12-06 02:35
62 bit status	1997rj7	Lone Mersenne Hunters	27	2008-09-29 13:52
OBD Status	Uncwilly	Operation Billion Digits	22	2005-10-25 14:05
1-2M LLR status	paulunderwood	3*2^n-1 Search	2	2005-03-13 17:03
Status of 26.0M - 26.5M	1997rj7	Lone Mersenne Hunters	25	2004-06-18 16:46

2012-02-14, 20:14	#580
firejuggler Apr 2010 Over the rainbow 2·1,303 Posts	each entry is table one is checked on each entry of table 2

2012-02-15, 04:59	#583
LaurV Romulan Interpreter Jun 2011 Thailand 2³·17·71 Posts	Thank you very much for your very fast answer and action! Now let's raise a bit in the top... I was beginning to rust there... :D