I will filter out the garbage when I get hoe this evening, and see what is left. I may have had those flags set, as I went through and added every flag which I thought might be helpful. The output could have filled the library of congress. :) One thing different with this time, is that after the initial filling with CPU work, a lot of GPU work came in, so when I made the test last night, there was plenty of GPU work on board. It may have responded more normally. After I ran the test, I did abort enough to get me out of high priority mode, as I was getting tired of it jumping from one unfinished work unit to another. So now the condition does not exist. I could about most of my GPU work, but from what I've read there was a shortage of GPU work when this occured, and now there is much more available. I wish I had had the forsight to capture the data as it first occured, but I was at work, and didn't realize there had been a problem until much later. Work tends to get in the way of a lot of things....
Since Einstein tasks occupy one CPU core with each GPU, both types are requested for each GPU task.
Why should BOINC client care about CPU and GPU requirements before it gets assigned a task which requires a combination of both? If CPU cache is full and GPU cache is empty, then BOINC CC should say so in sched request. It's up to scheduler to figure things out (in case of CPU cache being full it shouldn't assign GPU tasks if those also require non-trivial amount of CPU).
Since Einstein tasks occupy one CPU core with each GPU, both types are requested for each GPU task.
Why should BOINC client care about CPU and GPU requirements before it gets assigned a task which requires a combination of both? If CPU cache is full and GPU cache is empty, then BOINC CC should say so in sched request. It's up to scheduler to figure things out (in case of CPU cache being full it shouldn't assign GPU tasks if those also require non-trivial amount of CPU).
You've missed my first sentence:
Quote:
That's what I suspect:
but meanwhile, I think that my suspicion was wrong.
Quote:
I'd say that there's a bug in BOINC CC.
That's what I wanted to say, too. ;-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Same issue. One of my boxes was set to a one-day cache, but has downloaded about 20 days' worth of work. Unfortunately when SETI@Home kicks in I'll be aborting the vast majority of it. Didn't want to do this, thus the one-day cache!
As has been noted it also has a compatible CUDA GPU and wasn't downloading any GPU work before it started doing this. I kept getting "No work sent" responses. They were highlighted in red like errors. The logs don't seem to have anything relevant in them as it was probably overwritten, but I didn't know how to retrieve them.
I will filter out the garbage
)
I will filter out the garbage when I get hoe this evening, and see what is left. I may have had those flags set, as I went through and added every flag which I thought might be helpful. The output could have filled the library of congress. :) One thing different with this time, is that after the initial filling with CPU work, a lot of GPU work came in, so when I made the test last night, there was plenty of GPU work on board. It may have responded more normally. After I ran the test, I did abort enough to get me out of high priority mode, as I was getting tired of it jumping from one unfinished work unit to another. So now the condition does not exist. I could about most of my GPU work, but from what I've read there was a shortage of GPU work when this occured, and now there is much more available. I wish I had had the forsight to capture the data as it first occured, but I was at work, and didn't realize there had been a problem until much later. Work tends to get in the way of a lot of things....
Steve
Crunching as member of The GPU Users Group team.
now it started on my machine
)
now it started on my machine too.
That's what I
)
That's what I suspect:
Since Einstein tasks occupy one CPU core with each GPU, both types are requested for each GPU task.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Hi! But it's not doing
)
Hi!
But it's not doing that every time, that host is also sending requests for GPU only:
I wonder how this problem correlates with BOINC client versions.
CU
HB
I'm also having this problem.
)
I'm also having this problem. I've just aborted around 200 tasks and set E@H to get no new ones. I hope this is resolved soon!
Erik
RE: Since Einstein tasks
)
Why should BOINC client care about CPU and GPU requirements before it gets assigned a task which requires a combination of both? If CPU cache is full and GPU cache is empty, then BOINC CC should say so in sched request. It's up to scheduler to figure things out (in case of CPU cache being full it shouldn't assign GPU tasks if those also require non-trivial amount of CPU).
I'd say that there's a bug in BOINC CC.
Metod ...
RE: Hi! But it's not doing
)
Hi,
here are the logs for the GPU-only request.
RE: RE: Since Einstein
)
You've missed my first sentence:
but meanwhile, I think that my suspicion was wrong.
That's what I wanted to say, too. ;-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Same issue. One of my boxes
)
Same issue. One of my boxes was set to a one-day cache, but has downloaded about 20 days' worth of work. Unfortunately when SETI@Home kicks in I'll be aborting the vast majority of it. Didn't want to do this, thus the one-day cache!
As has been noted it also has a compatible CUDA GPU and wasn't downloading any GPU work before it started doing this. I kept getting "No work sent" responses. They were highlighted in red like errors. The logs don't seem to have anything relevant in them as it was probably overwritten, but I didn't know how to retrieve them.
http://einstein.phys.uwm.edu/host_sched_logs/3675/3675852
RE: The logs don't seem to
)
The log is kept in the BOINC data directory in the files stdoutdae.txt and stdoutdae.old.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
