Eric J KorpelaVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 15 Mar 05
Posts: 952
Credit: 6,130,739
RAC: 8,770
I've canceled all the old results and built about 10,000 in an initial testing pool. A CUDA 2.2 version should be released shortly. Your computer may get more than one version until it decided which version is fastest on your computer.
____________
Eric - quick double-check, please.
I'm not seeing any sign that I was offered cufft32_42_9.dll with my app download.
I was offered cudart32_42_9.dll, as I should have been (as well) - I have both files, so the test will continue, but please check the app_version (as I will, now).
EDIT panic over - properly specified in client_state.xml, just couldn't find it in the event log or downloads.
OK, first result is back: 11195641.
Looks like a clean run, stderr is as expected. Sorry about the false alarm earlier.
Eric J KorpelaVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 15 Mar 05
Posts: 952
Credit: 6,130,739
RAC: 8,770
Thanks! No problem. SETI is all about false alarms.
____________
I just turned on fetch for beta with my GTX-670, will see how the work goes with the same configs that I run on main with x41z.
I have received both 32 & 42 work.
Linux, please! No Astropulse, no Seti@home... :-(
Eric J KorpelaVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 15 Mar 05
Posts: 952
Credit: 6,130,739
RAC: 8,770
You aren't getting any work for linux? Or you are asking for a linux CUDA version?
____________
Linux, please! No Astropulse, no Seti@home... :-(
If you are after a Linux Cuda app, Lunatics has had one available since December last year, If you don't help out and run it and provide feedback then it won't get updated, and be available for Seti Beta to run,
Hopefully getting the x41z Linux app running will be a lot easier than with the Astropulse app.
Claggy
I'm already running x41g in main Seti. I don't know if I can run it here (with S@H v7), because this project's goal is to test stock apps. And I'd like to see an Astropulse GPU app for Linux...
I've canceled all the old results and built about 10,000 in an initial testing pool.
I set Seti main to NNT yesterday in preparation for the cuda release but AFAIKT I've got around 3 days worth of shorties that are gonna want to run in High Priority. Which brings me to my question:
How much of a hurry are you guys in to get this batch of 10,000 tasks back? Should I manually suspend suspend Seti main to get Beta started or should I leave it up to Boinc to decide and let it do it's thing?
I would suggest that we possibly need to distribute the 10,000 tasks over a reasonably wide range of hosts and cards. I've only got one machine active on Beta at the moment, but it's my GTX 670 and there's a danger it'll hoover up everything available and create a monoculture: I'll try and keep it under control, and add other - variegated - machines during the day as I wake up.
I probably could have worded that a bit better...
I'm not trying to hog Beta WUs, I've actually set Beta to NNT too. But that's mainly because in the past it has sent me up to 30 days worth of work on something like a 4day cache:) No, it's Seti main that's running in high priority and if I leave Boinc to it's own devices I'm guessing it's gonna start doing Beta in about 3-4 days. Are these 10,000 WUs a rush job?
Enjoy your coffee Richard:)
Remember that no BOINC project ever sends you work - you ask for it. How much you ask for is under your control.
Having said that, the conversion factor between 'amount requested' and 'amount allocated' is indeed sometimes a little - er, 'creative'. Particularly in the first few hours after a new application is installed.
Turn down cache, turn on <work_fetch_debug>, and be prepared to micromanage. For information, my GTX 670 is getting shorties and estimating them as 16 minutes: actual runtime is about 5 minutes, so the error is in the direction of safety this morning. YYMV.
Probably nothing but I've never seen this before so posting in case it's useful to you guys:
28/09/2012 13:08:16 SETI@home Beta Test Started download of 02jl11ad.4804.12710.3.14.98
28/09/2012 13:08:26 SETI@home Beta Test Finished download of 02jl11ad.4804.12710.3.14.98
28/09/2012 13:08:26 SETI@home Beta Test [error] MD5 check failed for 02jl11ad.4804.12710.3.14.98
28/09/2012 13:08:26 SETI@home Beta Test [error] expected 0f31e945b380f8e13afde8212579f393, got fabdfac19b0d9e94245921af37bde711
28/09/2012 13:08:26 SETI@home Beta Test [error] Checksum or signature error for 02jl11ad.4804.12710.3.14.98
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=11197247
Eric, I don't think the 'Number of tasks completed' field is being updated in the Application Details record properly.
host 59866 has 11 consecutive valid tasks for cuda42, but zero completed - I don't think they were all outliers.
So far, I've received cuda22, cuda23, and cuda32, on my Samsung with NVIDIA GeForce 315M. Let's see which of the flavours it likes best.
Nothing so far on the Super ION :-), it's busy with some AP's for the moment, and may ask for new tasks some time before this decade is over.
LOL
Eric J KorpelaVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 15 Mar 05
Posts: 952
Credit: 6,130,739
RAC: 8,770
Eric, I don't think the 'Number of tasks completed' field is being updated in the Application Details record properly.
That's one of the bugs in the credit system that David doesn't want me to fix. When a result comes back from a GPU the validator assumes the GPU works at assuming 100% efficiency, so it tries claiming 30,000 credits for a workunit that deserves 100. The validator correctly identifies this a too high a credit claim, and because of this, it doesn't update the host_app_version pfc_n, pfc_avg, and pfc_scale values. The pfc_scale value is the important one because it's used to scale that credit claim to a normal value. So the stats are never updated.
[edit]
It turns out the credit code doesn't reread the app_version table entries from the database except on start. Which is a very odd thing for a program designed to run in parallel to do. It means the validators aren't seeing updates made by other validators. Anyway, I restarted the validator and now sees the app_version scales, which should make it more likely that the "completed tasks" counter will start counting.
[/edit]
____________
I'm running Linux x41g (many thanks to LadyL), and got 4 cuda32 tasks (3 pending validation and 1 in progress). Seems that x41g is running fine for Seti v7, let's see if they validate...
I just finished a run of 60 CUDA 32 and 60 CUDA 42 WU, so far they look all normal with CUDA 42 being faster.
Eric, I don't think the 'Number of tasks completed' field is being updated in the Application Details record properly.
That's one of the bugs in the credit system that David doesn't want me to fix. When a result comes back from a GPU the validator assumes the GPU works at assuming 100% efficiency, so it tries claiming 30,000 credits for a workunit that deserves 100. The validator correctly identifies this a too high a credit claim, and because of this, it doesn't update the host_app_version pfc_n, pfc_avg, and pfc_scale values. The pfc_scale value is the important one because it's used to scale that credit claim to a normal value. So the stats are never updated.
This is beginning to get me very, very, annoyed indeed.
Two years ago, I sat in a seminar room in London as David reported to the annual BOINC workshop that CreditNew had been deployed. He didn't even pause for breath at the end of his talk, let alone call for questions or discussion.
Tonight, David is again in London, and has today presided over a hackfest to produce the next set of BOINC bugs. Sounds like a continuation of business as usual, then.
In politely turning down the offer of a subsidised place at this year's workshop (from another project, not SETI), I wrote:
So, although I have the time and resources to attend if I wish, the motivation is somewhat lacking. I just don't feel that there's a slot where enthusiastic volunteer troubleshooters, or experienced mediators between the wider user base and harassed project core staff, conveniently fit in. If, one of these fine years, we had a UserFest to re-introduce the concept of 'volunteer' to volunteer computing, perhaps followed a year later with a Bug(Fixing)Fest to blitz the problems reported by users, I would certainly be interested. But I'm not sure whether this is the year.
The project in question replied:
Hi Richard,
I think it is a good point to make to David Anderson. Based on the number of people signed up there must be plenty of slots available for this, or perhaps a portion of the day of the hackfest could be allocated to it.
If even project administrators are reaching the point where BOINC code bugs cause this level of frustration - and I've heard it on other project message boards as well - then the time has come to make a point. Anyone else willing to join me in the fine old Berkeley tradition of manning the barricades?
[edit]
It turns out the credit code doesn't reread the app_version table entries from the database except on start. Which is a very odd thing for a program designed to run in parallel to do. It means the validators aren't seeing updates made by other validators. Anyway, I restarted the validator and now sees the app_version scales, which should make it more likely that the "completed tasks" counter will start counting.
[/edit]
D'oh. I'll report some more tasks, then.