[QUOTE=axn;306046]In BOINC world, when crunching multiple WU's, you launch multiple copies of the app. So BOINC-ified P95 would benefit by cutting out all multi-threaded codes, dealing with affinities, etc -- just assume that you're running one thread only.[/QUOTE]

Would it not be possible to multithread one WU then? (Not to make it harder for me or anything :razz: In any case, that is encouraging, thanks.)

[QUOTE=Dubslow;306047]Would it not be possible to multithread one WU then? [/QUOTE]

I suppose you could just do it. But I think that would mess with BOINC scheduler. Is there a BOINC-approved way of making a WU use multiple-cores? None that I'm aware of. I'll admit that I don't have any first hand experience implementing either the client or server -- only running projects. Someone more knowledgeable can correct me.

[QUOTE=axn;306054]I suppose you could just do it. But I think that would mess with BOINC scheduler. Is there a BOINC-approved way of making a WU use multiple-cores? None that I'm aware of. I'll admit that I don't have any first hand experience implementing either the client or server -- only running projects. Someone more knowledgeable can correct me.[/QUOTE]
I think there is actually a way to do it and "play nice" with BOINC's scheduler; it's been a while since I used BOINC myself, but the last time I ran it I poked around in a number of the .xml files defining the workunits and such, and there, I recall, three fields defining what resources the workunit would require: # of CPU cores, # of GPU cores, and whether the application was network-intensive. Each of the former two can be set to anything >=0, and the BOINC scheduler will plan around them appropriately--so if, for instance, a Prime95 task is labeled as using 4 cores, BOINC will leave 4 cores free for Prime95 to use however it can. Ditto for GPU tasks--you could have, for instance, an mfaktc workunit that is scheduled for 1 GPU and 1 CPU core.

Though I've never seen a project do this, I [I]think[/I] that you can have a mix of 1-threaded and multi-threaded workunits available on the server; the client reports to the server the # of cores it has available (by default this is all the cores on the system--counting hyperthreaded CPUs double, FYI--though the user can manually set the # of cores and affinities differently), so I'd guess that the server just gives out the highest-priority workunit that can fit within that client's available resources. So, for instance, if the server was loaded with a mix of 4-thread and 1-thread LL tests, and the 4-threads were set to a higher precedence, the 4-thread jobs will be handed out to an clients with 4 cores allocated to BOINC.

Possibly a more flexible way to do it would be to set up two client "applications" on the server, both of which are basically identical implementations of Prime95 but with one of them reserved for only 1-core jobs and the other for only 4-core jobs (for example). Then the user could manually select/deselect which combinations they want to be able to receive on their preferences page at the project website. This could be a handy way to implement the current variety of work choices we have now: first time LL, world record LL, 100 million digit LL, etc.; the number of cores used could be customized for each worktype, so, for instance, 100 million digit jobs could be only for 4 cores and up. Deadlines could then be set appropriately so that clients will estimate whether they can complete the job in a reasonable amount of time, thus ensuring that the big jobs only get assigned to computers that can complete them within our lifetime.

[QUOTE=mdettweiler;306097]I think there is actually a way to do it and "play nice" with BOINC's scheduler; it's been a while since I used BOINC myself, but the last time I ran it I poked around in a number of the .xml files defining the workunits and such, and there, I recall, three fields defining what resources the workunit would require: # of CPU cores, # of GPU cores, and whether the application was network-intensive. Each of the former two can be set to anything >=0, and the BOINC scheduler will plan around them appropriately--so if, for instance, a Prime95 task is labeled as using 4 cores, BOINC will leave 4 cores free for Prime95 to use however it can. Ditto for GPU tasks--you could have, for instance, an mfaktc workunit that is scheduled for 1 GPU and 1 CPU core.

Though I've never seen a project do this, I [I]think[/I] that you can have a mix of 1-threaded and multi-threaded workunits available on the server; the client reports to the server the # of cores it has available (by default this is all the cores on the system--counting hyperthreaded CPUs double, FYI--though the user can manually set the # of cores and affinities differently), so I'd guess that the server just gives out the highest-priority workunit that can fit within that client's available resources. So, for instance, if the server was loaded with a mix of 4-thread and 1-thread LL tests, and the 4-threads were set to a higher precedence, the 4-thread jobs will be handed out to an clients with 4 cores allocated to BOINC.

