cloudsim中的timeshared是如何工作的,没有代表时间片或量子的变量,那么cloudsim中如何验证round robin的概念呢?
如果我们有 50 个小云,10 个虚拟机
cloudsim中的timeshared是如何工作的,没有代表时间片或量子的变量,那么cloudsim中如何验证round robin的概念呢?
如果我们有 50 个小云,10 个虚拟机
实际上,CloudSim 中的CloudletSchedulerTimeShared 并没有实现时间片/量子的概念。假设我们有一个 VM,其中有 1 个 1000 MIPS 的 CPU (PE) 和 2 个 Cloudlet 在其中运行。CloudSim 的 CloudletSchedulerTimeShared 提供了一个过度简化的实现,为每个 Cloudlet 分配 500 MIPS,使它们在同一个 CPU 上同时运行。
如果虚拟机只有一个长度为 5000 MI 的 Cloudlet,那么 Cloudlet 需要 5 秒才能完成。由于有 2 个 Cloudlet,在该单核 VM 的时间共享调度程序中,每个交替运行的 Cloudlet 需要 10 秒才能完成。为 2 个 Cloudlet 中的每一个仅分配一半的 CPU 容量 (500 MIPS),使它们像有 2 个 CPU 内核一样并行运行,将产生完全相同的结果:每个 Cloudlet 在 10 秒内完成。
关键是任何 Cloudlet 都没有等待时间。这些 Cloudlet 将像 VM 有 2 个 CPU,每个 CPU 500 MIPS 一样运行。如果您在模拟中评估 Cloudlets 的等待时间,那么这样的结果就是错误的。如果等待时间不是问题,结果很好。
如果你真的需要评估 Cloudlets 的抢占过程,你可以查看CloudSim Plus,它是一个功能齐全、最先进、完全重新设计和积极维护的 CloudSim 分支。它提供了完全公平的 Linux 调度程序的实现,它执行实际抢占并考虑运行 Cloudlets 的时间片。检查CloudletSchedulerCompletelyFair和LinuxCompletelyFairSchedulerExample。
[如果我们有 50 个小云,10 个虚拟机。cloudsim 中的 CloudChedular 和 VmSchedular( 时间共享) 类将根据要执行的作业 (cloudlet) 的总数分配资源。例如,当请求的容量超过当前容量时,将发生故障并导致违反 SLA。