I just noticed the good news over on the 321 Search forums! I was already considering helping them with some crunching, but didn't get to yet, and this will be a great opportunity for me to do so! :-)

When is work scheduled to become available for it? I noticed that the app has already been inserted on the Applications page.
____________

Thanks!
____________

Work should be flowing now. Validation is off for the moment, also no frontpage status update yet.

Is there going to be a range statistics page like the ones for Cullen, Woodall, and TPS?

Not yet.

Is there going to be a range statistics page like the ones for Cullen, Woodall, and TPS?

Not yet.

Wow I'm amazed as to the progress your PrimeGrid project has taken Rytis. Now I'm just currious, is there a limit for the total amount of running projects, that PrimeGrid can handle? Also PrimeGrid is now the most significant primeproject next to Gimps and SoB (both wellestablished), but how many more projects is we likely to see before new project addition comes to an end?

Regards!

KEP

Ps. I had also a 321 WU today, it took 6 hours on my host. Are PrimeGrid going to be the only distributor of 321 work in the future or will manual reservation still be possible?

I think Primegrid is a great platform for Boinc users to do some prime searching project instead of manual "reservation".
(I think it is a wrong word)

I think Primegrid is a great platform for Boinc users to do some prime searching project instead of manual "reservation".
(I think it is a wrong word)

When I have only LLR 321 work selected in my project preferences, I get a "won't finish in time" message from the server when my client requests work. Here's a log of an example conversation from my client to the server:

I don't think that the wu from SHA-1 Collsion Search Graz is the problem. According to the on-fraction and some more factors the scheduler probably thinks that you have less then 84 hours to complete the 321 workunit (probably even less than 84 hours). As far as I know the scheduler then calculates how many operations your client can perform in this time. This should be based on the benchmark values which seem to be quite low for your host (even my 2.4GHz P4 running a standard client has values twices as high as yours). If the number of these operations is lower than what is required (or expected to be required) for the 321 workunit it won't send you work as it assumes that you won't be able to finish it in time.
I am not 100% sure that it really works like I described here but that is the way I understood it.

However, I think you should check your benchmark results and maybe force the client to do a new benchmark.
____________
Synecdoche

I don't think that the wu from SHA-1 Collsion Search Graz is the problem. According to the on-fraction and some more factors the scheduler probably thinks that you have less then 84 hours to complete the 321 workunit (probably even less than 84 hours). As far as I know the scheduler then calculates how many operations your client can perform in this time. This should be based on the benchmark values which seem to be quite low for your host (even my 2.4GHz P4 running a standard client has values twices as high as yours). If the number of these operations is lower than what is required (or expected to be required) for the 321 workunit it won't send you work as it assumes that you won't be able to finish it in time.
I am not 100% sure that it really works like I described here but that is the way I understood it.

However, I think you should check your benchmark results and maybe force the client to do a new benchmark.

I ran my benchmarks again, this time shutting down the manual LLR that was running at the same time (it was running on the other "CPU", since hyperthreaded CPU's appear as two CPU's to the operating system, but in reality only have the power of one). They came out a lot higher; I'll see if that gets me a 321 workunit now.

Edit: To eliminate the SHA-1 Collision Search workunit as a possibilty for preventing me getting a 321 workunit, I shut down BOINC, opened the client_state.xml file in a text editor, and edited the deadline value by subtracting a day's worth. Thus, when I started BOINC back up again, it immediately went into High Priority mode to finish the SHA-1 Collision Search workunit (thinking it's in much more serious deadline trouble than it really is). It's only got 15 minutes left before it will be done, so it shouldn't take long to run it to completion.
____________