Possibly a more flexible way to do it would be to set up two client "applications" on the server, both of which are basically identical implementations of Prime95 but with one of them reserved for only 1-core jobs and the other for only 4-core jobs (for example). Then the user could manually select/deselect which combinations they want to be able to receive on their preferences page at the project website. This could be a handy way to implement the current variety of work choices we have now: first time LL, world record LL, 100 million digit LL, etc.; the number of cores used could be customized for each worktype, so, for instance, 100 million digit jobs could be only for 4 cores and up. Deadlines could then be set appropriately so that clients will estimate whether they can complete the job in a reasonable amount of time, thus ensuring that the big jobs only get assigned to computers that can complete them within our lifetime.[/QUOTE]

Interesting, interesting. That reminded me that BOINCing Prime95 would also mean tossing the hyperthread detection package.

[QUOTE=Dubslow;306099]That reminded me that BOINCing Prime95 would also mean tossing the hyperthread detection package.[/QUOTE]

Quite probably. Let's be honest -- we're a little spoilt by how close George codes to the metal.

On the other hand, a BOINCed Prime95 could allow intermediate uploads of LL check-point files. Given 4 MB each (an overestimate) and 100,000 tests underway at any one time (an approximate estimate), a server with 2 TB of bandwidth allotment a month could easily handle five such updates a month from every single tester.

Such servers are retail $60 USD a month. And, actually, there are many with unlimited bandwidth for that price.

[QUOTE=chalsall;306102]Quite probably. Let's be honest -- we're a little spoilt by how close George codes to the metal.

On the other hand, a BOINCed Prime95 could allow intermediate uploads of LL check-point files. Given 4 MB each (an overestimate) and 100,000 tests underway at any one time (an approximate estimate), a server with 2 TB of bandwidth allotment a month could easily handle five such updates a month from every single tester.

Such servers are retail $60 USD a month. And, actually, there are many with unlimited bandwidth for that price.[/QUOTE]
Umm... a 60M expo would be closer to 7.5 MB.
[url]http://www.wolframalpha.com/input/?i=6e7+bits[/url]

Interesting idea though.

I think we can be safe in saying that such a project would require a lot of experimentation, errors and trials to get right.

[QUOTE=Dubslow;306103]Umm... a 60M expo would be closer to 7.5 MB.
[url]http://www.wolframalpha.com/input/?i=6e7+bits[/url][/QUOTE]

You're right.

And, of course, the server would need to be able to store the data. I should add that for $60 a month you also get 500 GB of online storage and 250GB of near-line; for $80 you get 1.5 TB online.

[QUOTE=Dubslow;306103]I think we can be safe in saying that such a project would require a lot of experimentation, errors and trials to get right.[/QUOTE]

Unquestionably.

But given that BOINC is much more "mainstream", it could be a worthwhile exercise.

[QUOTE=Uncwilly;304990]Has anyone compared them to the list from GIMPS and submitted those that were missed?[/QUOTE]

It seems that nobody else worked on it (because I checked no missing factors had been uploaded), so I made the comparison and uploaded all missing factors (using a new account, Mersenne@Home Dump).

All together, there are 145,165,204 factors in factors.csv files, with 27,770,827 factors whose corresponding exponents are less than 1,000,000,000. Among these factors, 30434 of them were not in PrimeNet database; especially 79 factors were missed by GIMPS, because these exponents had not been factored before I uploaded them. For example, M[URL="http://www.mersenne.org/report_exponent/?exp_lo=81096871&exp_hi=&B1=Get+status"]81096871[/URL] has a 49.2-bit factor, but it had been TFed to [URL="http://www.unc.edu/%7Exiaoyinl/gimps/StatusPage/M81096871.html"]70 bit[/URL] without reporting any factors.

Mersen Neat Homes?
 

"Mersen Neat Home" turned out to be a weird (not even an acronym) homonym for [url]http://mersenneathome.net/[/url]

Sic transit gloria mundi!

[QUOTE=Batalov;359537]"Mersen Neat Home" turned out to be a weird (not even an acronym) homonym for [url]http://mersenneathome.net/[/url]

Sic transit gloria mundi![/QUOTE]

:rofl: