Is this of any interest to anyone? Notice CPU time vs Elapsed time

Is this task at 100%? I had it a couple of times already. You will need to reboot that machine, only stopping and re-starting BM will not do it.

I did mention it once on the alpha mailing list. Propably got lost, I did report something else in the same mail.

The good questiohn is: Which debug flags to set to get the required evidence when BM is not noticing the completion of the WU?

First I got that with GPU tasks. Lately I got it also with some LHC classic CPU tasks.

---

Christoph

Is this task at 100%?

It got stuck @48% so I paused it until I restart my laptop.

Well, on my Samsung with NVIDIA GeForce 315M (474MB) driver: 267.54 (no, I won't upgrade, it isn't broken :-) )

APR so far (not having reached 10 completed tasks yet):

(cuda22)
Average processing rate: 4.0518128038015

(cuda23)
Average processing rate: 10.58294941665

(cuda32)
Average processing rate 9.7590459010878

(cuda42)
Won't get any, before I upgrade the driver, which I of course will not do. cuda42 will be even slower than cuda32, on this card anyhow.

I just hope the server will be smart enough to know that cuda23 is what my 315M really should have.

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?

Yea, I'm seeing the same aswell (hence all teh error'd tasks on my host:
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=60354

As soon as you edit the mbcuda-6.98-*.cfg file Boinc stops recognising it as tries to re-download the files
I haven't had this happen on the Astropulse cmdline file

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?

astropulse cmdline.txt is fine. It stays the way you edit it. I've been running with edited astropulse cmdline.txt files on all my computers all the time back to AP v6 6.02.

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?

astropulse cmdline.txt is fine. It stays the way you edit it. I've been running with edited astropulse cmdline.txt files on all my computers all the time back to AP v6 6.02.

I see that the <file_info> block for 'mbcuda-6.98-cuda23.cfg' in client_state.xml has <signature_required/>, and a file signature. Sten, could you look and see if the same applies to the astropulse cmdline.txt <file_info>?

David might be right - checksums might only be checked once on download, but signatures might be checked more rigorously.

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?

astropulse cmdline.txt is fine. It stays the way you edit it. I've been running with edited astropulse cmdline.txt files on all my computers all the time back to AP v6 6.02.

I see that the <file_info> block for 'mbcuda-6.98-cuda23.cfg' in client_state.xml has <signature_required/>, and a file signature. Sten, could you look and see if the same applies to the astropulse cmdline.txt <file_info>?

David might be right - checksums might only be checked once on download, but signatures might be checked more rigorously.

I can't find as in my case "ap_cmdline_6.04_windows_intelx86__opencl_ati.txt" referenced at all in my client_state.xml file. And I'm positive that I do run AP 6.04 just now :-)

Edit: Yes I could, and it looks like this:

file_info>
<name>ap_cmdline_6.04_windows_intelx86__opencl_ati.txt</name>
<nbytes>0.000000</nbytes>
<max_nbytes>0.000000</max_nbytes>
<status>1</status>
<signature_required/>
<file_signature>
44747fc47089a055ebd6c46faebb96ecca63482553191714b4e11357f8372e4c
666c69b8c91fa74df826526a808771b9025f1a3ecdde95c11161b7cc982cf6d0
3b47cf6ba65125299cba737ce82bcf95471b7a1f0e38d6b0cd8a8781ed405a86
b705a2dbe9c621cf3d2ff09e55a799bb616cf6ec68c6caf0eca86384ab2fb74f

Ah well, another nice theory bites the dust. Thanks, Sten.

Unless the zero initial size bypasses the signature check?

My hostid=60346, with 306.23 NV driver got the cuda22, 23, 32 & 42 app.

But the WUs are not equally spread over the 4 apps in BOINC.

The slowest cuda22 app get the most WUs.

It's possible to send at work request 20 WUs to app cuda22.
The next request BOINC get 20 WUs for cuda23 app.
The next request BOINC get 20 WUs for cuda32 app.
The next request BOINC get 20 WUs for cuda42 app.
And again from the beginning.

In this case the fastest app will be detected very fast.
At least faster than now.

At least on my above mentioned host the cuda22 app get as fastest the 100 granted results.
The other 23,32 & 42, there it'll last very long, because WUs very rarely in BOINC.
In the meantime the cuda22 app calculated maybe ~ 300 or more WUs.
The cuda22 app is ~ 50 % slower than the fastest one the cuda23 app.
Wasted performance in my eyes - at least on my host.


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

---

Those results came from multiple database connection, many were obtained before your prior results had validated. It also looks like, you had exceeded the max results per day for the cuda32 and cuda42 app versions which are still relatively low becuase they don't get increased until result validate. So the only option at the time was for the scheduler to give you cuda22 and cuda23 or nothing at all.

It should resolve on its own. If you're still getting cuda22 results a week from now without busting the max results per day of the cuda32 and cuda42 version (which shouldn't be a problem if results are validating), we'll worry about it at that point.

