NPLB Database

[Brucifer]

It was basically decided that that was a bit too much to handle at this point in the game as it would require some healthy infrastructure increases to handle it.

edit: plus the old thing about some people like it and some people don't, and who would stay and who wouldn't. And then also the learning curve on bringing boinc on line, or hitching a ride with one of the other projects and thus losing some freedom, etc. Bottom line was that things just weren't favorable at the point in time things were talked about.

[mdettweiler]

Originally Posted by IronBits

One recommendation was to get NPLB BOINC'd - how we do that I don't know.
It was talked about once before, but I forget what became of it.

Believe it or not, I actually tried to get a BOINC server set up inside a virtual machine a while back. It ended up failing miserably; a BOINC system is a MUCH bigger undertaking than I had ever imagined.

If we were to go that route, we'd need to be prepared for a whole heck of a lot of administrative effort. Also, from what I've observed it can often be a bit of a pain to keep all the users "happy"--a lot of BOINC crunchers could care less about being involved with what their computer is actually crunching, all they care about is the credits they get for it. Riesel Sieve BOINC is a good example of this. Quite a while back, they and PrimeGrid essentially perfected their BOINC LLR application, and the admins posted publicly in the forum that they had long passed optimal depth for their sieve and that LLR was what was needed most. However, their sieve application produced slightly more credits per workunit--in fact, the sieve work was somewhat widely known as producing quite a good payout even compared to other BOINC projects. Thus they were somewhat afraid to set up LLR as the default application, and it was left as optional in the user's preferences. So...at one point something about their 64-bit Linux sieve app went kapooey, and they had to switch all of those clients over to LLR for a month or so. Keep in mind, at this point they were so well past their optimal sieve depth that even 64-bit AMDs were much better used on LLR than on sieve. Yet, before long, the complaints started to file in on the forum: "dude, what happened to the sieve work? i hate these new llr stuff they don't give enough credits! i have a 64-bit amd and anything but sieve work is a high insult to my super-duper computer!" Okay, maybe I made up the part about the "high insult to the super-duper computer", but that's still the general idea of what was going on. No matter how many times the users were reassured that LLR was the best thing their computers could be doing at the time, they didn't care since they got more credit doing sieve.

Anyway, long story short: if we ever do decide to go BOINC, be prepared for many of the users to not be interested in an active participation in the project--all they want to do is crunch and watch their stats tick up. Granted, not all of the users are like that, but nonetheless the truly active users are a relatively small proportion of a BOINC project's membership.

Okay, end of rant. My belief is that while BOINC can be an extremely powerful tool for a project, it needs to be handled quite carefully if it's to become a help rather than a hurt. If we're not prepared to have floods of users who don't have the slightest idea of what's going on behind the scenes, and don't even care, then we'd probably be best off saving BOINC for later.

Anyway, just my $0.02.

Max

Edit: Ah, I see Bruce echoed some of these sentiments, also, in a post that showed up as I was composing this.

[IronBits]

Ok, thumbs down on the Boinc idea at this time.

[AMDave]

Hi guys.

All my boxen are belong the movers.

It is moving day today.
All my boxen going down.
They will be back up tonight but I don't have DSL at the new address yet.

This does not affect the NPLB stats DB.

Have a great day.

AMDave

[AMDave]

The stats DB has reported an error to me in the logs.
The automatic notifications were stopped due to the error state.
This is a precaution to prevent incorrect emails from being issued.
No data is being lost, please continue crunching.

I am investigating the record that caused the error to determine the exact cause.

I will reinstate the automatic notifications as soon as the issue is fixed.

[AMDave]

The issue has been diagnosed.
A processing change has been implemented.
The last 2 days records have been re-processed to ensure nothing has been missed.
Normal function is now restored.

Have a great weekend

[henryzz]

out of interest what vaguely was the problem
was it either the prpnet server or manual results that caused the problem?

[mdettweiler]

Originally Posted by henryzz

out of interest what vaguely was the problem
was it either the prpnet server or manual results that caused the problem?

It was apparently some results from the PRPnet server that appeared as duplicates to the DB due to the way PRPnet handles rejected results. (It simply puts them in the completed_tests.log file like any other result, it would seem.)

In fact, this drew our attention to another issue: when we start doublechecking ranges in the future that are already in the DB from the first time around, the DB would flag them as duplicates and ditch the results. Thus, we are working on this issue now to avoid any such problems in the future.

[AMDave]

Hi guys,

Due to the accidental loading of the GB-2000 double-check data into the first-pass stats a correction has just been applied to the stats server.

Only those who have been contributing to that server and port are affected and may see a correction to their first-pass stats.

The double-check files will be re-loaded when the the process to handle them is completed.

AMDave

[mdettweiler]

Ian,

I see three entries on both the progress table and the stats-by-user page for the users "Molly#2", "Molly#3", and "Molly#4", all on the ROLP team. Knowing that such nomenclature has previously appeared from stray machines of yours that still had internal-use names on them, I presume these are yours, also? If so, I'll aggregate them to MyDogBuster in the DB.

Max

[MyDogBuster]

I see three entries on both the progress table and the stats-by-user page for the users "Molly#2", "Molly#3", and "Molly#4", all on the ROLP team. Knowing that such nomenclature has previously appeared from stray machines of yours that still had internal-use names on them, I presume these are yours, also? If so, I'll aggregate them to MyDogBuster in the DB.

Yup, their mine. Thanks

Seeing as I have admin status on the team name stuff, is this something I can do myself in the future so you guys don't have to deal with my absentmindedness.