Posts by Janus

1) Message boards : Server backend and mirrors : Time Machine (Message 15510)
Posted 17 Oct 2018 by Profile Janus
Post:
The files on the mirror suggest it was last updated 2009-10-04
That's almost a decade ago!

Thanks for being part of the mirror network back then - bandwidth was a real issue both for SETI@home and BURP for several years
2) Message boards : Comments and discussion : 3468 (Message 15503)
Posted 24 Sep 2018 by Profile Janus
Post:
Putting this session on hold until the new validator/stitcher code has been deployed
3) Message boards : Comments and discussion : 3470 (Message 15502)
Posted 24 Sep 2018 by Profile Janus
Post:
This session does not render consistent results. Switching to best effort validation. This will mark some results as "invalid" right now but they will also be credited in the next Payday run.
4) Message boards : Comments and discussion : 3468 (Message 15493)
Posted 20 Sep 2018 by Profile Janus
Post:
Yes, you are perfectly right, stitching of this session has been manually stopped. Normally it happens as part of the last workunit to return to the server but in this case it will take quite some time before we can proceed.
5) Message boards : Comments and discussion : 3464 (Message 15491)
Posted 19 Sep 2018 by Profile Janus
Post:
Updated the guide, thanks!
6) Message boards : Comments and discussion : 3468 (Message 15490)
Posted 19 Sep 2018 by Profile Janus
Post:
Streaming the images in a tile-based fashion is actually the way we do it normally for this exact reason.

OpenEXR and OpenEXR multilayer support is still a bit experimental since it relies on a 3rd party piece of software to load and manipulate the files rather than the native support we have for PNG. Unfortunately it has to load an entire colour layer at once in order to allow us to inspect it - at least for now - and that just takes up a whole lot of memory.

There's something wrong with how our current code disposes of the colour layers once they have been used, there is some memory that does not get released immediately. It is not a memory leak as such, but rather a question of needing to get rid of the previous layer before loading the next.
The stitcher definitely has the same issue.

Will have to dig a bit deeper.

I feel kinda bad with my scene causing so much trouble


No need to!

This is an interesting test since the validator system is currently being rewritten to better handle Cycles (and similar physical-based renderers with noisy results) and it would be nice to be able to handle large frames too - even when they are EXR.

Fun fact of the day: If you allocate enough RAM then "top", the Linux task manager, will show resource allocation in terrabytes... never seen that before.
7) Message boards : Comments and discussion : 3468 (Message 15485)
Posted 18 Sep 2018 by Profile Janus
Post:
Yeah this one is definitely a bit of a mouthful, each part is using almost 12GB of RAM while being checked. Previously we have been running multiple validators simultaneously but in this case that is a really bad idea because the server simply runs out of memory.

It is probably going to be even worse when it has to stitch it all together.

Switching the session to "best effort" mode which means some results will be marked "invalid" now but they will be fixed and credited later.

I'll have another look at this tomorrow evening.
8) Message boards : Number crunching : I want to be part of this project (Message 15477)
Posted 17 Sep 2018 by Profile Janus
Post:
That commandline looks a bit odd - did it get eaten by the forum? (also doesn't BOINC already add the threadcount to the commandline automatically with the current plan class?)

If you post a link to a completed result you can check towards the very top how many cores it was launched with. Check the number following the small "-t" parameter. That is the thread-count (in this case 32):
Executing blender.exe -noaudio --factory-startup -y -b in -P clirender.py -- -F PNG -T 16 -t 32 -f 18 0.0 0.0 1.0 1.0


Just assuming that you want to set this specifically for one app, otherwise it is much easier to set the overall CPU limit for BOINC.
9) Message boards : Comments and discussion : 3464 (Message 15476)
Posted 17 Sep 2018 by Profile Janus
Post:
Ah yes, right now EXR is only available on request (through the description).

Since we don't have anything else rendering right now I've re-queued it as EXR over here: #3468
10) Message boards : Comments and discussion : 3465 (Message 15473)
Posted 14 Sep 2018 by Profile Janus
Post:
There still seems to be an issue with the splitter being off by 1 pixel in the vertical axis when rendering with high splits. The image will unfortunately be missing 2 rows of pixels.
11) Message boards : Number crunching : What happens with site ? (Message 15472)
Posted 14 Sep 2018 by Profile Janus
Post:
The server backend crashed this morning due to running out of memory. This may be related to the very large image currently getting rendered.

The backend has been restarted and we're keeping an eye on the stitching process that caused the issue.

