I’ve been running into issues where when I try to assign a slave to either of these lists it gets put into both lists. No matter what I do the slave is either removed or added to both lists at the same time. This has the effect of disabling the job. I’m curious if this is a known issue.
Hello James,
The way the blacklist/whitelist page works in job properties, you can set it to either white or black, depending on the radio button you select. If you leave it on whitelist, it should be fine.
Cheers,
Yeah, just a bit curious how it’s added to both lists. Do you mean that there are duplicates in both columns? Can you take a few screen shots to illustrate?
This appears to be an intermittent issue. But it has happened several times. If a slave is put into either the whitelist column or the blacklist column that slave will be assigned to BOTH columns. The same is true when you remove a slave from either column. The corruption appears to happen when I try emptying the blacklist. Deadline doesn’t seem to like it when you leave the blacklist empty once a slave has been added.
I hope that all makes sense.
So here’s a question that I think might be the root cause of these issues. So let’s say that I launch a job with a few slaves in the whitelist. But after the job is submitted i want to remove them from the whitelist so that the job is open to all slaves in it’s group. But if I try doing this Deadline complains that emptying the whitelist will mean that no slaves will be picked up by this job. Why is it set up like this? The whitelist and blacklist should only work if there are slaves in the list. If there are no slaves then the job should default to the main slave group.
Am I missing something here? Or is there some other logic to this?
Edit:
I forgot to mention that when I put all of the slaves into the whitelist it causes the bug I mentioned in the original post. I now have all slaves in both white and black lists.
Hmm, that is indeed a very confusing situation. When I switch a the Machine Limit option to Blacklist, it does as I would expect. I don’t see any evidence on my end of there being two separate lists for white and black lists, only a list that is either white, or black. To clarify, this is happening in Job Properties, then Machine Limits, right? Also, what version is this happening on? Thanks
So I’ve always assumed that there are two lists since it makes sense functionally. Oh and I’m using Deadline 6. I know that there was a point in time where I had some machines on the white list and different machines on the black list. So you’re saying that it’s just one list and I can make it either a white or a black list?
James
Hello James,
That is correct. You have a list, and you choose if it is a white or a black list. It is possible the functionality may have worked differently at one point, and we can definitely look at having such an option in the future, but this is the current functionality.
Cheers,
Well that would certainly explain the issues we’ve been having. I would recommend changing this functionality to make it two lists. Anything that gives more functionality to isolate jobs on and from certain clusters of machines the better.
Thanks for the responses.
James
Hi James,
Typically, a combination of “pools”/“groups” and if necessary, “limits” delivers a world of possibilities when it comes to controlling which machines pick up a job. Combine this with controlling the order of “pools” & “groups” for each slave instance and I have always found this delivers a lot of possible configurations. Personally, I always have found blacklist/whitelist useful for ad-hoc situations only (just run this job on my machine only, kind of thing) and as they are not as visible (read: normal workflow of controlling jobs) to users at a glance than pools/groups, it almost feels like ‘black magic’ to your users, when your trying to understand why a particular job is not rendering! I found most success by keeping the setup as simple as possible for users and in the case of new, higher spec rendernodes/machines being purchased, then a new “group” could be created which defined their spec and named accordingly - “2 x 8-core” or " min_ram_16gb" for example. (I use “pools” to define job type and not spec of machines.) I always found that the more options for limitation you give your users, the more they will use these settings to narrow their job down so much, that it is set to run on a silly number of machines and this will heavily effect the efficiency of your renderfarm.
Let me know what you think?
Mike
Hi Mike, your logic is solid in the context of a homogeneous render farm or a decent size. But I’m working on a medium size farm of about 50 machines that is very patch work in nature. I have small chunks of similar machines with plenty of user workstations scattered in there of varying degrees of strength and stability. So sometimes with light weight jobs, the farm as a whole can handle them no problem. But we frequently have jobs that are far more intensive that will trip up certain groups. Sometimes it’s not very apparent which machines will play nice with a job. Sometimes we have one machine that we know will render a job fast and we need just a short sequence rendered.
So, with all that being said, it is very beneficial to me to have the ability to finely isolate jobs on certain machines. When it comes to the groups and pools, they are great for the macro management of the farm. But I found the white/black list perfects for directing bigger jobs around obstacles on the farm. So in this sense, having more choices increases my ability to optimize.
Fair enough, understood James.
If it helps at all, I always called my groups by simple logical names so my artists ‘got it’ straight away (read: no mistakes by junior/new artists).
ie:
“min_ram_8gb”
“min_ram_16gb”
“min_ram_24gb”
“min_ram_32gb”
a slave could be in more than 1 group, but had to have at least that amount of RAM. Whilst the following 3 x remaining groups are self explanatory.
“quad_cores_only”
“workstations_only”
“renderfarm_only”
We are of like minds on this Mike. I do have my groups in a similar configuration. But I wasn’t exaggerating about the hodgepodge nature of my farm lol. If I created groups for every type of PC on the farm I’d be inundated with groups. 