[QUOTE=chalsall;293356]I wasn't singling you out -- I wrote a quick report for the G72 "admin" area which showed a dozen different individuals who had reservations beyond the new policy's range -- two (not you) with rather extremely old assignments.

But, in your case, I think it would be best if you unreserved some, and let the system process them or pass them back to PrimeNet as appropriate. If you try to reserve some more now, you'll see just how long it is expected what you have currently assigned will take you to do.

On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days.[/QUOTE]

I know I accidentally reserved 2 months worth, and the ones I have remaining will be done within the next month.

[QUOTE=chalsall;293356]On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days.[/QUOTE]

OK... This information is now being rendered on everyone's View Assignments page.

Note that the "GHz Days per Day" value is calculated differently than the simple "30 day running average" on the graphs. It takes into account the total amount of work done divided by the total number of days assignments were out (for each work type class).

Thus, the "GHz Days per Day" value will be less than the "30 day running average", particularily for the DC/LL work class where the assignments will be out for some period of time before the first result is submitted.

This is to handle situations like what Ethan encountered, where he did a large batch of TF work, and then stopped for several months before returning.

The heuristics box is another much appreciated tool for keeping track of assignments. It's nice to have statistics for all active assignments in one place.

The number formatting seems funny, leading decimals and such. I have, for example:
GHz Days per Day TF: ".150.38"
GHz Days TF: "2.192.42"
GHz Days P-1: ".711.52"

[QUOTE=James Heinrich;293399]The number formatting seems funny, leading decimals and such.[/QUOTE]

Whoops... Bad regex! Bad!

Thanks for pointing that out.

I have a stupid question! Probably already been answered, but...how hard would it be to translate p95's P-1 algorithm to a GPU? Or is a GPU incapable due to low memory access? Short answer is all thats needed, thanks!

[QUOTE=c10ck3r;293427]I have a stupid question! Probably already been answered, but...how hard would it be to translate p95's P-1 algorithm to a GPU? Or is a GPU incapable due to low memory access? Short answer is all thats needed, thanks![/QUOTE]


Not terribly hard. The "easiest" way would be to create a version of the gwnum library that uses CUDA. At first it would support only Mersenne numbers. Supporting all the k*b^n+/-c variations that the gwnum library library supports would be quite a bit harder.

I'm not sure how many temporaries could be allocated on the GPU.

Wouldn't you just use CUFFT like CUDALucas? In fact, isn't Stage 1 basically the same as the LL test, except instead of calculating Sn^2 modM, you calculate 3^E modM (where E is a large primorial), which can be done as a series of M size multiplications? In other words, all you need to do is change the input data to the FFT, but otherwise it's the same. Obviously Stage 2 is a bit harder with the memory and I'm not sure about the math, but it still seems like CUDALucas would be a good basis.

E is not a big primorial, you can see it like a product of primorials if you like, and everything times p. Of course you could use cufft to do the multiplications, but you don't get any speedup as you need to transfer the data to gpu memory everytime. I raised this question sometime ago and some guy with better knowledge (sorry, I forgot who was, but the discussion is here around) argued that transfer with global/constant/texture memories (one per grid) is 500 times slower then working with registers and shared memory (one inside of each block on the grid). In fact mfaktc is many times faster then a CPU-competitor (10, 20, 50, 100 times) because it takes advantages of working inside of these blocks (see GPU-Z: there is no memory activity with mfaktc), but CudaLucas is not more than 2-3 times faster than a CPU-competitor, because it needs to transfer data back and forth after every iteration, data is too big to be stored in shared memory (and if you look to GPU-Z, you will see memory activity to 50-60% always!).

Huh. Is there any way to get directly to the registers with CUDA? I guess so, since mfaktc appears to be capable of doing it.

Hi chalsall,

What are the new P-1 limits? I usually put 5-10 P-1 assignments per worker into the worktodo file, which obviously crosses some threshold you have established:

[code]
Sorry Bdot, but you already have too many assignments.
Since you joined the project you have done on average 8.59 GHz Days of P-1 Factoring work per day.
You currently have 41 assignments totalling 189.29 GHz Days of work assigned, or 22 days worth based on your history. The oldest is 45 days old[/code]Allowing less than 22 days of P-1 seems a little tight to me. I rebalanced some assignments so the worker which was running low can continue ... Lets see how often I bump into the limit.