Hi Ben, I am aware this is a re-upload. I am curious to to read what you've done differently. Have you just cut down on the number of samples?

---

Have a crunching good day

Halved samples and quartered bounces.

Thanks for the information. Hope it turns out the way you want when the render is complete

---

Have a crunching good day

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

Can´t get tasks from this render job. Work generation stopped?

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

Can´t get tasks from this render job. Work generation stopped?

Assuming you are able to get work I think it depends what tasks are in the feeder at the time you request work. If I am wrong please feel free to correct me

---

Have a crunching good day

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

Can´t get tasks from this render job. Work generation stopped?

Assuming you are able to get work I think it depends what tasks are in the feeder at the time you request work. If I am wrong please feel free to correct me

Well, nearly. The problem is my notebook, which has only 12 GB memory. I didnt got work from this batch, which should work...

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

Can´t get tasks from this render job. Work generation stopped?

Assuming you are able to get work I think it depends what tasks are in the feeder at the time you request work. If I am wrong please feel free to correct me

Well, nearly. The problem is my notebook, which has only 12 GB memory. I didnt got work from this batch, which should work...

Interesting the only thing I could think of is that you've got something that is very RAM intensive running on your machine as well as BOINC

---

Have a crunching good day

She stopped going tasks. Boinc manager reports that have a lack of memory. I have enough memory.

Can´t get tasks from this render job. Work generation stopped?

Assuming you are able to get work I think it depends what tasks are in the feeder at the time you request work. If I am wrong please feel free to correct me

Well, nearly. The problem is my notebook, which has only 12 GB memory. I didnt got work from this batch, which should work...

I think it has something to do with the server work distribution policy. If I remember right smaller sessions always will be distributed first before the bigger ones come. However, priority can be changed if needed. Janus did change it sometimes in the past (especially during the Sunflower event).

---

Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg
My BOINC-Stats

What is happening? Rendering severely slowed and now no info is available?

The session was canceled? For several hours, I did not accept jobs from this session. I have little memory, unfortunately I can not render the task the user Danan.

The session was canceled?

I'm not sure what is up with the session also but as far as it appears on the server status page it obviously isn't canceled. I notice it's at the bottom now, so probably Janus did change something priority-wise, but I don't get wus from the session either, so there may be a flaw in wu generation...

---

Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg
My BOINC-Stats

Hang in there, just moving things around a bit and got distracted by some spammers yesterday. The session is not cancelled but is being re-purposed as a GPU test session because it is a perfect fit with its long rendertime and low amount of textures.
The session info page did not support a platform switch - it will be back shortly.

As credit for GPU work is still a bit sketchy (a bit of an understatement) we're putting out up to 100 units of temporary cobblestones for each workunit with more to be granted later when we have a good enough statistical basis to run Payday on it.

Depending on how much performance we're getting out of this we may be switching back to CPU rendering later in the session.

I´m waiting for GPU-work right now. ;)

I´m waiting for GPU-work right now. ;)

Hehe - Launching a new version of the GPU app very shortly
[Edit:] Aaaand the race is on!

The session is not cancelled but is being re-purposed as a GPU test session because it is a perfect fit with its long rendertime and low amount of textures.

That's a clever decision - I hope it will accelerate that session a bit, although I'm a bit sceptical because of the last GPU performances... ;-)

---

Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg
My BOINC-Stats

GPU is only for Windows? When will the GPU for Linux?

http://burp.renderfarming.net/result.php?resultid=8516381

Runtime is 391 sec, CPU-Time 375 sec. Not realy 0,412 CPU and 1 GPU. ;)

Runtimes are funny. One with 391 sec and one with 10k sec. :)

There is actually an interesting story to be told about that number. It turns out that on many systems the driver (and in extension of that, Blender) will appear to almost fully utilize a single CPU core during the entire rendering phase.
The core is actually not being utilized fully - what it is doing is mostly nothing at all - but the way that the program interfaces with the driver will make it look like the core is under 100% CPU load.

An interesting experiment:
On most systems if you pin the GPU process to that one core - so that it cannot jump away - you will be able to put somewhere around 50% to 60% additional load on the core without seeing a considerable performance loss from the GPU task (if any at all). You might think that the 100% load + an additional 60% is 160% load and would be really bad, but it turns out that the GPU driver wasn't really using those 100% for anything in particular anyways.
I believe that this has something to do with how data is transferred between Blender and the GPU through the GPU driver; all the locking and synchronization involved may sometimes require the CPU to wait a bit before continuing and this wait time shows up as load when it really isn't.

So there you have it: That is where those 0,412 originates from, and that is why you are seeing a CPU time almost identical to wall time on some systems while running GPU tasks.

With discussion in previous post in regards to CPU and GPU utilisation would you still recommend keeping the CPU core free when using the GPU to process work?

---

Have a crunching good day