Okay...now that the benchmarks have been run and came out a little higher, and now that the SHA-1 Collision Search workunit that was in potential deadline trouble is gone, I should get a 321 workunit, right? Wrong. :-( My computer still got the "won't finish in time" error when it reqeusted work from PrimeGrid.

I think I know what's holding it up now, though: A workunit from uFluids that I got a few days ago. The previous batch of uFluids workunits had a LOT of workunits that would go verrrrrrry long (actually they weren't supposed to, but a lot of them would crash then run extremely long). The current batch has much shorter (and more bug-free) workunits, but my duration correction factor is still way up in the air--naturally, BOINC estimates the new workunit at 45 hours to completion (it hasn't started yet). I'm thinking that that's probably why I'm not getting any 321 work--with an estimated completion time of 45 hours, no wonder PrimeGrid's scheduler thinks I can't handle any big workunits!

I guess it's time to do some more messing with the deadlines. :-)
____________

I always get the wont finish in time message for any project if there is no work available for the sub project I selected.
____________

Okay, you guys have just got to see this:


I got this by setting the deadline to "500" (it was previously a very large number--I heard somewhere that in programming, dates are often stored as the number of seconds since January 1, 1970--though it appears that whatever programming language BOINC was written in stores them in relation to a date slightly earlier than that--from the date that BOINC showed, it would appear that that would be December 31, 1969, 7:00 P.M.--since that's 500 seconds before the deadline shown.) I picked 500 arbitrarily, for those wondering how I came up with it.

One thing that I found interesting is that since the deadline is so far in the past, BOINC didn't even output in the log "result such-and-such is x days overdue"--I've noticed previously it does that if a result is very long overdue (under normal circumstances, this could happen if a computer running BOINC was shut down for quite a while, then turned back on).
____________

I always get the wont finish in time message for any project if there is no work available for the sub project I selected.

I always get the wont finish in time message for any project if there is no work available for the sub project I selected.

In that case, you would probably have just gotten the "there is no work available for the applications you selected, please check your settings on the website" part; the reason why I got that in addition to the "won't finish in time" message is because other applications that weren't selected would have finished in time.

I always get the wont finish in time message for any project if there is no work available for the sub project I selected.

In that case, you would probably have just gotten the "there is no work available for the applications you selected, please check your settings on the website" part; the reason why I got that in addition to the "won't finish in time" message is because other applications that weren't selected would have finished in time.

It used to be just the no work for selected apps but now it is not. It adds in all the rest as well.

Okay, update on the won't finish in time situation: The uFluids workunit got cleaned up, and BOINC promptly asked PrimeGrid for more work. I still got the "won't finish in time" error, even though there were no workunits that could at all be construed as being in deadline trouble.

Does anyone know what could still be holding my computer up from getting 321 work?
____________

I got this by setting the deadline to "500" (it was previously a very large number--I heard somewhere that in programming, dates are often stored as the number of seconds since January 1, 1970--though it appears that whatever programming language BOINC was written in stores them in relation to a date slightly earlier than that--from the date that BOINC showed, it would appear that that would be December 31, 1969, 7:00 P.M.--since that's 500 seconds before the deadline shown.)

I got this by setting the deadline to "500" (it was previously a very large number--I heard somewhere that in programming, dates are often stored as the number of seconds since January 1, 1970--though it appears that whatever programming language BOINC was written in stores them in relation to a date slightly earlier than that--from the date that BOINC showed, it would appear that that would be December 31, 1969, 7:00 P.M.--since that's 500 seconds before the deadline shown.)

No, it should really be January 1, 1970 at 0:00. However, I think timezones are taken into account. I would guess your timezone ist UTC-5 (Would make sense for the USA)?

Well, I completed my first 321 task about an hour ago (past deadline by about a day, but I guess that's to be expected since these early 321 workunits have such short deadlines). It's been validated now, but it hasn't shown up on my "Your Account" page with the rest of the stats for the various subprojects (at the bottom of the page)--has the 321 subproject been configured to display down there yet? Or is that still on the "to-do list"?
____________

Thanks!
____________

Thanks Rytis!

Oh, and by the way, on a slightly related note...when will the 321 project be added to the stats export for the little signature graphics like the one on the right in my signature?
____________