Prioritise Projects


Advanced search

Message boards : Website : Prioritise Projects

Author Message
00quick00
Send message
Joined: 9 Dec 07
Posts: 21
Credit: 3,169
RAC: 0
Message 8276 - Posted: 27 Apr 2008, 8:54:46 UTC

In my opinion users should be able to pick a priority for the session they\'re submitting. Eg. Low, Medium, High and Urgent.

This way massive projects that are being continually developed and rendered for several months can take low priority since they\'re stopping smaller sessions from rendering.

The user who submitted Session 833 (Bella Italia) needed the session to be rendered and accepted in one and a half days but because the Star Trek sessions were being rendered the deadline was not met.

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 8277 - Posted: 27 Apr 2008, 11:52:30 UTC
Last modified: 27 Apr 2008, 11:57:27 UTC

Agreed. And this is in fact already possible (just by selecting either high or normal priority when uploading).
However, the current system will be changed to a system where you can use your spendable cobblestones to \"boost\" any of your running sessions. Boosted sessions get higher priority than unboosted sessions.

In the case of the 833 (Bella Italia) session I think the session contained a mistake that made it render only a single layer rather than the entire scene.
If this was intentional then the session was completely unsuitable for distributed rendering (it would only have taken around 2 hours to render on his own machine).

00quick00
Send message
Joined: 9 Dec 07
Posts: 21
Credit: 3,169
RAC: 0
Message 8279 - Posted: 28 Apr 2008, 0:13:05 UTC - in response to Message 8277.

Agreed. And this is in fact already possible (just by selecting either high or normal priority when uploading).
However, the current system will be changed to a system where you can use your spendable cobblestones to \"boost\" any of your running sessions. Boosted sessions get higher priority than unboosted sessions.

In the case of the 833 (Bella Italia) session I think the session contained a mistake that made it render only a single layer rather than the entire scene.
If this was intentional then the session was completely unsuitable for distributed rendering (it would only have taken around 2 hours to render on his own machine).


But you need to choose the correct ratio or the correct amount of cobblestones/credits to boost the priority. A 1:1 ratio would be perfect for commercial rendering if you ever accept them since most corporations have a large amount of idle computers running 24/7/365 but they usually only need something to be rendered at a certain time while

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 8281 - Posted: 28 Apr 2008, 9:44:09 UTC - in response to Message 8279.
Last modified: 28 Apr 2008, 9:59:01 UTC

But you need to choose the correct ratio or the correct amount of cobblestones/credits to boost the priority.

Short answer:
Yes and no.

Longer answer:
Sure you do, but this may change over time. Sometimes rendertime on the renderfarm is \"worth more\" than other times. For instance rendertime can pretty much be free when the renderfarm is idle.

Really long and technical answer:
Well, there will be no set ratio. It will all depend on a big set of factors (when setting the boost priority you don\'t need to know about all this but I\'ll write about it here anyways):
1) The framesplit of your session and other sessions
2) The length of your session
3) How much credit you have boosted your session with (this, together with 1 and 2, will determine the \"boost factor\")
4) How busy the renderfarm is at the time where a workunit from your session attempts to get rendered
5) How high a boosting priority the competing sessions have
6) The memory requirements of your sessions and other sessions in the renderqueue
7) The project that the session belongs to and participants\'s preferences

The influence from each factor is described below:
(1) The higher framesplit the more it will cost to get a high boost for your session. In beta the framesplit will be selected by the system, so this basically means that more complex animations will be more costly to boost (per frame). For instance rendering a 100 frame animation at BoostX1 will be just as costly as rendering a single frame split to 100 parts at BoostX1. This is also expected to take approximately the same amount of time to complete.

(2) Longer sessions will be more costly to boost than small sessions. All else equal, a 100 frame animation can reach a boost of BoostX10 for the cost that it will take a 1000 frame animation (of same complexity) to reach a boost of BoostX1.

(3) When you upload a session you will be able to set an amount of credit that you want to boost it with. Based on (1) and (2) a \"boost factor\" will be calculated for your session. Once submitted you may either add or remove credit from the boost of the session to modify the boost factor. No credit is deducted from your SCS yet.

(4,5) In the normal case the renderqueue will contain sessions that are not boosted. These will compete so that each session is given \"a fair share\" of the farm. The greater the number of sessions in the queue the less each one of them will get.
In the case where one or more boosted sessions are in the queue only the session(s) with boost factor equal to max(ceil(boost factor)) are able to compete for resources. They share the resources evenly amongst themselves but for each workunit that wins the competition they will \"pay\" SCS equal to the second highest bid or 1 (if the second highest bid is 0). In the case where multiple competitors have the same ceil(boost_factor) this will be calculated from that boost factor.

This may seem slightly confusing but is based on a modification of something called a Vickrey auction. In a real Vickrey auction all bids are sealed and bidders cannot make the same bid (the auction is then repeated among the winners). In our case the \"auction\" is an open auction and specifically allows \"milking\" of the highest bidder in order to keep boost factors relatively sane. In other words, if you give your session a boost factor of 800 you should be prepared to pay that amount of credit per workunit for it once it renders, someone may correct their running session to have a boost factor of 799 (which will then be the second highest bid) just to \"milk\" your credit. This is considered fair use of the boosting system.

Let\'s have a look at some more normal examples instead, though:
3 sessions are in the queue: 2 sessions without boost and one with BoostX5. For each workunit the boosted session will \"win the auction\" and will deduct 1SCS from the artist\'s account.