Fortunately BOINC keeps a small cache of work available even when the backend is down, so the rendering has not been slowed down much.
12) Message boards : Comments and discussion : 3462 (Message 15466)
Posted 27 Aug 2018 by Profile Janus
Post:
A number of issues with this session:
- Resolution selected in upload wizard not configured to the resolution in the scene. Corrected to the one used in the scene
- Splitframe rendering selected for something that only takes 1 second to render, reset to 1 (full frame rendering). Splitframe rendering is mostly used to split frames that are very heavy to render (multiple hours).
- It only takes 1 second to render these frames and hence you really should consider rendering them locally on your own machine rather than sending them to an online renderfarm - there is a lot of overhead in startup up for renders like this.

You have pretty much had these same three comments on each of your past 5 sessions (or so), is the feedback not clear enough?
13) Message boards : Problems and Help : Sorry, I leave this project !! (Message 15456)
Posted 13 Aug 2018 by Profile Janus
Post:
There's already another thread about that
14) Message boards : Problems and Help : Sorry, I leave this project !! (Message 15453)
Posted 13 Aug 2018 by Profile Janus
Post:
For the same host, same running time, credits vary from 1 to 3.

Oh it can be much much worse than that. Check out some of the graphs from the Payday announcement thread.
15) Message boards : Number crunching : Tasks are not MT (Message 15452)
Posted 13 Aug 2018 by Profile Janus
Post:
Looks like the new plan class may have been missing a flag specifically required to instruct BOINC to pass the number of threads. Really weird that it has been working somewhat for some people and not others.

I've tried cancelling the WU I had that was stuck at 1. The new one I got from the server correctly launched as a proper multithreaded unit. It may be fixed, maybe not, since it seemed a bit random. How does it look at your end?
I don't know if all downloaded WUs are stuck, so I just cancelled everything on my client to get a fresh WU.

You can check very quickly if it launched correctly or not by opening the file "stderr.txt" in the slot directory. If it has "--nthreads detected with value" (and a number) among the first 20 lines or so then it works properly, otherwise it is stuck at 1-thread.
16) Message boards : Number crunching : Estimated runtime, credits,......... (Message 15450)
Posted 13 Aug 2018 by Profile Janus
Post:
Still no any answer from Admin !!!
Nothing !!!


Well, mmonnin is correct. There is not much more to add.

CreditNew is very unreliable for WUs without an estimated GFlop workload. We sometimes run a corrective credit algorithm that brings the variance down considerably.

Two things in the pipeline to change the credit situation:
1) Run Payday more often. Currently it is mostly run when the DB is being purged for big upgrades. It would be nice to be able to run it almost immediately after a session completes, or even replace CreditNew with Payday entirely but it is difficult to do that.
2) Provide a wild guess for runtime estimation up front. This has the to potential to make things better but could also make them way worse.
17) Message boards : Number crunching : Tasks are not MT (Message 15449)
Posted 13 Aug 2018 by Profile Janus
Post:
Really having a hard time nailing this issue but was finally able to reproduce it locally today.

BOINC clearly states that the WU is multithreaded but does not pass the number of threads that the WU should be started with (this differs from client to client depending on settings) to Glue3. Glue3 defaults to 1 thread and passes 1 thread to Blender.
18) Message boards : Comments and discussion : 3456 (Message 15445)
Posted 11 Aug 2018 by Profile Janus
Post:
This renders very quickly (around 0.5 secs per frame), maybe consider rendering this kind of animation locally on your own computer to avoid the delay of submitting it to a renderfarm?
There is a lot of overhead involved both in the review process as well as when sending out the workunits to the computers of the participants who donate resources to the renderfarm. All in all it ends up taking a lot longer than 0.5 seconds.
19) Message boards : Comments and discussion : 3453 (Message 15444)
Posted 11 Aug 2018 by Profile Janus
Post:
This session contains a particle physics simulation but the simulation data was not included in the .blend-file. Unfortunately Blender stores the fluid data on the local machine.

It also renders really fast, maybe you should render this locally instead?

The session was rejected
20) Message boards : Comments and discussion : 3455 (Message 15443)
Posted 11 Aug 2018 by Profile Janus
Post:
This session contains a particle physics simulation but the simulation data was not included in the .blend-file. Unfortunately Blender stores the fluid data on the local machine.

Also it completes almost instantaneously - maybe not the best fit for rendering on a renderfarm?

The session was rejected.


Next 20