Downloading and testing it right now. Anyone got the release change-notes?

Downloading and testing it right now. Anyone got the release change-notes?

There are no release notes, because at this time it is not intended as a public release, it was for a private test of scheduler issues.

It has not been tested yet.

*** Use at your own risk ***

I see it hasn't even been (officially) released to the alpha test group for testing.

Checking my email when I got home, Here is part of the quote I got from the release manager about the 6.3.15 build.

I've posted 6.3.15 to ....
Please note, the hard drive on my computer is failing. I haven’t been able to test the build to know if it will even work.

You're lucky when blindly trying it that flames didn't come out of your system. You should wait for official word before trying versions that just show up on the download page, without release notes you have no idea why they are there.

I have begun testing and will be putting the scheduler through some testing over the next couple of days.

Again, at this time, try at your own risk.

... without release notes you have no idea why they are there.

... Again, at this time, try at your own risk.

Yes, we do at our own risk ;), and we found some information about the changes here at the end of the page:

http://boinc.berkeley.edu/svn/trunk/boinc/checkin_notes

---

new between 6.3.14 and 6.3.15

- MGR: To reduce flicker, redraw only changed cells in List Control
- client: new config flags
<network_test_url>: where to go to see if network is up
<client_version_check_url>: where to get list of client versions
<client_download_url>: where to direct user to get new version
- manager: some different text for WCG version
- Taskbar icon on crash gefixed

---

Constant dripping wears away the stone. :)

I just tried 6.3.15, but the scheduler is still buggy...
After an hour or so, I had only 2 CPU tasks and one GPUGRID task running on my Vista64 Quad. So I'm back to 6.3.14 which works better than .10 on my PC.

When I reinstalled 6.3.14 I got an error message after the installation -

Internal error 2753. boincmgr.exe

A reboot fixed that...

---

pixelicious.at - my little photoblog

I just tried 6.3.15, but the scheduler is still buggy...
After an hour or so, I had only 2 CPU tasks and one GPUGRID task running on my Vista64 Quad.

Thats odd.

Do you have any cpu limit set in preferences or were you using debug option ncpus+1 ?

It may have to do with resource shares, but certainly you should have ended up with four CPU tasks, not two. I'm not real clear on how resource shares affect current clients for GPU work, but I'm under the impression CUDA tasks should always run as 'high priority' outside of resource shares to always keep GPU busy, that is if work is avaialble. Can you reproduce with debug information, that would be useful to Anderson ?

I have had no problems, but then again I have no quad core, only HT's. Scheduler has performed well (99.99%) in all my tests, including running both types of GPU work from both projects, public and alpha test. It always runs the correct number of other tasks and keeps the GPU busy as well as CPUs.

I'll try later tonight to simulate a quad core and see what happens for me.

So, it's working... It's honestly says, that my PS3GRID's WU is working using "1.00 CPUs, 1 CUDA". But I still waiting for BOINC Manager version which will allow me to run 2 CPU tasks and 1 GPU task.....

So, it's working... It's honestly says, that my PS3GRID's WU is working using "1.00 CPUs, 1 CUDA". But I still waiting for BOINC Manager version which will allow me to run 2 CPU tasks and 1 GPU task.....

This information was introduced in 6.3.14

And currently you'd loose much more performance / credits if you went for 2 CPU + 1 GPU instead of 1 + 1, especially with your GTX 260 and an X2 5200. It's an issue of the windows scheduler, which makes it really hard to fix.

MrS

---

Scanning for our furry friends since Jan 2002

...but I'm under the impression CUDA tasks should always run as 'high priority' outside of resource shares to always keep GPU busy, that is if work is avaialble.

On my 6.3.14 client this is certainly not true. I have seen CUDA tasks stopped in favour of CPU tasks (I run ncpus+1), on both quad and dual core machines when I had GPUGrid's resource share at a level that corresponds to 1 CPU core. As well, when I don't have excess amount of work from other projects cached, CUDA tasks run at "normal priority" within BOINC.

I think Keith is talking about a different high-priority mode than the deadline-realted one which BOINC tells you about. The BOINC scheduler should keep all co-processors busy before it starts to populate the CPUs with regular jobs.

MrS

---

Scanning for our furry friends since Jan 2002

I just tried 6.3.15, but the scheduler is still buggy...
After an hour or so, I had only 2 CPU tasks and one GPUGRID task running on my Vista64 Quad.

Thats odd.

Do you have any cpu limit set in preferences or were you using debug option ncpus+1 ?

It may have to do with resource shares, but certainly you should have ended up with four CPU tasks, not two. I'm not real clear on how resource shares affect current clients for GPU work, but I'm under the impression CUDA tasks should always run as 'high priority' outside of resource shares to always keep GPU busy, that is if work is avaialble. Can you reproduce with debug information, that would be useful to Anderson ?

I have had no problems, but then again I have no quad core, only HT's. Scheduler has performed well (99.99%) in all my tests, including running both types of GPU work from both projects, public and alpha test. It always runs the correct number of other tasks and keeps the GPU busy as well as CPUs.

I'll try later tonight to simulate a quad core and see what happens for me.

Nope... I haven't set a CPU limit, and I don't use ncpus+1 on the Vista machine.
Actually I don't think it has something to do with resource shares, because like you said, I should always have at least four tasks running. At the moment I have as active projects:

PS3GRID with resource share 1000
Cosmo with 500
Einstein with 400
and Rosetta with 250

active but without work are:

LHC with resource share 800
and SIMAP with 600

Which debug flags do you suggest to get usefull infos?
Are <coproc_debug>, <task> and <cpu_sched> enough?

I'll give 6.3.15 another try tomorrow evening if I have enough time...

---

pixelicious.at - my little photoblog

So, it's working... It's honestly says, that my PS3GRID's WU is working using "1.00 CPUs, 1 CUDA". But I still waiting for BOINC Manager version which will allow me to run 2 CPU tasks and 1 GPU task.....

That is this version. This is what we have been working towards the whole time. What is required is a change by the project in the work units to allow for less CPU usage, then this version will do as you want. I've tested it with the alpha test project OK so far. What you will see is "0.90 CPU, 1 CUIDA" and end up with that running and 2 other tasks on a dual core and four on a quad. At that time, users will have to remove any ncpus setting from thier config file, or else they will end up with 1 more extra cpu task.

I just tried 6.3.15, but the scheduler is still buggy...
After an hour or so, I had only 2 CPU tasks and one GPUGRID task running on my Vista64 Quad.

Thats odd.

Do you have any cpu limit set in preferences or were you using debug option ncpus+1 ?

It may have to do with resource shares, but certainly you should have ended up with four CPU tasks, not two. I'm not real clear on how resource shares affect current clients for GPU work, but I'm under the impression CUDA tasks should always run as 'high priority' outside of resource shares to always keep GPU busy, that is if work is avaialble. Can you reproduce with debug information, that would be useful to Anderson ?

I have had no problems, but then again I have no quad core, only HT's. Scheduler has performed well (99.99%) in all my tests, including running both types of GPU work from both projects, public and alpha test. It always runs the correct number of other tasks and keeps the GPU busy as well as CPUs.

I'll try later tonight to simulate a quad core and see what happens for me.

Nope... I haven't set a CPU limit, and I don't use ncpus+1 on the Vista machine.
Actually I don't think it has something to do with resource shares, because like you said, I should always have at least four tasks running. At the moment I have as active projects:

PS3GRID with resource share 1000
Cosmo with 500
Einstein with 400
and Rosetta with 250

active but without work are:

LHC with resource share 800
and SIMAP with 600

Which debug flags do you suggest to get usefull infos?
Are <coproc_debug>, <task> and <cpu_sched> enough?

I'll give 6.3.15 another try tomorrow evening if I have enough time...

I've tried to simulate a quad core. I got 3 running CPU and 1 running CUDa/CPU=1. After 1 hour 3 minutes, one of the CPU tasks went to waiting to run, and another CPU task for another project started running, which is what it is suppsoe to do. Still running, no problemo.

I would think these four debug flags would do, it will prioduce a lot of output though.
<checkpoint_debug>1</checkpoint_debug> <!-- Show when applications checkpoint. New in 5.10 -->
<coproc_debug>1</coproc_debug> <!-- Show details of coprocessor (GPU) scheduling. New in 6.3.14 -->
<cpu_sched>1</cpu_sched> <!-- CPU scheduler actions (preemption and resumption). -->
<cpu_sched_debug>1</cpu_sched_debug> <!-- Explain CPU scheduler decisions. -->
You can cut-n-paste above into your file, the comments won't hurt anything. I have a super cc_config.xml file will all the options, when I need one I jsut edit and change a zero to one, with the comments I know what they should do and I don't have to keep looking them up in the wiki.

...but I'm under the impression CUDA tasks should always run as 'high priority' outside of resource shares to always keep GPU busy, that is if work is avaialble.

On my 6.3.14 client this is certainly not true. I have seen CUDA tasks stopped in favour of CPU tasks (I run ncpus+1), on both quad and dual core machines when I had GPUGrid's resource share at a level that corresponds to 1 CPU core. As well, when I don't have excess amount of work from other projects cached, CUDA tasks run at "normal priority" within BOINC.

6.3.14 is buggy, what it does is irrelavant now as the scheduler operation was changed for 6.3.15, I'm refereing to how 6.3.15 works.
Anderson wrote:

The current scheduler will always run a GPU job if the host has one.
So these jobs are always high priority regardless of their deadline.

You just take a look! Without any magic from my side I have 3 tasks running! CPU resources distribution is as follows:

50% - Rosetta WU
30-40% - Rosetta WU
10-20% - PS3GRID WU.

So while 6.48 application is using so much of 1 core, I'm loosing some performance for CPU-related WUs, but it's already better then earlier "versions" of BOINC.

I have had no major defects show up. To me the scheduler preforms as intended.

I am giving my approval for this version to proceed into alpha testing.

Gianni will be waiting for the release of the linux version so he may test himself. After that the change should be made here on the project to go to CPU<1. He will announce when this happens.

@Stefan, below might be what you experienced. I tried for three hours yesterday, and could not duplicate your problem. The whole time I always had 4 tasks total running, this included several ending on thier own, and boinc correctly started a new one in its place.

I did find a minor defect,Today when I opened boinc manager I saw only had 1 CUDA/CPU task showing as 'Running...', but looking closely a CPU task was also running, clock ticking and it had already made 38% progress, yet the status showed as 'Ready to start'. It completed and reported and then another started and showed as Running. There seems to be a minor flaw in screen refresh.

Yes there is a minor flaw in screen refresh.

Also if project is in panic mode, It will run an extra workunit.
eg.
Quad core + GPU
Normal = 1 GPU and 3 CPU
Panic mode = 1 GPU and 4 CPU

Ok, maybe that is what happened.
I don't have much time until tomorrow evening or Friday, but I'll try it again and will report it to David if I find something else...

---

pixelicious.at - my little photoblog