I don't use my Cuda card here only at Seti, so I can't help out.
On other note, I guess I asked for a clean up in another thread, which Joe kindly answered. And in one fell swoop, my 88 pendings got killed.
Credits don't matter to me, but I was just a little shocked.

The same problem here: postid=43849 .. and following.


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

If your pending are gone, they should have been granted credit at least.

---

I don't know if it's me, my PC, or something other ..

I could adjust the CUDA app via .CFG file.

I edit all the 4 .CFG files (306.23 NV driver installed and cuda22, 23, 32 & 42 downloaded) in Notepad and press then *save*.

I do this during BOINC is running.

The apps use the changed settings.

I exit and start again BOINC, then BOINC download again the .CFG files for to delete my edited .CFG files.

I'm the only one who see this?


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

If your pending are gone, they should have been granted credit at least.

validation errors hostid=60340

.. they were pending results - then *package canceled* through S@h-B server - no wingman - and now validation errors.


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

Same at uli's machine: validation errors hostid=55420. (the 88 *killed* results)


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

Interesting situation on my host 59866. It's a Kepler (GTX 670), so the cuda42 application is (as expected) considerably faster - these shorties take ~4:40 with cuda42, against ~8:00 with cuda32.

To start with, both cuda42 and cuda32 tasks were estimated at 16 minutes+, before the BOINC server had any real idea how fast these new apps are. I was sent predominantly cuda42, with a few cuda32 thrown in.

Then, I reached 10 'completed' cuda42 tasks. Estimates for cuda42 dropped to an accurate 4:40 - clearly the server has dialled in the right speed (APR=169) for this card/app combination.

Next, the estimate for cuda32 tasks dropped - to ~4:00. I've only got five completions for this app-ver, so my APR (99) won't be being considered yet. We must have reached an averaging point for the population as a whole - and (unsurprisingly), for the whole population cuda32 is faster: that's because Keplers like mine are still quite rare, and the older 2xx cards (and possibly Fermis) may well prefer cuda32, and will be in the majority.

So, for the time being, I'm being allocated predominantly cuda32 - correctly, according to the information the server has available and is allowed to consider. It will be interesting to watch the next stage when these cuda32 tasks complete and bring my second APR into play.

I have APR for both 32 & 42.

SETI@home v7 6.98 windows_intelx86 (cuda32)
Number of tasks completed	11
Max tasks per day	        45
Number of tasks today	        60
Consecutive valid tasks	        12
Average processing rate	        88.383584966894
Average turnaround time	         0.50 days

SETI@home v7 6.98 windows_intelx86 (cuda42)
Number of tasks completed	11
Max tasks per day	        61
Number of tasks today	        60
Consecutive valid tasks	        28
Average processing rate	       142.66998416504
Average turnaround time	         0.15 days

I still have pendings for both so this should change a little more.

Downloads seem to be almost impossible at the moment, so my system hasn't been able to run many WU's.

---

Downloads seem to be almost impossible at the moment, so my system hasn't been able to run many WU's.

I turned on http_debug and this is what I'm getting during downloads:
2012-09-29 03:09:49 PM | SETI@home Beta Test | [http] [ID#134] Received header from server: HTTP/1.0 503 Service Unavailable

---

Downloads seem to be almost impossible at the moment, so my system hasn't been able to run many WU's.

I turned on http_debug and this is what I'm getting during downloads:
2012-09-29 03:09:49 PM | SETI@home Beta Test | [http] [ID#134] Received header from server: HTTP/1.0 503 Service Unavailable

Well, of course it is unavailable. If 100 thousand computers tries to get work from the same small 100Mbit line, at the same time, what else could we expect than "HTTP/1.0 503 Service Unavailable" ?

And this will just get worse and worse, when there's GPU work on all flavors available to both Nvidia and ATI GPU's, and the cards as well as the computers are getting faster and faster all the time.

We're just going to have to get used to it. Be patient, or become a mental hospital patient :-)

Downloads seem to be almost impossible at the moment, so my system hasn't been able to run many WU's.

I turned on http_debug and this is what I'm getting during downloads:
2012-09-29 03:09:49 PM | SETI@home Beta Test | [http] [ID#134] Received header from server: HTTP/1.0 503 Service Unavailable

I got that from server 208.68.240.21

Five minutes later (when Round Robin DNS has changed over) you have a fighting chance of getting a download from 208.68.240.13

No one other saw the above mentioned with the .CFG files?

No one edit the .CFG files?

- - - - - - - - - -

On my hostid=60346 cuda23 is the fastest (also lowest CPU time usage) - as I thought.

How long it will last (how much granted results/app), that the S@h-B server send WUs only to/for the fastest app?


- Best regards! :-) - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home Main). - SETI@home needs your help. -

---

I think I read somewhere that that number is 100.

---

Christoph

...
On my hostid=60346 cuda23 is the fastest (also lowest CPU time usage) - as I thought.

How long it will last (how much granted results/app), that the S@h-B server send WUs only to/for the fastest app?
...

I guess the project is probably using the default setting for version_select_random_factor. Anything other than zero means that alternate apps will be tested sometimes. The default 0.1 means that if there's a large difference in the speed of the apps on your system, it won't check the slower ones often after the apps have APRs which the servers use.

The scenario which Richard has described where the best app has reached 10 completed and most work is being sent to a less capable app until it too gets 10 completed could go the other way, too. If the less effective app reached 10 first and had a higher APR than the estimated speed of the better app, it might take a considerable time to get the majority of work on the best app. The project setting has to consider the tradeoff between the efficiency of existing host configurations and how quickly the system adapts initially or if a user upgrades their GPU, etc.

                                                                  Joe

I've modified that portion of the code, but haven't checked it in yet. Rather than being a constant random factor of 0.1, the random factor is 1/n where n is the number of results a host has submitted for that app version. So after 10 results for a host version it's the same, but after 100 results the performance difference will need to be typically less than 1% for you to get the worse perform version.

            DB_HOST_APP_VERSION* havp = gavid_to_havp(av.id);
            double r = 1;
            long n=1;
            if (havp) {
                n=std::max((long)havp->pfc.n,(long)n);
            } 
            if (config.version_select_random_factor) {
                r += config.version_select_random_factor*rand_normal()/n;
            }

---

I can confirm that if you edit the config files, BOINC will delete them on the next startup and redownload them again.

Really? David has said that BOINC only checks the checksum on the initial download. Anyone know if that happens with the astropulse cmdline.txt file as well?

---

Same at uli's machine: validation errors hostid=55420. (the 88 *killed* results)

Oh. Don't worry about those. Once I'm sure I have the "grant_credit" script working, they'll get credit, too.

---

I've modified that portion of the code, but haven't checked it in yet. Rather than being a constant random factor of 0.1, the random factor is 1/n where n is the number of results a host has submitted for that app version. So after 10 results for a host version it's the same, but after 100 results the performance difference will need to be typically less than 1% for you to get the worse perform version.

            DB_HOST_APP_VERSION* havp = gavid_to_havp(av.id);
            double r = 1;
            long n=1;
            if (havp) {
                n=std::max((long)havp->pfc.n,(long)n);
            } 
            if (config.version_select_random_factor) {
                r += config.version_select_random_factor*rand_normal()/n;
            }

You may want to change from pfc.n to et.n since older clients which don't report an elapsed_time don't get pfc counts.

The logic is good for initial adaptation, but if someone's old GPU dies and is replaced by a new one the adaptation would be really slow. Generically, BOINC needs some modification to recognize significant changes and restart its statistics, this isn't the only case.

                                                                  Joe