3 sessions are in the queue: 1 session without boost and 2 with BoostX3. The two boosted sessions will each get half the renderfarm but will pay 3SCS per workunit they send out.

3 sessions are in the queue: 1 session without boost, 1 session with BoostX1 and 1 with BoostX2. BoostX2 will win the auction and pay 1 SCS per workunit it sends out.

3 sessions are in the queue: all without boost. They share the renderfarm with 33% to each and pay nothing.

(6) There are situations where the winning session is a session with high memory requirements. In this case lowmem machines would not be able to help with the rendering of the auction winner session and would sit around idle until a suitable session wins. This is of course not desireable and to counter this scenario (which has occoured multiple times during alpha) the system will select additional sessions in each memory category, sort them by boost factor and ship those to low-mem hosts. A session will only have to pay SCS if there is competition in that memory category.
When sending a workunit to a host it will always attempt to send the one with the highest memory requirements first.

(7) The plan is to add support for \"preferred projects\", licenses and several other criteria that participants may use for filtering or prioritizing sessions that they want to help with. This will be solved similarly to (6) but getting ino the technical details is slightly out of scope of this post.

If you are interested in knowing more about how session priorities will be handled in the future I suggest you keep an eye on updates in the big beta rewrite thread ; more specifically the \"RenderQueueHandler\" service.

Achim
Send message
Joined: 17 May 05
Posts: 182
Credit: 2,525,844
RAC: 991
Message 8333 - Posted: 13 May 2008, 14:29:58 UTC - in response to Message 8281.


... for each workunit that wins the competition they will \"pay\" SCS equal to the second highest bid or 1 (if the second highest bid is 0). In the case where multiple competitors have the same ceil(boost_factor) this will be calculated from that boost factor.

Can you explain why the second highest?

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 8334 - Posted: 13 May 2008, 19:24:39 UTC - in response to Message 8333.
Last modified: 13 May 2008, 19:26:06 UTC


... for each workunit that wins the competition they will \"pay\" SCS equal to the second highest bid or 1 (if the second highest bid is 0). In the case where multiple competitors have the same ceil(boost_factor) this will be calculated from that boost factor.

Can you explain why the second highest?

If you use the highest bid you always pay what you bid. That means that you can bid 20credit/WU and you have to pay 20credit regardless of whether the renderfarm is otherwise not in use.
The intention is to encourage use but discourage overuse. By making people pay the second highest \"bid\" you automatically get a higher price when there is competition than when there is no competition - in other words the price reflects the demand for render power directly.

Achim
Send message
Joined: 17 May 05
Posts: 182
Credit: 2,525,844
RAC: 991
Message 8335 - Posted: 13 May 2008, 21:42:46 UTC - in response to Message 8334.

I assume zou thought about the disadvantage>
example>
1 Boost factor 10
2 boost factor 5
now first the one with factor 10 gets prio.
the session pays 5 *because the second highest is 5.
now the boost factor 10 session is finished, so both other are started.
both pay 5 again, as both are running and the second highest is again 5

=> all pay the same price, but one is faster.

Have I got that right?

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 8337 - Posted: 14 May 2008, 7:00:39 UTC - in response to Message 8335.
Last modified: 14 May 2008, 7:04:10 UTC

1 Boost factor 10
2 boost factor 5
now first the one with factor 10 gets prio.
the session pays 5 *because the second highest is 5.
now the boost factor 10 session is finished, so both other are started.
both pay 5 again, as both are running and the second highest is again 5

=> all pay the same price, but one is faster.

Have I got that right?

That\'s absolutely right. In this example a workunit on the renderfarm is \"worth\" 5 credit before BoostX10 joins the queue. The newcommer merely states that he is willing to pay up to twice that in order to keep the farm rendering for him.

I\'m working with the idea of adding a +1 somewhere in the formula when you override a priority which is lower than your own, that way the newcommer would pay 6 in this example but the two BoostX5 people would still pay 5 when they were the only ones there.
This way the rules would be like this:
- If you are in the top priority and you are alone in that class you pay the second highest bid +1
- If you are in the top priority class and you share it with someone you pay the price of that priority

The original examples modified:
3 sessions are in the queue: 1 session without boost and 2 with BoostX3. The two boosted sessions will each get half the renderfarm but will pay 3SCS per workunit they send out.

3 sessions are in the queue: 1 session without boost, 1 session with BoostX1 and 1 with BoostX2. BoostX2 will win the auction and pay 2 SCS [previously 1 SCS] per workunit it sends out.

3 sessions are in the queue: all without boost. They share the renderfarm with 33% to each and pay nothing.

Keep in mind that there will be a \"top priority\" class for each memory category (and similarly for each license and project category given that we adopt a multilicense system).

Achim
Send message
Joined: 17 May 05
Posts: 182
Credit: 2,525,844
RAC: 991
Message 8339 - Posted: 14 May 2008, 10:02:28 UTC

That would solve the problem.
I thought about half of the diff (rounding to the upper one), but the difference is only important when someone really wants to get it done, and uses very high boost factors.

I just thought it might be a game later to make things expensive.
E.g you have somone with boostfactor 10 but nothing else, you create a session with 9, which is very short(let\'s assume it passes somehow the check is it makes sense to render on burp) so the boost 10 session now pays 10, compared to the 0 before.
On the other side this is fair, because the owner said he/she is ready to pay 10.


Post to thread

Message boards : Website : Prioritise Projects