PRPNet analog for sieves
 

Does anyone know of any software that does something with sieves (the prime-searching kind) similar to what PRPNet does for the actual primality testing (i.e. stores the candidates on a server, distributes them, runs the testing program, displays progress, etc.)? If not, is there a market for a system like this, what features would be needed, and how should one approach writing this? My idea for this would be for this to distribute a person's own sieves across their own (heterogeneous) cluster, not necessarily a distributed sieve (as with BOINC), though I supposed it could be designed for a small distributed effort if that's desired.

[QUOTE=Happy5214;617200]Does anyone know of any software that does something with sieves (the prime-searching kind) similar to what PRPNet does for the actual primality testing (i.e. stores the candidates on a server, distributes them, runs the testing program, displays progress, etc.)? If not, is there a market for a system like this, what features would be needed, and how should one approach writing this? My idea for this would be for this to distribute a person's own sieves across their own (heterogeneous) cluster, not necessarily a distributed sieve (as with BOINC), though I supposed it could be designed for a small distributed effort if that's desired.[/QUOTE]

It's funny how I asked a question of whether or not this would have value over at PrimeGrid. They don't care much about anything that they cannot do with BOINC.

I have thought about the same question you are asking. AFAIK, there is nothing anyone can run on their home networks to do automate sieving.

I don't think it would be overly difficult to code. I would probably start with PRPNet then add a switch on the server to indicate "sieve mode" or "test mode". The configuration of the client would indicate what to do. So if the client has both sievers and testers configured it would get work based upon the mode of the server. If it has only one mode configured and not the other then it can only do that kind of work. This means that a client on ARM could do sieving and one on Intel could do testing for the same server.

To further this, the server would have a fixed sieving range that all clients would use, e.g. 1e9, 5e11, 1e14, etc. The client would need to have its own configuration for other command line switches for the sievers.

Thoughts?

I didn't know anyone would respond that quickly, so I didn't bother checking this thread until now. Oops.

[QUOTE=rogue;617202]I don't think it would be overly difficult to code. I would probably start with PRPNet then add a switch on the server to indicate "sieve mode" or "test mode". The configuration of the client would indicate what to do. So if the client has both sievers and testers configured it would get work based upon the mode of the server. If it has only one mode configured and not the other then it can only do that kind of work. This means that a client on ARM could do sieving and one on Intel could do testing for the same server.

To further this, the server would have a fixed sieving range that all clients would use, e.g. 1e9, 5e11, 1e14, etc. The client would need to have its own configuration for other command line switches for the sievers.[/QUOTE]

Questions:[list=1][*]So I'd upload the candidates to the server [i]before[/i] fully sieving them? (I'd suppose I'd have to seed it to some low level to generate an initial list.)[*]Can the server only have one mode at a time, or can both modes be enabled for different platforms?[*]How would the server divide the ranges?[*]How does it keep track of what's already been done? Is there a sieve depth field on each candidate?[*]How does the client configure the siever switches? Can that be done in the prpclient.ini, or do you put that in a shell/batch script?[*]Do we know mtsieve works on ARM yet?[/list]
To describe my workflow, I typically sieve to a target time (not depth) based on the average LLR test time in the dataset on my primary testing computer, and most of my PRPNet servers have new data regularly added to them (two of them are actually designated "miscellaneous" small and medium servers, and they're never "completely" filled).

[QUOTE=Happy5214;618572]Questions:[list=1][*]So I'd upload the candidates to the server [i]before[/i] fully sieving them? (I'd suppose I'd have to seed it to some low level to generate an initial list.)[*]Can the server only have one mode at a time, or can both modes be enabled for different platforms?[*]How would the server divide the ranges?[*]How does it keep track of what's already been done? Is there a sieve depth field on each candidate?[*]How does the client configure the siever switches? Can that be done in the prpclient.ini, or do you put that in a shell/batch script?[*]Do we know mtsieve works on ARM yet?[/list][/QUOTE]

My thoughts:

1) It might use one mode for CPU and one more for GPU, but I haven't thought about it beyond that.
2) One would configure the size of each work unit in terms of "1e9" or "1e12". All work units would have the same size.
3) Sieving would use the entire list of candidates. The client would get an updated list every xx hours per some server configuration. The server would track work similar to what is done for PRP testing with each client assigned a range of p.
4) It would have to be done via prpclient.ini, which would include GPU/CPU affinity. There are not many settings that you would have for the client. I can only think of -G and -g for GPU sieves.
5) Many of the sieves will work on ARM. You can look at the makefile to see which ones are currently supported. Unfortunately I have not finished the support for Metal (Apple Mx). Maybe that will happen this Christmas.

[QUOTE=rogue;618594]1) It might use one mode for CPU and one more for GPU, but I haven't thought about it beyond that.[/QUOTE]

Splitting up the CPU mode between x86 and ARM is another possibility.

[QUOTE=rogue;618594]2) One would configure the size of each work unit in terms of "1e9" or "1e12". All work units would have the same size.[/QUOTE]

I assume the first work unit would have to be done locally, just to get the initial list. Would it be configured in prpserver.ini?

[QUOTE=rogue;618594]3) Sieving would use the entire list of candidates. The client would get an updated list every xx hours per some server configuration. The server would track work similar to what is done for PRP testing with each client assigned a range of p.[/QUOTE]

That breaks very easily if you ever add candidates. Those would not be sieved in the ranges already marked as "done" on the server.

[QUOTE=rogue;618594]4) It would have to be done via prpclient.ini, which would include GPU/CPU affinity. There are not many settings that you would have for the client. I can only think of -G and -g for GPU sieves.[/QUOTE]

To clarify, since I've never tried to pass flags to the executables through PRPNet, prpclient.ini passes through the whole invocation?

[QUOTE=rogue;618594]5) Many of the sieves will work on ARM. You can look at the makefile to see which ones are currently supported. Unfortunately I have not finished the support for Metal (Apple Mx). Maybe that will happen this Christmas.[/QUOTE]

So someone finally got around to testing it? Nice to hear.