<p dir="ltr">Ok, but I don't understand why it works like a pull model instead of push. Is so because of a too high load matter or only because the initial architectural decision was to work like that and now it is still so?</p>

<p dir="ltr">What would be the drawbacks if were the core,immediately every time a request arrive, tell to the scheduler to schedule that request?</p>
<p dir="ltr">My question comes because I'm working on improving the deployment time of VMs for my master thesis, and I understood that I can choose to deploy VMs little by little, or immediately as they come but I can't see the cases in which deploy VMs little by little would be better that process them immediately.<br>
</p>
<p dir="ltr">Thanks a lot,</p>
<p dir="ltr"> Andrea Gardiman.</p>
<div class="gmail_quote">On Mar 7, 2014 10:58 AM, "Carlos Martín Sánchez" <<a href="mailto:cmartin@opennebula.org">cmartin@opennebula.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi,<div><br><div>On Thu, Mar 6, 2014 at 1:30 PM, Andrea Gardiman <span dir="ltr"><<a href="mailto:andreagardiman@gmail.com" target="_blank">andreagardiman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr">Dear all,<div>I do not understand the usefulness of the scheduler parameter "SCHED_INTERVAL". Why the scheduler act as a periodic task and have to wait a fixed period to schedule all the pending jobs instead of to be event-driven and schedule immediately a request?</div>


<div>What are the benefits and the drawbacks, besides the wait?</div><div><br></div><div>Thanks a lot,</div><div> Andrea Gardiman.</div></div></blockquote><div> <br></div></div><div>The scheduler is a separate daemon. So it polls the core periodically to look for pending VMs.</div>


<div><br></div><div>The usefulness of the SCHED_INTERVAL is that, combined with the other config parameters [1] MAX_DISPATCH and MAX_HOST, allows you to configure a "buffer" to deploy VMs little by little, or immediately as they come.</div>


<div><br></div><div>Regards</div><div><br></div><div>[1] <a href="http://docs.opennebula.org/stable/administration/references/schg.html" target="_blank">http://docs.opennebula.org/stable/administration/references/schg.html</a><br>
</div>
<div class="gmail_extra">
<br clear="all"><div><div dir="ltr">--<br><div>Carlos Martín, MSc<br>Project Engineer</div><div>OpenNebula - Flexible Enterprise Cloud Made Simple<br><div><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42,93,176)" target="_blank"></a></span></div>


</div></div></div>
<br></div></div></div>
</blockquote></div>