---

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

Just to be clear, you're editing the cfg files in the projects/setiweb... directory and not the ones in the slots directory, right?

---

arkayn wrote:

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

Eric J Korpela wrote:

Just to be clear, you're editing the cfg files in the projects/setiweb... directory and not the ones in the slots directory, right?

Yes, I edit the .CFG files in the S@h-B project folder.
[EDIT: Just delete one *;* and change the priority to *high*. Save.]

Next start of BOINC new download of the .CFG files.


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

---

Well, on my Samsung with NVIDIA GeForce 315M (474MB) driver: 267.54 (no, I won't upgrade, it isn't broken :-) )

APR so far (not having reached 10 completed tasks yet):

(cuda22)
Average processing rate: 4.0518128038015

(cuda23)
Average processing rate: 10.58294941665

(cuda32)
Average processing rate 9.7590459010878

(cuda42)
Won't get any, before I upgrade the driver, which I of course will not do. cuda42 will be even slower than cuda32, on this card anyhow.

I just hope the server will be smart enough to know that cuda23 is what my 315M really should have.

No, what your 315m should have is an APR of over 25 so I'm guessing the "half speed" bug for pre-Fermi cards using stock apps is still alive and kicking and celebrating it's first birthday any day now:) It's the same bug that got me to install Lunatics... is any of this ringing a bell?

No, what your 315m should have is an APR of over 25 so I'm guessing the "half speed" bug for pre-Fermi cards using stock apps is still alive and kicking and celebrating it's first birthday any day now:) It's the same bug that got me to install Lunatics... is any of this ringing a bell?

It isn't as simple as that, and the figures are not directly comparable.

The project declares how many fpops (floating point operations) a task is expected to take. BOINC looks at how long it has taken, and works out the notional speed (APR) from those two numbers.

But - SaH v7 performs extra calculations (autocorrelations), so the work takes longer. But as yet, the extra work hasn't been incorporated into the fpops estimates declared by the project for the new tasks. So, as far as BOINC knows, we're doing the same amount of work in a longer time - i.e., we're slower.

This isn't the same bug as you remember, but there is still a possibility that it might creep back. As you can see from Sutaru's figures, the cuda22 application is roughly half the speed of the cuda23 application. That's a genuine figure (it may vary a little from card to card), and there's still a slight possibility that the cuda23 application may pick up the cuda22 component which causes the slowdown. Eric is doing his best to avoid that happening.

Well, on my Samsung with NVIDIA GeForce 315M (474MB) driver: 267.54 (no, I won't upgrade, it isn't broken :-) )

APR so far (not having reached 10 completed tasks yet):

(cuda22)
Average processing rate: 4.0518128038015

(cuda23)
Average processing rate: 10.58294941665

(cuda32)
Average processing rate 9.7590459010878

(cuda42)
Won't get any, before I upgrade the driver, which I of course will not do. cuda42 will be even slower than cuda32, on this card anyhow.

I just hope the server will be smart enough to know that cuda23 is what my 315M really should have.

No, what your 315m should have is an APR of over 25 so I'm guessing the "half speed" bug for pre-Fermi cards using stock apps is still alive and kicking and celebrating it's first birthday any day now:) It's the same bug that got me to install Lunatics... is any of this ringing a bell?

Ring a bell? Sure, but I'm still not convinced that there is any half speed bug really.

Of course the opt Lunatics version will be faster, as it always have been, much much faster, often more than twice as fast a stock, but that does not mean there is any half speed bug in the stock version, it only means that the opt version is optimized for your hardware.

An APR of over 25 is exactly what I expect from opt version, but not from stock which I run here.

Edit: Now I know what you meant by the half speed bug, and I'd say that was something totally different, and have nothing at all to do with what we see now.

[snip, chop, hack]
But as yet, the extra work hasn't been incorporated into the fpops estimates declared by the project for the new tasks.

That's the piece of the puzzle I was missing! What was it you said about theories biting dust?:)

Thanx Richard

arkayn wrote:

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

Eric J Korpela wrote:

Just to be clear, you're editing the cfg files in the projects/setiweb... directory and not the ones in the slots directory, right?

Yes, I edit the .CFG files in the S@h-B project folder.
[EDIT: Just delete one *;* and change the priority to *high*. Save.]

Next start of BOINC new download of the .CFG files.


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

That is correct for me as well.

The initial pool noted in Eric's opening post was later expanded by another 5000 or so from the same 02jl11ad tape file, ending with WU 4115961.

October has started with 2304 additional WUs (9 groups of 256) split from the 04mr12aa tape file. But they're VLAR tasks and only being sent for CPU processing.

                                                                    Joe

Damn, I though I had selected only files that were mostly non-VLAR. I'll get another file.

I was able to cancel all but about 300 of the VLARs before they went out. A new bunch of what I think are non-VLARs will be coming up as soon as we chew through some of those 285 remaining VLARs.

---