infrastructure as a service  ( iaas ) systems @xcite build on virtualisation technologies to allow automated infrastructure provisioning .
virtual machine ( vm ) based provisioning gives users two major benefits : they do not need to be experts in physical infrastructure maintenance , and they can easily follow their demand patterns and scale their virtual computing infrastructure ( composed of several vms ) with tools built on top of iaas systems .
these two benefits led to the wide and rapid adoption of such infrastructure offerings .
unfortunately , their rapid adoption has led to infrastructures that still have plenty of open research issues ( e.g. , energy aware vm placement , service level objective specifications ) .
however , even iaas systems operated by academia are used in production nowadays . as
production level systems are used by a multitude of users on a daily basis , changing the internal behaviour of such systems might hinder their user experience ( such as reliability and usability ) .
thus , research focused on improving the internals of iaas systems ( e.g. , introducing a new experimental virtual machine placement algorithm ) can not be done on such production systems directly .
consequently , to analyse new and novel ideas for internal behaviour , researchers are either restricted to severely limited iaas deployments ( e.g. , rarely utilising more than a few hosts ) or should resort to theoretical modelling of expected internal behaviour .
however , results based on such research is often questioned by the operators of production clouds because their applicability to large scale systems is often not proven .
some researchers use simulators to further evaluate their models  @xcite .
these simulators allow researchers the evaluation of new ideas in life - like scenarios and as a result such simulators could pave the way for the new research results allowing their wide - spread adoption .
although a plethora of iaas related simulators exist even today , these simulators have very different focuses .
some are designed completely from the user s point of view and hide the cloud s internals so users can make decisions on how and what services should be moved to the clouds  @xcite . because of their user orientation , in these simulators it is frequently problematic to introduce changes in iaas behaviour .
some others  @xcite emphasise the need for precision for such simulations . despite their extensibility , these simulators not only scale very poorly ( making it problematic to evaluate more elaborate iaas scenarios where sometimes thousands of physical machines collaborate ) , but they also require complex setup procedures to be precise ( e.g. , one should model every possible application in the system to receive realistic results ) . finally , there are simulators that introduce some assumptions in the system that reduce the precision of the simulations but reach unprecedented speeds  @xcite . unfortunately , despite having clear advantages , they are too specific to allow investigations on internal iaas changes ( e.g. , groudsim only models external interfaces of clouds , simgrid merely focuses on virtualisation , and cloudsim has conflicting extensions
e.g. , power modelling is not available while using networking ) .    in this article ,
a new versatile simulation framework is presented ( called discrete event based energy consumption simulator for clouds and federations
dissect - cf ) .
compared to the previously mentioned simulators , dissect - cf offers two major benefits : a unified resource sharing model , and a more complete iaas stack simulation ( including for example virtual machine image repositories , storage and in - data - centre networking ) .
the benefits of the sharing model are threefold : @xmath0 it allows a single framework to model resource bottlenecks ( e.g. , cpu , network ) , @xmath1 generic resource sharing performance optimisations immediately improve entire simulations , @xmath2 it provides a unified view on resource usage counters ( i.e. , allows resource type independent , generic monitoring ) .
finally , dissect - cf also opens up possibilities for more fine - grained energy consumption modelling by allowing the user to derive energy consumption from multiple resource usage counters . as a result of these new advancements ,
the new simulator could foster research on schedulers that could either have better insight into internal iaas behaviour or collaborate with internal schedulers of iaas systems in order to achieve previously unprecedented flexibility , adaptability and elasticity in future cloud systems .
unfortunately , dissect - cf s focus on supporting research on infrastructure cloud schedulers introduces several limitations to its applicability .
first of all , for performance reasons the simulator represents networks with a simple flow model , which has already been shown by several studies ( e.g. , @xcite ) to be inaccurate for smaller - sized network transfers .
fortunately , smaller - sized network transfers have a negligible influence on scheduling decisions in most cloud related schedulers .
also , because scheduler focused research usually uses task or virtual machine instantiation / termination traces for behavioural studies , dissect - cf uses the black box philosophy for applications .
thus , the simulator will not provide accurate results on resource utilisation if a particular application s behaviour can not be approximated with simple resource consumption metrics ( e.g. , when there is unstable cpu utilisation for extended periods of time ) .
in fact , these limitations are present in most simulators  ( except those that have packet level network simulations or employ more complex flow models  see @xcite ) . finally ,
as the new simulator is aimed at providing a framework for researchers to experiment with the internals of infrastructure clouds , the included scheduling mechanisms themselves are present only as examples for future work and they do not extend the scheduling related state - of - the art themselves .
the behaviour of dissect - cf was analysed by first validating it against the behaviour of a small - scale infrastructure cloud at the university of innsbruck .
according to the findings of this article , the system s simulated behaviour matches real - life experiments with negligible error ( in terms of application execution time , larger scale network transfers and energy consumption ) . for larger scale experiments ,
dissect - cf was validated with proven results from two other simulators that are close to the new simulator s functionality ( namely cloudsim @xcite and groudsim @xcite ) .
then , performance of these two simulators was compared to the newly proposed one .
comparisons were executed with both real - world  ( using the grid workloads archive  @xcite ) and synthetic traces .
the use of real - world traces also revealed that dissect - cf based simulations allow 1.5 - 32@xmath3 faster behavioural analysis of simple cloud schedulers or vm placement strategies .
the performance differences were further investigated through synthetic traces and it is shown that dissect - cf scales significantly better in complex resource sharing situations with the help of its unified resource sharing model ( one can observe an improvement of even over 2800@xmath3 in execution time in some cases ) .    the rest of this article is organised as follows .
section [ sec - relworks ] presents the related research results .
then , section [ sec - design ] reveals the architecture of the newly proposed simulator and discusses its internal behaviour and extensibility options .
section [ sec - eval ] analyses the properties of dissect - cf by comparing its behaviour to real - life systems and by comparing its performance to other simulators .
finally , section [ sec - conclusion ] concludes the article with a summary and with the identification of future research directions .
this section first reviews the scheduling scenarios that a cloud simulator might support .
then an overview is presented on the most popular cloud simulation platforms .
finally , the section concludes with a problem statement for the new simulator .
there are seven common kinds of schedulers that could have an influence on the behaviour of a virtual infrastructure created on top of iaas cloud systems . in the following
, a short overview is given of these kinds of schedulers with special attention on their requirements from a simulated environment .
the list is presented from the schedulers that have the strongest user - side orientation to the most hidden schedulers in infrastructure systems .
if a user has large enough resource demands , then its virtual infrastructure might include multiple virtual machines that could host a particular kind of task .
in such cases , whenever a new task arrives , the user has to decide on which virtual machine it should actually run the task .
the decision can be automated with a scheduler and a queuing system ( similar to local resource managers
e.g. ,  @xcite ) . in order to support research on these kinds of schedulers , _
simulators should be able to provide past and present vm level performance metrics _
( e.g. , temporal performance degradation of the vm s computing capabilities ) .    when a user s resource demands are more dynamic and sometimes unpredictable , then he / she would frequently face heavy under- or over - utilisation of his / her virtual infrastructure . to better meet the demands of the newly arriving tasks ,
the virtual infrastructure should be able to automatically scale .
this scaling is often achieved with a special scheduler ( e.g. , @xcite ) that decides when to instantiate / terminate a particular kind of vm .
research on such schedulers need _ simulators that are capable of providing accurate vm management metrics _ ( e.g. , virtual machine instantiation time ) .
some users have access to multiple cloud infrastructures . for such users ,
a new scheduler is needed ( e.g. , @xcite ) which can choose between various cloud providers and dispatch vms to them .
the selection procedure is expected to take into account the availability , reliability and similar metrics of the various providers and also it should consider issues like placing processing close to big data . for such schedulers , _
simulators are required to offer infrastructure provider level metrics and data locality information . _    inside iaas systems , user requests are no longer represented as tasks but they are only seen as vms . as iaas systems
are highly automated , decisions to place a particular vm on a physical machine must be also done by a scheduler .
this kind of scheduler ( e.g. , @xcite ) could have two main tasks : @xmath0 for already existing virtual machines , a new vm to host mapping could be identified which would allow a vm arrangement that considers both the vms actual load and the providers current needs , and @xmath1 for newly requested virtual machines , the scheduler should determine the host where the vm could be run . as these schedulers have diverse tasks , _
simulators should have the capability to disseminate the load of currently running virtual machines and also the utilisation of physical machines_.    energy conscious iaas systems aim at reducing their energy consumption in several ways .
a simple way to do so is to consolidate vm load to the most energy efficient machines and switch the rest to a more energy efficient state .
the automated decisions on which machines should be serving vms and which ones should be waiting in low power states ( e.g. , suspend , switch off ) are done by physical machine schedulers ( e.g. , @xcite ) .
these schedulers should ensure that , because of their operations , virtual machine creation and quality of service do not degrade below certain levels . to support the development of physical machine ( pm ) schedulers , _
simulators must necessarily maintain the cost of pm power state changes _
( e.g. , cold / suspend to ram boot - up procedures ) .
schedulers are also present in virtual machine monitors  ( like xen or kvm ) in order to allocate physical resources to virtual machines on a time - sharing basis ( e.g. , @xcite ) .
although , these schedulers are not the main focus of research in cloud computing , they could have a direct impact on the quality of service if the above - mentioned vm placement strategies under - provision some virtual machines .
for this reason , _
simulators should be able to correctly handle and report under - provisioning scenarios on physical machines_.    the lowest levels of schedulers that may affect higher - level ( e.g. , task to vm assignment ) decisions are the process schedulers ( e.g. ,  @xcite ) of the operating system in the user s vms . in some cases the user could have an influence on the os scheduler , but in others users must use oss and schedulers that are prepared and accredited by the iaas providers . since these schedulers are generic os level schedulers , they are out of the scope of cloud computing research .
but since higher - level schedulers might make decisions on how these process schedulers behave , simulators should give their users some information on their behaviour .
for example , _ simulators should be capable of reporting if a particular vm is under - provisioned _ and tasks have no chance to access resources scheduled for them by the os level scheduler .
cloudsim  @xcite is amongst the most popular iaas cloud simulators .
it was initially based on gridsim  ( a widely used grid simulator developed by the same research institute
@xcite ) but , after some performance and reliability issues , it was completely rewritten so it uses only some concepts ( e.g. , cloudlet  gridlet analogy ) from its predecessor  @xcite .
cloudsim introduced the simulation of virtualised data centres mostly focusing on computational intensive tasks and data interchanges between data centres .
later , they extended the simulation to better support internal network communications of a data centre with networkcloudsim  @xcite .
there are also extensions that simulate the energy consumption behaviour of the physical machines in the data centre based on specpower benchmarks and on dynamic voltage and frequency scaling  @xcite .
cloudsim also formed an ecosystem .
several third parties offer extensions on top of cloudsim .
some significantly change cloudsim behaviour
( e.g. , add performance improvements  @xcite , add better support for inter - cloud operations  @xcite , implement new energy consumption models  @xcite , or introduce sla concepts into the simulation  @xcite ) , while others wrap cloudsim and provide additional functionality ( like graphical user interfaces for teaching  @xcite or for analytics  @xcite ) . despite its wide use , cloudsim has several disadvantages : @xmath4 low performance for scheduling research where thousands of scheduling scenarios should be evaluated in a timely fashion , @xmath5 networking is simulated for tasks only ( e.g. , data centre operations that utilise the same network as user tasks  like virtual machine image transfers  are not simulated even though they could have significant effects on the user perceived network performance ) and @xmath6 using multiple extensions at once is frequently not possible ( e.g. , advanced networking and energy consumption modelling are not usable together since one would need to have virtual machines that inherit behaviour both from ` powervm ` and from ` networkvm ` classes ) .
the simgrid framework  @xcite is another widely used simulator for analysing the behaviour of distributed systems ( e.g. , grids , peer to peer systems ) .
its resource sharing simulation is one of the most detailed ; for example , it contains one of the most accurate non - packet oriented network models  @xcite .
this simulator s focus was not particularly on clouds for a long time but recently its developers introduced extensions for virtualisation ( e.g. , hypervisors or live migration
because of its distributed systems and grid background the simulator is inefficient in iaas cloud related situations . for example , this simulator stops at the virtual machine level , thus it would require significant effort to build a multi data centre / cloud simulation on top of it .    while cloudsim and simgrid were heavily influenced by previous simulators for grids and distributed systems , for performance reasons they also make compromises on networking . to resolve such issues
there are simulators like icancloud  @xcite and greencloud  @xcite that are built on network simulators ( e.g. , omnet++ or ns2 ) to more accurately simulate network communications in cloud systems .
their efforts result in great accuracy if all iaas components and applications are modelled correctly network - wise ; otherwise , they just introduce serious performance penalties because of the packet level simulations without the expected accuracy .
in addition to networking improvements , greencloud  @xcite is also offering precise energy estimations for networking and computing components , while icancloud also offers a user oriented simulation which supports iaas utilisation decision - making  @xcite on top of the regular iaas related simulation functionalities  @xcite .
next , groudsim  a simulator developed at the university of innsbruck  @xcite  was analysed .
this simulator aims at performance while it encompasses cloud concepts in a grid simulator environment . the simulator is also integrated with the askalon workflow system  @xcite so it can be used to evaluate behavioural changes of real - life scientific workflows in the case of changes in the computing environment .
although this simulator supports clouds , it does not provide implementation on the internals of iaas systems ( i.e. , it provides a black box implementation ) , thus it is not suitable for research studies that involve the internals of cloud infrastructures . and
although groudsim supports both cpu and network resources , the networking implementation of groudsim is one of the least developed ones amongst the reviewed simulators .
the above simulators focus more on the user related behaviour of data centres , but there is a class of cloud simulators which is more focused on supporting decisions related to data centre operations  ( e.g. ,  @xcite ) .
so even though these simulators could be used for examining user related behaviour , their detailed implementation of data centre behaviour reduces their usability in this context . on the other hand ,
these simulators offer some unique features that might be useful for research on iaas related schedulers .
for example , speci  @xcite is focused on offering a tool to analyse the scalability of iaas toolkits that will support future data centres .
next , dcsim  @xcite allows the analysis of new virtual machine management operations ( like relocation ) .
finally , dcworms  @xcite provides a unique view on data centre energy efficiency , including the heating , ventilation and air conditioning ( hvac ) system s airflow and high granularity resource ( e.g. , individual cpu , memory modules , network interfaces ) energy modelling .    [ [ problem - statement ] ] problem statement + + + + + + + + + + + + + + + + +    the analysis of the related work leads to the conclusion that existing simulators have many drawbacks for those who would like to investigate scheduling scenarios in iaas systems . to fulfil the needs of such scheduling scenarios , the rest of the article reveals a new infrastructure simulator that provides better insights on infrastructure behaviour for schedulers while maintaining the scalability of past simulators .
]    figure  [ fig - arch ] presents the overall architecture of the newly proposed simulator .
the figure groups the major components with dashed lines into subsystems . each subsystem is implemented as independently from the others as possible . as a result , simulation developers do not need to understand the complexity of the entire simulator if they intend to work on one of its subsystems .
there are five major subsystems ; they are listed in an order that follows their level of abstraction ( from the most abstract to the more specific to iaas systems ) :    these components provide the time reference for simulations
.    this subsystem acts as a lightweight and extensible foundation to low - level computing resource sharing ( e.g. , cpu , i / o ) .
with these components dissect - cf enables simulator developers to monitor and analyse energy usage patterns of each individually simulated resource ( e.g. , network links , disks ) .
these components handle the behaviour of those iaas system parts ( e.g. , virtual machines ) that are the primary target of iaas related schedulers .
this subsystem provides the user interface ( the vm management api ) and represents the high level functionalities ( e.g. , virtual machine schedulers ) of infrastructure clouds .    in the following sections ,
these subsystems are individually discussed .
the core of the dissect - cf simulator is a simple but high performance event generator  ( reflected as ` timed ` in figure  [ fig - arch ] ) .
it is used to maintain the time within the simulated system and allow third parties to be notified if a particular time instance has been reached.the simulator is not aware of the applied time granularity  ( i.e. , it is not known in the simulation if a single increase in the maintained time is equivalent to a single millisecond or a full hour ) .
this enables flexibility in use , and allows simulation developers to have precision only when they assuredly need it ; otherwise , they can benefit from faster simulations . in later sections of the article , the smallest time granularity for the current simulation
is denoted with @xmath7 and is expressed in seconds .
thus any given time instance in the simulator can be specified as : @xmath8 , where @xmath9 and @xmath10 .
here , @xmath11refers to the set of all possible time instances throughout a simulation .
the simulator also assumes that notifications are recurring .
thus , subscribing to events means specifying the frequency with which one would like to be notified .
the simulator contains a construct ( called ` deferredevent ` ) for non - recurring events . creating a subclass of either
the ` timed ` or the ` deferredevent ` classes allows simulation developers to receive custom time dependent notifications .    finally , the ` timed ` class is also the control point for the simulation time .
simulations have two distinct ways to influence simulated time :    controls directly influence the timer .
first , one can _ fire _ the events for the current time instance then advance the timer by one @xmath12 .
second , it is possible to ask for a time jump that will progress the time with a given interval if within the interval there are no events expected .
controls let the simulation flow for a given time interval without any intervention  ( e.g. , one can simulate until all events from the queue are cleaned up ) .
these controls also enable the progression of the timer while dropping irrelevant events that would occur in a given period of time .      directly on top of basic time management
lies the resource model of the simulator .
the model is intended to capture low - level resource sharing behaviour ( e.g. , assigning tasks to virtual cpus  of vms  or virtual cpus to physical ones , or balancing network bandwidth utilisation ) .
dissect - cf applies a provider - consumer scheme to resources where resource consumptions are intermediaries between consumers and providers . in the case of simulated cpus , consumptions represent instructions to be processed , thus cpu computing cycles of a physical machine are provided to virtual machines to consume . in a network analogy ,
consumptions represent data to be transferred between two network hosts ( where the sender acts as the provider and the receiver as the consumer ) .
dissect - cf allows the definition of both providers and consumers with the help of the ` resourcespreader ` class  ( see figure  [ fig - arch ] ) .
the set of all spreaders in a particular simulation will be referred as @xmath13 .
the simulator uses the concept of resource consumptions as the intermediaries that represent the current processing demands of the actual consumers .
resource consumptions are denoted with a triplet : @xmath14 , where @xmath15 represents the resource consumption , @xmath16 represents the processing that is currently under way , @xmath17 represents the remaining processing ( i.e. , processing that has not started yet ) and @xmath18 represents the limit for this processing in a single @xmath12  ( e.g. , simulation developers can specify that a resource consumption is single - threaded so it can use the processing power of a single processor of a consumable cpu resource only ) .
@xmath19 represents all possible resource consumptions in a simulation : @xmath20 . at a given time instance , the function @xmath21 determines which provider offers the resources to be consumed .
similarly , @xmath22 defines the consumer that utilises the offered resources .
these functions are time dependent to allow the migration of resource consumptions amongst spreaders .    at a given time
, a particular resource consumption is processed in its provider by determining how much processing can be considered possible during a single @xmath12 .
the possible processing has an upper bound of @xmath17 ( i.e. , if more processing could be possible than there is still remaining in @xmath15 , then the provider will have some non - utilised processing capabilities ) .
also , the possible processing is limited by the provider s maximum processing capability and the processing limit @xmath18 of the consumption . @xmath23 where @xmath24 , @xmath25 and @xmath26 represent the processing under way , the remaining processing and the limit , respectively , for resource consumption @xmath15 at the time instance @xmath27 .
it must be pointed out that @xmath28 is offering the provider side under processing value only .
finally , @xmath29 reveals the processing power of a resource spreader ( in this current case the provider for resource consumption @xmath15 : @xmath30 ) at the time instance @xmath27 .
dissect - cf simulates consumers with similar behaviour , so they remove utilised resources from @xmath16 .
of course in this case the limit of utilisation is dependent on the consumer and the previously evaluated provider side possible processing value : @xmath31 thus , to determine the state of a particular resource consumption , dissect - cf first evaluates the provider side of resource consumptions , and then it processes the consumer side . after the simulator determined the @xmath16 value for a resource consumption , the remaining consumption @xmath32 can be determined as well by reducing with the increment of the @xmath16 value .
this behaviour ensures that at the end of the consumer side processing both @xmath16 and @xmath17 will represent the resource consumption s state in the next simulated time instance ( @xmath33 ) .    in order to determine how much processing can be done on resource consumptions at a particular time instance @xmath34
, resource spreaders apply the lowest level schedulers in dissect - cf based simulations .
these schedulers share the processing capacities of the resources amongst those resource consumptions that the spreaders are currently dealing with  ( @xmath35 , where the notation of @xmath36 is used to depict a power set ) . as simulation developers
are expected to run simulations with thousands of resources and millions of resource consumptions , these low - level schedulers must be highly customisable and efficient . to enable simple customisability ,
dissect - cf provides efficient implementations for most common scheduling related tasks ( e.g. , resource consumption registration , de - registration , event generation for parties interested in resource consumption state ) , allowing providers of new schedulers to just focus on the scheduling logic that calculates the new @xmath34 values .
+    the scheduling logic is expected to deliver fair resource allocation for simultaneously occurring resource consumptions  denoted as @xmath37 . to simplify the behaviour and complexity of schedulers
, dissect - cf also introduces the concept of influence groups .
these groups are formed from all resource spreaders that have a chance to influence each other s resource allocation schedules . with the help of influence groups
even schedules for complex network structures can be simulated at close - to - real - life behaviour ( e.g. , the simulator can apply fair share algorithms over multiple related network links ) .
these schedulers can utilise influence groups as their domain in which they have to guarantee a fair resource schedule for the spreader associated resource consumptions .    to determine the membership of an influence group
, the simulator uses the resource consumptions that link consumers and providers ( see figure  [ fig - inf - gen ] ) . as a practical example ,
figure  [ fig - inf - cpu ] shows how each simulated physical machine forms independent influence groups with the virtual machines it hosts via their respective cpu spreader implementations .
formally , an influence group of a resource spreader at the particular time instance is defined as follows ( @xmath38 ) : @xmath39 where @xmath40 is a resource spreader , and the function @xmath41 defines the spreaders available at a particular time instance .
the equation shows that @xmath42 includes all resource spreaders that are directly or transitively referred by the associated resource consumptions of the spreader @xmath43    @xmath44 . as a result
, one could find as many influence groups as the number of resource spreaders existing at a given time instance in the simulation . on the other hand ,
these groups are frequently equivalent because determining the influence group of any member of a particular group will result in the original influence group : @xmath45 this last equation is derived from the definition of @xmath42 and reveals that after the proper calculation of @xmath42 there should not be any members of it ( e.g. , @xmath46 ) that would result in a different influence group than the original @xmath42 .
although the definition of @xmath47 is quite straightforward , its evaluation in all necessary time instances for all relevant resource spreaders would result in significant simulation performance deterioration .
therefore , dissect - cf provides an algorithm that significantly reduces the use of @xmath47 but still ensures that the influence groups are available for the scheduling logic in every time instance . to differentiate between the original function s results and the algorithm calculated values , the notation @xmath48 is used for
the influence groups determined by the algorithm ( see algorithm  [ alg - basopt ] ) .
@xmath49 @xmath50 [ lin - ext - start ] @xmath51 [ lin - emptyext ] @xmath52 [ lin - identadd ] @xmath53 [ lin - extgadd ] @xmath54 [ lin - realext ] @xmath55 [ lin - igextcomplete ] [ lin - ext - stop ] [ lin - split - start ] @xmath56 @xmath57 [ lin - randsel ] @xmath58 [ lin - correct - group ] @xmath59 [ lin - split - upd - start ] @xmath60 [ lin - split - upd - stop ] [ lin - split - stop ]    in the following few paragraphs , the internal behaviour of the new algorithm is discussed .
it is built on the assumption that @xmath61 and it is composed of two distinct phases : influence group extension
see lines [ lin - ext - start]-[lin - ext - stop ]  and group dissolution
see lines [ lin - split - start]-[lin - split - stop ] .
let us first discuss the extension phase . during this phase ,
the algorithm first starts with an empty resource spreader set ( see line [ lin - emptyext ] ) that will later on hold the identified extensions of the input influence group  @xmath49 . as a next step , line [ lin - identadd ] determines the resource consumptions that arrived to a particular resource spreader at the time instance @xmath33 .
afterwards , the following line focuses on those newly added resource consumptions that introduce new resource spreader members into the input influence group .
these non - member providers or consumers are added to the extension set in line  [ lin - extgadd ] .
this iteratively created extension set is used to actualise the input influence group in lines [ lin - realext]-[lin - igextcomplete ] .
the extension phase completes only when there are no newly introduced resource spreader members in the input group .
otherwise , the current phase is repeated to ensure finding even further group extensions via the resource consumptions associated with the introduced members ( this last step is shown in line [ lin - ext - stop ] ) .
after there are no new extension possibilities found in the current influence group , the algorithm proceeds to its second phase in which it identifies all splits of the current influence group .
for example , influence group # 5 in figure  [ fig - inf - gen ] will have to be split when the resource consumption between provider @xmath62 and consumer @xmath63 finishes . to identify the need for splitting
, the algorithm therefore first determines if there were some resource consumptions dropped from at least one member of the influence group ( see line  [ lin - split - start ] ) .
if there is a need for splitting , then the algorithm will maintain the not yet split parts of the original influence group in @xmath64 . in order to determine
which parts have to be split from the not yet split parts , lines [ lin - randsel ] and [ lin - correct - group ] use the original @xmath65 on a randomly selected spreader from @xmath64  resulting in a new influence group called @xmath66 . in the next line ,
the not yet split parts are updated so that only those resource spreaders will be considered afterwards that are not in @xmath66 .
finally , the algorithm updates its self - maintained influence group membership so all members of @xmath66 will be exactly the same ( see lines [ lin - split - upd - start]-[lin - split - upd - stop ] ) .    to conclude , the newly introduced algorithm reduces the number of direct @xmath42 function calculations to those cases where there is a chance to have a group to be split . and even in that case
, it ensures that the number of @xmath42 evaluations is limited by the number of influence groups created after a split .      ]
the last remaining part of the unified resource model is the simulation developer customisable low - level scheduling logic . to understand the customisation options dissect - cf offers ,
figure  [ fig - rs ] presents the context of the scheduling logic .
the figure reveals the role of the low - level scheduler through the illustration of the life of a single resource consumption that can be represented in three phases and denoted with different kinds of arrows : preparation
regular lines ; resource consumption    dashed lines ; and completion
  dotted lines .
the next paragraphs provide a brief overview of these three phases .
first , the preparation phase is initiated by the entity who is responsible for creating ( see _ step 1 _ in the figure ) a particular resource consumption  @xmath67 .
this entity could be an automated process ( e.g. , a workload generator ) or some higher - level entity of the simulator ( e.g. , the virtual machine representation ) .
after creation , the registration can be initiated in any time instance @xmath27 after both the consumer
@xmath68  and the provider  @xmath69
spreaders are specified .
the registration is accomplished in _ step 2 _ in the figure .
the provider nudges the scheduler base in _ step 3 _ after both the consumer and the provider have registered the new resource consumption  @xmath70 and @xmath71 .
the _ scheduler base _ is implemented in the base class of all resource spreaders and is responsible for interfacing with the event system , the scheduler and the influence group management algorithm . before contacting the event system for subscription ,
the scheduler base first updates the influence groups with algorithm  [ alg - basopt ] in _ step 4_. after the identification of all distinct influence groups , the scheduler base filters those groups that would need an updated schedule .
such groups are identified via recently added or dropped resource consumptions to / from one of their member resource spreaders
i.e. , @xmath72 . in _ step 5
_ , the scheduling logic is invoked for each of the filtered groups . during this step
, it should assign the @xmath34 values for all resource consumptions that are currently taking place in a given influence group . with these assignments ,
the simulator calculates the earliest completion time of the currently managed resource consumptions .
then , in _ step 6 _ , it subscribes to a notification from the event system in order to know when the next resource consumption will be removed from the filtered influence groups .    in the following phase , the simulator handles the resource consumptions
this phase is either done when the event system delivers the notification on a resource consumption completion ( see _ step 7 _ ) or alternatively upon the registration of a new resource consumption . in the second case ,
the resource consumption handling is automatically executed before influence groups are calculated ( i.e. , steps _ 8 - 12 _ could precede _ step 4 _ of the preparation phase if a resource consumption is registered at a resource spreader that has already had some prior resource consumptions ) . in practice ,
_ steps 8 - 9 _ evaluate eq .
[ eq - prov - update ] and _ steps 10 - 11 _ evaluate eq .
[ eq - cons - update ] for all simultaneously existing resource consumptions
@xmath73  in the simulator . resource consumptions
e.g. , @xmath74  are automatically marked for removal when they reach their completion
i.e. , @xmath75 . as a final step for resource consumption handling , the scheduler base checks for resource consumptions marked for removal  ( see _ step 12 _ ) and on all marked resource consumptions it executes the completion phase .    in the final phase ,
the resource consumption s completion is simulated .
consumptions can be considered complete in two cases : either they have no further processing to be done or they were cancelled by the entity using the resource sharing mechanism .
the scheduler base notifies this entity in both cases  see _ step 13_. then it checks if it has finished all the current resource consumptions
if there are still further resource consumptions to process , then the scheduler base resumes operations from _ step 4 _ , otherwise it cancels further notifications from the event system .
as can be seen , the simulator expects scheduling logic implementations to utilise a fairly narrow and well - defined interface with the scheduler base . through this interface
the simulator ensures that whenever a new schedule is needed ( i.e. , new @xmath34 values ) , the simulation developer provided scheduling logic is always called .
dissect - cf also provides two sample implementations for this scheduling logic : a max min fairness algorithm  @xcite implementation with progressive filling , and a simple logic that does not deal with complex bottleneck situations but demonstrates the interfaces with the scheduler base .
compared to other recently developed simulators , dissect - cf completely decouples energy modelling from resource simulation in order to allow accounting for such energy consumptions that are not in direct relation to the resource utilisation of data centres . with this approach ,
a more comprehensive energy and power modelling is achievable that enables the analysis of new sophisticated energy aware algorithms in the areas of virtual machine placement , task scheduling , etc .
these algorithms previously were frequently limited because energy readings from heating , ventilation and air conditioning ( hvac ) units or higher - level iaas components ( like vm schedulers or iaas interfaces ) were scarcely available in past simulators .
thus , this section presents how energy consumption related information is collected and accumulated so they can support future algorithms .
later , section  [ sec - hls ] discusses the foundations for physical machine schedulers that are expected to be the primary users of the models overviewed in this section .
first , in order to enable the decoupling , dissect - cf offers _ resource utilisation counters _ both for producers and consumers .
these counters allow an aggregated and time dependent view of the consumption of particular resources .
counters are updated depending on the ` power state ` of a resource spreader ( see figure  [ fig - arch ] ) .
for example , a physical machine  @xmath77  in suspend to ram ( str ) power state zeroes its processing power : @xmath78 the power states of the various entities in the simulation can be defined as needed ; the simulator only expects these states to define the basic power characteristics ( e.g. , minimum and maximum power draw ) and the resource processing behaviour of the given entity at the specific state .
the simulator also provides a basic set of power states ( on , off , turning on , turning off ) for which the resource processing behaviour is already defined for the resources incorporated into a physical machine .
based on this low - level power modelling functionality , the decoupling of energy models is accomplished through ` energy meter`s .
these meters are organised around four functionalities : @xmath0 monitoring of energy consumption directly related to resource utilisation , @xmath1 indirect energy consumption estimation , @xmath2 aggregation of metering results from multiple meters and @xmath79 presenting up - to - date energy readings to their users .
the remainder of this subsection reveals how these functions accomplish the decoupling and shows the ways customised , infrastructure specific metering can be achieved in dissect - cf .      ]
[ [ direct - resource - utilisation - related - energy - consumption - metering ] ] direct resource utilisation related energy consumption metering + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    based on the previously mentioned resource utilisation counters , the simulator can be requested to periodically evaluate the instantaneous utilisation percentage . then , energy ` consumption model`s use these percentages ( see figure  [ fig - arch ] ) to estimate the instantaneous power draw of each monitored resource spreader ( later the resulting estimate and the metering period is used to calculate the direct meter s energy consumption estimate ) .
consumption models are dependent on the actual power state a resource spreader is in , and the simulator developer can define them . as examples ,
the simulator provides two simple energy consumption model implementations : @xmath0 a linear interpolation between minimum and maximum power draw depending on current resource utilisation , to allow basic modelling of dynamic power behaviour  or @xmath1 a constant minimum power draw , to allow the effortless modelling of _ off _ or _ str _ power states .
figure  [ fig - meters ] presents direct meters for each resource spreader in the shown physical machines .
[ [ indirect - energy - consumption - estimation ] ] indirect energy consumption estimation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    to support more complex energy consumption estimates , the simulator also allows energy consumption to be derived from other properties of the simulated system .
for example , these properties could include the virtual machine request rate of a particular data centre , or the utilisation of the data centre level storage subsystem ( e.g. , to estimate how many disk drives the currently stored data can occupy ) .
these meters are expected to periodically evaluate the system state and accumulate their energy consumption estimates for those components of the simulated system that are not directly represented with resource spreaders .
figure  [ fig - meters ] reveals two indirect metering solutions to represent the internal actions of iaas systems and the energy consumption behaviour of data centre level hvac systems .
[ [ meter - aggregators ] ] meter aggregators + + + + + + + + + + + + + + + + +    in several cases , the energy consumption values from individual direct or indirect meters are not sufficient for higher - level energy aware decision makers ( e.g. , physical machine state schedulers  see section [ sec - schedulers ] ) .
for example , a physical machine in dissect - cf is represented with multiple resource spreaders ( e.g. , cpu , disk bandwidth ) , thus to have a complete view of a physical machine s energy consumption , one would need to monitor several direct energy meters .
meter aggregators allow the automated collection and management of several meters in parallel and provide the higher - level view expected by decision makers .
figure  [ fig - meters ] shows a complex scenario for the use of aggregators .
this scenario shows that a single aggregated meter can be constructed for a whole data centre , allowing even the inclusion of indirect metering results such as hvac .
the figure also shows how a physical machine s resource spreader set can be metered as a single entity .
as the estimation of energy consumption of the simulated entities might be time consuming , the simulator allows simulation developers to fragment and focus their measurements on those parts of the simulated systems that they are interested in .
for instance , the simulation developers might be only interested in the energy consumption of a single virtual machine that is deployed on a simulated cloud with multiple data centres .
in such cases , dissect - cf can limit the number of energy meters that are evaluated with two approaches : independent meters or adjusted aggregations .
[ [ independent - meters ] ] independent meters + + + + + + + + + + + + + + + + + +    this approach entails that metering results are only dependent on the metered component and the rest of the simulated system can not influence them .
e.g. , the energy consumption reported for a cpu level resource spreader of a physical machine should not be dependent on the behaviour of the rest of the system .    [
[ adjusted - aggregations ] ] adjusted aggregations + + + + + + + + + + + + + + + + + + + + +    if there is a dependency between two metered components ( e.g. , a virtual machine that is hosted on a particular physical machine ) , then a special meter aggregator can be created .
this meter aggregator will not just add the aggregated meters measurements .
instead it allows simulation developers to define an aggregation function .
dissect - cf uses the adjusted aggregation technique to handle derived energy consumptions such as vm level energy consumption .
for example , when applying the linear interpolation based energy consumption model , virtual machine level power draw can be calculated using the power draw of the hosting physical machine , as follows : @xmath80 where @xmath81 is the derived instantaneous power draw of a particular vm while it is running .
the equation s first part estimates the variable part of the power draw , while the second part provides an estimate for the idle part . the variable part is dependent on @xmath82 , which is the maximum variability of the physical machine s power draw .
the variable part is proportional to @xmath82 , depending on the resource utilisation of the particular vm compared to the resource utilisation of all vms hosted on the same physical machine .
the second part of the estimate is the idle part that is derived from the idle power draw of the physical machine  @xmath83 .
this part is proportional to the number of vms hosted by the physical machine at the given time instance ( this number is one less than the cardinality of the vm s influence group because the group contains also the resource spreader of its hosting physical machine ) .
[ eq - powermodel ] reveals that the energy consumption model ( that estimates the instantaneous power draw ) of the virtual machine is not independent from the physical machine s behaviour .
therefore , energy consumption can not be directly accounted to virtual machines .
when such meters are requested , the simulator identifies them as dependent meters and instead of creating independent meters , it creates an adjusted meter aggregator including those meters that could provide the necessary information to calculate the energy consumption to be attributed to the originally requested meter . it must be noted that dependent meters consider energy consumptions multiple times ( e.g. , energy consumption is accounted to both physical and virtual machines ) .
thus when meter aggregations are created they must only include meters that are not dependent on each other .      to allow the simplified development of new vm placement algorithms and pm state schedulers , dissect - cf provides an implementation of relevant infrastructure components in iaas systems .
these components are built on top of the previously discussed resource sharing and energy modelling techniques and provide abstractions for networked entities and for physical / virtual machines ( see figure  [ fig - arch ] ) .
network activities rarely play a role in scheduling decisions related to tasks or to physical / virtual machines .
thus , to increase the performance of simulations , by default , dissect - cf offers a limited network model where two networked entities must be always directly connected ( therefore connection properties like bandwidth must be defined between all networked entities that should be able to communicate with each other in the simulation ) .
this rudimentary behaviour could be sufficient even for some network aware schedulers , but to allow better representation of real networks , the simulator also allows the creation of intermediary network entities ( such as routers ) . the implementation of such entities should alter the processing limit ( @xmath84 ) of all resource consumptions that are directed through them .
directly connected networked entities ( @xmath85 , where @xmath86 is the set of all possible networking entities ) are simulated with the ` networknode ` component .
this component encapsulates an incoming and an outgoing network connection simulated with the unified resource sharing foundation ; thus connections are implemented as resource spreaders : @xmath87 , where @xmath88 .
the processing power of these spreaders represents the network bandwidth ( either incoming or outgoing ) of the given network node .
when a new network communication must take place , simulation developers are expected to request a resource consumption between the source network node s outgoing resource spreader and the target s incoming resource spreader .
the component also introduces network latencies ( @xmath89 ) that can be defined between every networked entity for any given time instance .
the latency values resulting from this function are used as delays preceding the registration of each resource consumption to the incoming or outgoing resource spreader of the node .
for example , let us see what happens if a network communication ( represented as a resource consumption @xmath90 ) needs to be registered between a source and a target networked entity ( @xmath91 ) at the time instance @xmath92 : @xmath93 where @xmath94 is the network latency between the source and target nodes at the time of registration ( @xmath95 ) , and @xmath96 is the nonperforming spreader that never processes any resource consumption : @xmath97
. thus the equation shows , that the consumption is registered to the nonperforming spreader for the complete period of the latency , afterwards the simulator switches the consumption s registration to the originally designated spreaders ( which are the network output port @xmath98 of the source node @xmath99 and the input port @xmath100 of the target node @xmath101 ) .
this last step allows the simulator to utilise its unified resource sharing mechanism after the latency period is over .      in iaas systems ,
physical machines offer most of the user exploited simulated resources .
thus , dissect - cf ` physical ` ` machine`s encapsulate a diverse set of resources : local disks ( via repositories
see section  [ sec - ui ] ) , network interfaces ( with the help of network nodes  see section  [ sec - nw ] ) , cpus ( using the unified resource sharing model of section  [ sec - ursm ] ) and memory .
besides the modelling of these resources , dissect - cf s physical machine behaviour also focuses on two additional functionalities : administering resource allocations and vm requests ; and modelling physical machine level power behaviour . as resource sharing and modelling
has already been discussed in detail , this subsection mainly discusses the latter functionalities .
[ [ resource - allocator - and - vm - request - handler ] ] resource allocator and vm request handler + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    in order to maintain up - to - date information on the available and utilised resources of the physical machine , dissect - cf applies a resource allocator .
the applied allocator can reserve resources ( e.g. , a given amount of memory or number of cpu cores ) from the physical machine .
these reservations are represented as ` resource ` ` allocation ` instances that are used to maintain the free resource set of the physical machine .
allocation instances are also passed as a token of resource availability towards virtual machine schedulers .
other than the amount of resources associated with them , resource allocations also have the following properties : expiry time if unused or a link to the vm that uses it . when a resource allocation is created , the physical machine automatically initiates a ` deferredevent ` , which automatically cancels the allocation after the expiry time . to avoid this mechanism , the entity that requested
the allocation must request a vm to use the reserved resources ( i.e. , establishing the link between the vm and the allocation ) .
the automatic cancellation of the resource allocation is a self - defence mechanism of physical machines to avoid keeping resources out of use just because they received an unused allocation .    for a single vm request ,
dissect - cf allows multiple ` resource ` ` allocation`s to be made across multiple physical machines .
the multi - allocation technique can be used by schedulers to optimise for non - functional properties ( e.g. , past availability , expected energy consumption , environmental impact ) of those resources that a vm could bind to at a given moment . after a decision
is made about the use of a particular allocation for the vm request , the rest of the allocations ( which were non optimal according to the non - functional requirements ) are expected to be cancelled by the schedulers .
for complex vm instantiation scenarios , schedulers are also allowed to adjust the expiration time upon allocation request . with this mechanism
, researchers can evaluate advanced reservation - like scenarios regarding vm instances .
[ [ power - behaviour ] ] power behaviour + + + + + + + + + + + + + + +    as dissect - cf aims at supporting the development of energy aware scheduling strategies in iaas clouds , the energy model of the physical machine is particularly important . in its default configuration ,
the simulator supports 4 power states ( and the transitions between them ) : off , switching on , running and switching off . although this power state set is fairly limited , the simulator already offers constructs that allow the modelling of more complex operations like : suspend to ram , suspend to disk , dynamic voltage & frequency scaling or core / cpu de- and reactivation .
suspension related states can be modelled with the introduction of new power states , while the latter two are available because resource spreaders can alter their maximum processing capabilities .
the modelling of the 4 supported states was done after real - life physical machine behaviour in the clouds of the university of innsbruck and mta sztaki .
the real - life behaviour of the machines was observed through constantly monitoring their instantaneous power draw while they went through the following cycle : idling @xmath102 shutdown @xmath102 off @xmath102 switch on @xmath102 idling @xmath102 full cpu load .
a sample measurement with a typical cloud node at innsbruck ( with 80 cpu cores , 128 gb ssd , 132 gb ram , and redundant power supplies ) can be seen in figure  [ fig - pmbehaviour ] . as physical machine state schedulers can be highly influenced by the behaviour in non - running states ( e.g. , their decision on shutting off a machine could be dependent on the time it takes to boot the machine back and the expected power savings because of the completely off machine ) , dissect - cf offers a simplified and a more complex behaviour model .    .simplified power state definition of a physical machine[tab - simpli ] [ cols="<,<,<,<,<",options="header " , ]     during the performance evaluation , all parallel tasks of the trace started up in the first 10 seconds ( _ task spread _ ) and had a length variety between 10 - 90 seconds .
the necessary amount of tasks for the 10-second - long simulation runtime is shown in table  [ tab - taskdistrs ] .
each evaluation was ran with different parallel task numbers between ( 1 - 100,000 ) to allow the investigation on how the increasing parallelism changed the performance of the simulators .
the findings are shown in figure  [ fig - pjruntime ] .    as the figure shows , in the case of cloudsim , both its time - shared and space - shared vm scheduler was experimented on .
the time - shared scheduler of cloudsim simulates parallelism , while the space - shared scheduler serialises the arrived tasks so at any given time there is only one task that can utilise the cpu , and the rest are queued until this task is finished .
unfortunately , the time - shared scheduling mechanism of cloudsim is broken ; it lengthens task execution times significantly even in the case of a two - parallel - task setup ( e.g. , a simple setup like the one presented in figure  [ fig - incpartask ] leads to completely different results than one would see in real - life ) on the other hand , the space - shared scheduler provides completely different task completion times ( because of its serialising behaviour ) .
thus the cloudsim related details of the figure are only valid when considering their simulation runtime ; the simulated tasks do not finish at the expected times in either case .    as depicted in the figure , cloudsim - time - shared and groudsim measurements abruptly finish at 1,000 and 50,000 tasks .
for higher levels of parallelism , the runtime of the simulation took more than 8 hours and therefore was cancelled . in the case of cloudsim , the performance penalties mainly originate from its centralised design of data centres ( i.e. , most of the logic and event processing reside in the ` datacenter ` class , and the rest of cloudsim s classes are used for state representation only ) .
groudsim , on the other hand , has a different design issue : it pre calculates all task completion times , puts them into the event queue and thus if a change is needed to them , the whole event queue has to be updated .
finally , for all simulators , the task processing performance shown in the figure is expected to be faster than what one usually would see , because of the large amount of tasks that were executed for gathering data for the figure .
the amount of repeated evaluations allowed the jvm to optimise the runtime behaviour of each simulator for the particular performance evaluation scenario . later on this effect
is excluded from the evaluations .
[ [ performance - influence - of - load - characteristics ] ] performance influence of load characteristics + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    the rest of this sub - section analyses of how the performance of the resource sharing varies depending on changes in task arrival and length characteristics . for this analysis ,
a baseline measurement was collected with no parallel tasks but varying task lengths . than the assumption
was made that from this baseline , the simulators would linearly degrade in performance ( i.e. , two times the parallelism would increase the simulation run time of a single task by two times ) . to compare how linearly a particular simulator behaves under particular load characteristics ,
the following scaling ratio function was designed : @xmath103 where @xmath104 is the scaling ratio , @xmath105 is the kind of simulator , @xmath106 is the chosen range of task length variety ( in the below detailed experiments it was either 10 - 90 s or 200 - 3600 s ) , @xmath107 is the number of parallel tasks , @xmath108 is the task spread ( in particular , 10 s or 200 s were used ) , and @xmath109 is the measurement function that evaluates the particular simulator with the given load characteristics .
figure  [ fig - jobscalingcompare ] compares dissect - cf with the two selected simulators via the scaling ratio function .
the labels of the figure are presented in the following format : @xmath110 ( see eq .
[ eq - scratio ] ) , where @xmath105 is one of ds / gs / cs , which translate to dissect - cf / groudsim / cloudsim , respectively .
the x - axis of the figure shows the increase in @xmath107 .
based on the distribution of the measured scaling values for the different load characteristics , the most tolerant to the change in workload is groudsim , while the least tolerant is cloudsim .
degrading performance in scaling can be also observed for both cloudsim and groudsim . in the case of cloudsim ,
the degradation starts around 10 parallel tasks , and by the time the simulation reaches 50 parallel tasks the simulator becomes worse than linear ( @xmath111 ) . in the case of groudsim ,
the degradation starts around 100 parallel tasks , and becomes worse than linear around 20,000 parallel tasks . in both cases
the early degradation is caused by the data structures and the indirect call structures used ( i.e. often these simulators experience rather deep call stacks during parallel event handling ) .
finally , although it is not visible in this chart , the degradation starts for dissect - cf at around 10,000 parallel tasks , and based on estimates , its scaling becomes worse than linear around 1.5 million parallel tasks .
fortunately , this huge amount of parallelism is unlikely for most simulations . but simulations of some highly under - provisioned systems might need levels of parallelism that could lead to degraded performance even in groudsim .
the figure also reveals that the performance of dissect - cf is more dependent on the task spread , while cloudsim s scaling is limited more by the task length variety . in case of dissect - cf
, the task spread dependency manifests because the simulator executes its resource sharing mechanism only once per @xmath12 , on new resource consumption arrivals and departures ( see figure  [ fig - rs ] for details ) .
however , the increased task spread decreases the likelihood that the resource sharing mechanism can be executed on multiple resource consumptions at once .
therefore , the wider the spread the closer one gets to the worst possible resource sharing performance in dissect - cf .
in fact , the 200 s long spread was used because this spread is already high enough to reveal close - to - worst - case performance . increasing
the spread further did not introduce significant resource sharing performance drops , but its impact on cloudsim based simulations rendered the evaluation of the 1,000 parallel task experiment too time consuming .
as synthetic loads often criticised because of their possible bias , dissect - cf was evaluated and compared using workloads that were collected from real - life computing infrastructures .
thus , the evaluation required workload traces with the following characteristics : @xmath0 collected for extensive periods of time ( i.e. , at least a few months long ) to ensure the widest variety of observable load characteristics for the particular infrastructure ; @xmath1 tasks should be described in detail including their resource utilisation and submission , start and completion times ( so even if just task definitions are available , one can still translate them to the kinds of virtual machines the tasks would need for their execution in a cloud environment ) ; and @xmath2 if the traces contain virtual machine management logs , then task allocation details are also necessary to enable the analysis of new scheduling techniques that might aim at reallocating tasks or that would change vm management operations .
based on these requirements , most of the traces ( e.g. , planetlab ) containing virtual machine management logs were not found suitable for the planned comparative study ; the rest of these log based traces are not collected for enough time to be used in large scale experiments .
thus , although these virtual machine management log based traces would be the best candidates for analysing cloud characteristics , their immaturity necessitates to also search amongst traces collected from other large - scale infrastructures like grids .
two appropriate sources were identified : the grid workloads archive ( gwa @xcite ) and the parallel workloads archive .
because both at the university of innsbruck and in mta sztaki , there are earlier good experiences with the processing of gwa traces , this article presents a comparative study of the three selected simulators through the traces downloadable from gwa ( namely : das2 , grid5000 , nordugrid , auvergrid , sharcnet , lcg ) .
[ [ trace - processing ] ] trace processing + + + + + + + + + + + + + + + +    a trace loader was prepared for all three simulators so events were fired every time a task arrives .
every time a new task arrival event is fired , the simulators are programmed to create a virtual machine that will host the task .
once the vm was created the task was instantiated in it according to its definition in the trace file . when the task was completed according to the particular simulator , its hosting vm
was also terminated .
because of the known problems with the time - sharing mechanism in cloudsim , single vms did not receive parallel tasks ( e.g. , by requesting a vm that is sized to host multiple tasks first ) . instead ,
when parallel tasks were needed , multiple vms were created in the simulated cloud infrastructure .
unfortunately , because of a few conceptual differences between dissect - cf and the other analysed simulators , the above - mentioned trace processing technique has several minor differences in their adaptations to the various simulators .
first of all , dissect - cf has a queuing first - fit vm scheduler ( see section  [ sec - hls ] ) that allows users to send vm requests right upon task arrival and wait for the vm scheduler s queuing mechanism to notify them about the vm s running state ( and readiness to receive the task ) .
unfortunately , the rest of the simulators do not offer vm request queuing : they reject vm requests that can not be hosted according to the actual state of the simulated infrastructure . to have a similar behaviour to dissect - cf , either the vm request needs to be resent until it can be fulfilled ( which would introduce an unwanted busy waiting loop ) , or
alternatively one must rely on user - side information .
if the vm request is repeatedly resent , then the other simulators are significantly disadvantaged .
thus , the second approach was used : previously non - servable vms were only re - requested once one of the previous vms have terminated ( i.e. , it was assumed that one can determine the state of all the running vms at a given time instance ) . with this technique
the cpu share of the performance evaluation code ( as measured by java s embedded cpu sampler ) was kept around the same levels as it was for dissect - cf .
tasks , which are utilising several cpu cores in parallel , are modelled in two ways .
first , the simulation tries to request a vm with as many cpu cores as the task needs .
unfortunately , this can not be achieved in cases when even the biggest possible vm is too small for the task s needs . for these huge tasks ,
the simulation requests multiple vms , enough to fulfil the parallelism in the task . in groudsim and
dissect - cf it is possible to request multiple vm instances at once ( e.g. , similarly to how amazon ec2 behaves ) and they will be ensured to be available in parallel . on the other hand , cloudsim does not have such functionality ; therefore it was extended with a technique that only submits the tasks to their virtual machines once all necessary vms are available for the level of parallelism needed for the task .    as groudsim is more focused on the user - side behaviour of cloud infrastructures
, it has several deficiencies compared to the other two evaluated simulators : @xmath0 it can only handle tasks that occupy a single cpu core , @xmath1 its network sharing mechanism could result in network under utilisation if the communicating parties are using connections with different bandwidths and @xmath2 it does not provide data centre level simulation details
e.g. , no vm / pm scheduling and pm level resource sharing is simulated . to overcome the first deficiency ,
multi - core tasks are simulated as several single core tasks in the same groudsim virtual machine . to avoid the problem with network sharing , the simulated data centres in all three simulators
were constructed on such a way that every node was connected with the same bandwidth to the others .
unfortunately , without significantly changing groudsim s code it was not possible to add the missing data centre level simulation details .
thus , during the performance analysis one should keep in mind that these details are not simulated in groudsim .
finally , for both groudsim and cloudsim , the instantiation time of a virtual machine is instantaneous , which is not realistic . as the transfer of the vm image is often the most time consuming operation in the vm instantiation procedure  @xcite ,
this transfer was simulated with a download operation to the vm with both of the simulators . in groudsim
, a network transfer was initiated right after the vm was created and this transfer delayed the creation of the task on the vm until the transfer s completion . in cloudsim , cloudlets ( computing tasks in cloudsim terminology ) could have input files defined for them .
thus , tasks in cloudsim were specified so they must transfer an input file with the size of the vm image before they can start their processing .
unfortunately , even with input files specified , the vms in cloudsim start immediately and execute their tasks right after the vm is created .
this means that cloudsim based simulations can not be as accurate as the other two simulator s results . in order to reduce the impact of vm image transfer on task execution times  and to allow all three simulations to have a similar simulation completion time  , the size of the vm image was set to 100 mb ( which is the size of a rather small image nowadays ) .    [ [ the - simulated - virtual - infrastructure ] ] the simulated virtual infrastructure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    in all three simulators , a single kind of physical machine acted as the foundation of the simulated infrastructure .
this physical machine was modelled after a single node in mta sztaki s cloud and had the following properties : @xmath0 64 cpu cores , @xmath1 256 gb ram , @xmath2 5 tb local disk , and @xmath79 two 1 gb / s ethernet connection .
in the experiments detailed below , it was possible to define how many of these machines should be in the data centre .
the set up of the machines includes the creation of a network interconnecting all of them with a central switch .
[ [ the - runtime - comparison - experiment ] ] the runtime comparison experiment + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    for the first experiment the simulated infrastructure was set up so it was sufficient to host even the largest parallelism a single task of the traces could request ( i.e. , no task has had to be dropped because there were not enough physical machines to host its level of parallelism ) .
in particular , this experiment required the simulation of 20 physical machines with the above - mentioned properties . on this infrastructure , the first @xmath112 tasks from a particular trace
were submitted .
then , a measurement was initiated for the real time passed between the submission of the first task and the completion of the last one .
the infrastructure preparation , task submission and time measurement operations were repeated 10 times , each time starting with a new jvm . then , the trace specific average simulation duration for the measurement of @xmath113 tasks was calculated .
afterwards , the whole measurement procedure was repeated for the remaining traces .
finally , the _ aggregated simulation duration _ was calculated for @xmath113 tasks by averaging the trace specific averages from all traces .
later , the aggregated simulation duration is referred as @xmath114 ( where @xmath105 is the measured simulator , @xmath107 is the number of tasks , @xmath115 is the number of physical machines to simulate and @xmath116 ) .
figure  [ fig - runtimecompare ] presents these aggregated simulation durations while the number of tasks
@xmath107  were changed from a hundred to a million . as the measurements ran with a cold jvm , for the first 10,000 tasks one can see that the jvm s effects on the start - up dominate the runtimes .
the first workload related differences of the simulators can be seen after the jvm s behaviour is no longer a significant contributor to the measurement .
also , despite dissect - cf s focus on the internals of the infrastructure , its performance is always better than that of the other two simulators .
this is especially apparent after around 200,000 tasks . in spite of groudsim doing the lightest - weight simulation
( see the deficiencies listed in the previous paragraphs ) , it is still significantly and consistently slower ( albeit in some cases  like the lcg trace  groudsim performs consistently better ) .
the figure also shows that groudsim s network simulation code gives around 21% overhead for lower task counts , and for higher task counts the overhead could grow as high as 109% .
this difference experienced during the network simulation is caused by groudsim s sub - par network modelling ( i.e. , for a single transfer to occur there are several events that needs to be handled in the event system , and in case of parallel transfers these events must be refreshed in the future event queue ) .
[ [ the - scalability - experiment ] ] the scalability experiment + + + + + + + + + + + + + + + + + + + + + + + + + +    to determine the scalability of the compared simulators , the previous experiment was repeated with varying sizes of infrastructure under them .
thus , these experiments will not only be able to pinpoint how the various simulators deal with the increasing amounts of tasks and virtual machines , but also how the simulators cope with increasing size of infrastructures .
infrastructures as small as a single physical machine were used but the experiments were reaching to the size of 500 machines . as even smaller infrastructures were evaluated than 20 machines ( which was the minimum for the level of parallelism found in some of the traces ) , there were tasks that could not fit to the infrastructures .
these tasks were automatically filtered out by the trace processor and never reached the simulation .
interestingly , even with the simulation with a single machine the filtered out tasks were never more than 6% of the total number of tasks in any of the traces .
of course , the single machine still caused a significant serialising effect that lengthened the total execution time of the rest of the tasks .
similarly to eq .
[ eq - scratio ] , the scalability of the simulators was calculated compared to linear scaling .
figure  [ fig - scalingcompare ] presents how the various simulators scale under a particular number of physical machines .
the figure is composed of twelve sub - charts , each delimited with a black line . between the black lines
a large bidirectional arrow contains the title of a sub - chart .
the title shows the number of tasks for which the final runtime measurement values were compared .
for example : the title `` _ _ 100 - 200 tasks _ _ '' means the sub - chart shows how the final runtime measurement value of 200 tasks compares to the value of 100 tasks .
the comparison is made according to the following equation : @xmath117 where @xmath118 , @xmath119 is the number of tasks for which the aggregated simulation duration is evaluated , @xmath105 is one of the evaluated simulators and @xmath115 is the physical machine count .
thus , @xmath120 will become one if the particular simulator scales linearly in the task number range of @xmath118 and @xmath119 .
if the scaling function above is lower than one then the particular simulator is worse than linear .
according to the sub - charts in figure  [ fig - scalingcompare ] all simulators scale significantly better than linear with fewer than 10,000 tasks ( again , this is mostly due to the jvm s class loading and start - up mechanism , since practically all measurements under this task count result in sub - second runtimes ) .
afterwards , one can see that cloudsim is already scaling significantly worse than the other two investigated simulators , and by 50,000 tasks cloudsim already drops below linear scaling .
it can be also observed that simulators handle the number of parallel machines completely differently . in the case of cloudsim , the bigger the machine number , the more likely that the scaling factor will become lower . in the case of groudsim ,
the opposite behaviour is observed ; while for dissect - cf , one can see a rather balanced case . in conclusion , groudsim behaves as expected : the missing simulation of physical machine behaviour and vm / pm scheduling techniques allows it to behave practically independently from infrastructure size . in this sense ,
cloudsim and dissect - cf should behave more closely to each other .
unfortunately , the problematic implementation of cloudsim s time - shared vm scheduler ( see section  [ sec - syntheval ] ) changes its apparent behaviour and reduces the similarities in the trends between dissect - cf and cloudsim . to conclude , dissect - cf scales comparably to other state - of - the - art simulators ( in fact it never drops below linear scaling , in contrast to the others ) while it offers significantly more detailed infrastructure level behaviour .    this experiment was also used to _ validate the results of dissect - cf _ through a comparison with the other simulators . as the first step of validation ,
the simulator reported completion time of the last task in every trace specific measurement was collected ( from @xmath114  where @xmath107 was set between one and a million , and @xmath115 between one and five hundred ) .
then , these task completion times were compared with each other .
the median of the difference between the simulators was less than 0.001% ( the average difference from the median was 2.15% ) .
the biggest differences occurred with simulated infrastructures containing the lowest number of physical machines : in such cases the median of difference between the simulators jumped to a little more than 0.29% ( with a sample standard deviation of 7.21% ) .
the reason behind such a great deviation is the magnified effect of virtual machine instantiation simulation ( i.e. , as vms can only be instantiated on a single pm , they are mostly created and destroyed in a serial fashion ) .
[ [ the - impact - of - energy - metering ] ] the impact of energy metering + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    so far , all presented measurements were executed without energy meters attached to the resource spreaders of dissect - cf . as energy metering is not available in groudsim
, the other two simulators would have suffered a disadvantage because of their ongoing metering simulation .
as dissect - cf was consequently a better performer than the other two simulators , its further evaluation was focused on how one could set up energy metering in order to get comparable performance to the other simulators meter - less operation .
figure  [ fig - energyperformancedrop ] analyses the performance drop of dissect - cf observed when energy metering was requested for the complete simulated infrastructure with 20 physical machines . just as before ,
the function @xmath121 was evaluated , but now instead of comparing dissect - cf to other simulators , the comparison was made between the newly received values to values from the previously presented simulations without energy metering . adding energy metering leads to significant performance differences between the various gwa traces . to show what is the possible performance degradation range in the various traces , the two extreme cases ( the best and worst performing ones ) are revealed in the figure .
the presented cases show that selecting the energy measurement interval is crucial for well performing simulations . in general it
is not recommended to use energy measurement intervals below one minute for long running simulations
i.e. , where the trace s length is over a few thousand tasks .
if higher precision is needed , then selective metering techniques should be used that evaluate energy meters for only the necessary parts of the infrastructure ; otherwise , one could experience a slowdown of over 50 times compared to meter - less runtimes .
finally , in figure  [ fig - energyequivalence ] , a comparison is shown about the performance drop caused by the metering to the meter - less setups of other simulators .
the figure shows what the metering interval is  despite the resulting performance drop  that still provides equivalent performance to other simulators .
as the figure shows , the performance drop also depends on the number of physical machines in the simulated infrastructure .
overall , if energy metering is desired on the entire simulated infrastructure , the metering interval must be set to at least five - seconds to receive comparable performance to cloudsim .
in contrast , groudsim s performance can be matched with a metering interval around 25 - 30 seconds .
anything above these values will give a performance advantage to dissect - cf .
on the other hand , metering intervals below these values could still cause a better performing dissect - cf but this is highly dependent on the particular trace or virtual machine request pattern used during simulations .
this article outlined several iaas related schedulers that could be further improved with the use of cloud simulators .
then , it has shown that current simulators barely meet the demands of the scheduling oriented researchers : @xmath0 they often limit the accessibility of information , @xmath1 they often hide the internal details of iaas systems , @xmath2 they frequently perform poorly in large - scale simulations , and @xmath79 they provide scarcely any options for introducing new energy management techniques inside iaas clouds . to overcome these issues ,
the article has proposed a new simulator called dissect - cf .
the proposed simulator targets information accessibility issues with open apis and monitoring and performance related customisable events .
the internal details of the cloud systems are also accessible , allowing simulation developers : @xmath0 to construct clouds in novel ways ( e.g. , introduction of new physical machine - virtual machine interaction techniques or cloud organisation topologies ) , and @xmath1 to experiment with new cloud side behaviour ( e.g. , new vm schedulers , power states ) .
dissect - cf utilises a new unified resource sharing mechanism that allows centralised performance optimisations and ensures scaling independently of the size of the infrastructure and the amount of tasks processed by the simulated system .
finally , the new simulator deeply integrates energy metering techniques ( ranging from resource usage counters and energy consumption models to meter aggregators ) .
these techniques not only allow further extensions but they allow selective and composite power metering to ensure minimal performance drops during the metering sessions .
the new simulator was evaluated by comparing it to small - scale but real - life environments . during this evaluation
, it was presented how one should model cpu and memory intensive tasks , and it was also shown that the accuracy of the simulator s energy metering technique is also dependent on the new unified resource sharing mechanism .
experiments shown that the relative error of the new resource sharing technique is around 1% in most cases . after the small - scale evaluation , dissect - cf was compared with two state - of - the - art simulators ( namely cloudsim and groudsim ) .
the comparisons were focused on the scaling and performance characteristics of the simulators .
the results revealed that these simulators often produce inaccurate results , while the new simulator not only provided more accurate outputs but also offered better performance .
future research will consider several areas .
first , there are plans to look how the simulator s resource sharing accuracy could be improved with stochastic sharing models and new low - level scheduling techniques .
next , support for more complex network topologies and additional node types ( e.g. , routers and switches ) will also be prepared . as the current simulator merely provides raw data for user - side schedulers ,
an investigation of the necessary constructs and optimisations to better support the development and analysis of these schedulers also needs to be done .
finally , memory behaviour is practically neglected in the current simulator , because applications and openly available traces do not offer any details on this . in the future
, a task level complex memory model is expected to be delivered that not only considers memory bandwidth utilisation but also access patterns . with this model
the simulator s target could include accurate live migration support .
this article described the behaviour and features of dissect - cf version 0.9.5 .
the source code of the simulator is open and available ( under the licensing terms of the gnu lesser general public license 3 ) at the following website :    https://github.com/kecskemeti/dissect-cf .
this work was partially supported by european union s horizon 2020 research and innovation programme under grant agreement no 644179 ( entice ) as well as by the cost program action ic1305 : network for sustainable ultrascale computing ( nesus ) , finally the research has also received partial funding from the austrian science fund project trp 237-n23 .
a.  ahmed and a.s .
cloud computing simulators : a detailed survey and future direction . in _
advance computing conference ( iacc ) , 2014 ieee international _ , pages 866872 .
ieee , february 2014 .
doi:10.1109/iadcc.2014.6779436 .
w.  zhao , y.  peng , f.  xie , z.  dai , modeling and simulation of cloud computing : a review , in : ieee asia pacific cloud computing congress ( apcloudcc ) , ieee , shenzhen , 2012 , pp . 2024 .
doi:10.1109/apcloudcc.2012.6486505 .
t.  hirofuchi , a.  lbre , adding virtual machine abstractions into simgrid : a first step toward the simulation of infrastructure - as - a - service concerns , in : third international conference on cloud and green computing ( cgc ) , ieee , karlsruhe , germany , 2013 , pp . 175180 .
doi:10.1109/cgc.2013.33 .
a.  nez , j.  l. vzquez - poletti , a.  c. caminero , j.  carretero , i.  m. llorente , design of a new cloud computing simulation platform , in : computational science and its applications - iccsa 2011 , vol .
6784 of lecture notes in computer science , springer , santander , spain , 2011 , pp . 582593 .
doi:10.1007/978 - 3 - 642 - 21931 - 3_45 .
k.  kurowski , a.  oleksiak , w.  pikatek , t.  piontek , a.  przybyszewski , j.  wkeglarz , dcworms  a tool for simulation of energy efficiency in distributed computing infrastructures , simulation modelling practice and theory 39 ( 2013 ) 135151 .
doi:10.1016/j.simpat.2013.08.007 .
d.  kliazovich , p.  bouvry , y.  audzevich , s.  khan , greencloud : a packet - level simulator of energy - aware cloud computing data centers , in : global telecommunications conference ( globecom 2010 ) , 2010 , pp . 15 .
doi:10.1109/glocom.2010.5683561 .
r.  n. calheiros , r.  ranjan , a.  beloglazov , c.  a. de  rose , r.  buyya , cloudsim : a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms , software : practice and experience 41  ( 1 ) ( 2011 ) 2350 .
doi:10.1002/spe.995 .
s.  ostermann , k.  plankensteiner , r.  prodan , t.  fahringer , groudsim : an event - based simulation framework for computational grids and clouds , in : euro - par 2010 parallel processing workshops , vol .
6586 of lecture notes in computer science , springer , 2011 , pp . 305313 .
doi:10.1007/978 - 3 - 642 - 21878 - 1_38 .
velho , l.  m. schnorr , h.  casanova , a.  legrand , on the validity of flow - level tcp network models for grid and cloud simulations , acm transactions on modeling and computer simulation ( tomacs ) 23  ( 4 ) ( 2013 ) 23 .
doi:10.1145/2517448 .
p.  velho , a.  legrand , accuracy study and improvement of network simulation in the simgrid framework , in : proceedings of the 2nd international conference on simulation tools and techniques , icst ( institute for computer sciences , social - informatics and telecommunications engineering ) , 2009 , p.  13 .
doi:10.4108/icst.simutools2009.5592 .
r.  sobie , a.  agarwal , i.  gable , c.  leavett - brown , m.  paterson , r.  taylor , a.  charbonneau , r.  impey , w.  podiama , htc scientific computing in a distributed cloud environment , in : proceedings of the 4th acm workshop on scientific cloud computing , science cloud 13 , acm , new york , ny , usa , 2013 , pp .
doi:10.1145/2465848.2465850 .
h.  song , j.  li , x.  liu , idlecached : an idle resource cached dynamic scheduling algorithm in cloud computing , in : 9th international conference on ubiquitous intelligence computing and 9th international conference on autonomic trusted computing ( uic / atc ) , 2012 , pp . 912917 .
doi:10.1109/uic - atc.2012.24 .
m.  rodrguez , d.  tapiador , j.  fontn , e.  huedo , r.  montero , i.  llorente , dynamic provisioning of virtual clusters for grid computing , in : e.  csar , m.  alexander , a.  streit , j.  trff , c.  crin , a.  knpfer , d.  kranzlmller , s.  jha ( eds . ) , euro - par 2008 workshops - parallel processing , vol .
5415 of lecture notes in computer science , springer berlin heidelberg , 2009 , pp .
doi:10.1007/978 - 3 - 642 - 00955 - 6_4 .
b.  sotomayor , k.  keahey , i.  foster , combining batch execution and leasing using virtual machines , in : proceedings of the 17th international symposium on high performance distributed computing , hpdc 08 , acm , new york , ny , usa , 2008 , pp .
doi:10.1145/1383422.1383434 .
j.  tordsson , r.  s. montero , r.  moreno - vozmediano , i.  m. llorente , cloud brokering mechanisms for optimized placement of virtual machines across multiple providers , future generation computer systems 28  ( 2 ) ( 2012 ) 358  367 .
doi:10.1016/j.future.2011.07.003 .
e.  elmroth , l.  larsson , interfaces for placement , migration , and monitoring of virtual machines in federated clouds , in : eighth international conference on grid and cooperative computing .
gcc 09 . , 2009 ,
doi:10.1109/gcc.2009.36 .
k.  tsakalozos , m.  roussopoulos , a.  delis , vm placement in non - homogeneous iaas - clouds , in : g.  kappel , z.  maamar , h.  motahari - nezhad ( eds . ) , service - oriented computing , vol .
7084 of lecture notes in computer science , springer berlin heidelberg , 2011 , pp . 172187 .
doi:10.1007/978 - 3 - 642 - 25535 - 9_12 .
d.  jayasinghe , c.  pu , t.  eilam , m.  steinder , i.  whally , e.  snible , improving performance and availability of services hosted on iaas clouds with structural constraint - aware virtual machine placement , in : ieee international conference on services computing ( scc ) , 2011 , pp .
doi:10.1109/scc.2011.28 .
r.  ghosh , v.  naik , k.  trivedi , power - performance trade - offs in iaas cloud : a scalable analytic approach , in : ieee / ifip 41st international conference on dependable systems and networks workshops ( dsn - w ) , 2011 , pp .
doi:10.1109/dsnw.2011.5958802 .
e.  feller , c.  rohr , d.  margery , c.  morin , energy management in iaas clouds : a holistic approach , in : ieee 5th international conference on cloud computing ( cloud ) , 2012 , pp .
doi:10.1109/cloud.2012.50 .
lizhe wang , samee  u. khan , dan chen , joanna kolodziej , rajiv ranjan , cheng zhong xu , and albert zomaya .
energy - aware parallel task scheduling in a cluster .
, 29(7):1661  1670 , september 2013 .
including special sections : cyber - enabled distributed computing for ubiquitous cloud and network services & amp ; cloud computing and scientific applications  big data , scalable analytics , and beyond .
doi:10.1016/j.future.2013.02.010 .
d.  ongaro , a.  l. cox , s.  rixner , scheduling i / o in virtual machine monitors , in : proceedings of the fourth acm sigplan / sigops international conference on virtual execution environments , vee 08 , acm , new york , ny , usa , 2008 , pp .
doi:10.1145/1346256.1346258 .
g.  von laszewski , l.  wang , a.  younge , x.  he , power - aware scheduling of virtual machines in dvfs - enabled clusters , in : ieee international conference on cluster computing and workshops .
cluster 09 .
, 2009 , pp .
doi:10.1109/clustr.2009.5289182 .
j.  yang , x.  zhou , m.  chrobak , y.  zhang , l.  jin , dynamic thermal management through task scheduling , in : ieee international symposium on performance analysis of systems and software .
ispass 2008 . , 2008 , pp .
doi:10.1109/ispass.2008.4510751 .
r.  buyya , r.  ranjan , r.  n. calheiros , modeling and simulation of scalable cloud computing environments and the cloudsim toolkit : challenges and opportunities , in : international conference on high performance computing & simulation ( hpcs09 ) . ,
ieee , leipzig , 2009 , pp .
doi:10.1109/hpcsim.2009.5192685 .
r.  buyya , m.  murshed , gridsim : a toolkit for the modeling and simulation of distributed resource management and scheduling for grid computing , concurrency and computation : practice and experience 14  ( 13 - 15 ) ( 2002 ) 11751220 .
doi:10.1002/cpe.710 .
s.  k. garg , r.  buyya , networkcloudsim : modelling parallel applications in cloud simulations , in : fourth ieee international conference on utility and cloud computing ( ucc ) , ieee , victoria , nsw , 2011 , pp .
doi:10.1109/ucc.2011.24 .
a.  beloglazov , r.  buyya , optimal online deterministic algorithms and adaptive heuristics for energy and performance efficient dynamic consolidation of virtual machines in cloud data centers , concurrency and computation : practice and experience 24  ( 13 ) ( 2012 ) 13971420 .
doi:10.1002/cpe.1867 .
tom gurout , thierry monteil , georges  da costa , rodrigo  neves calheiros , rajkumar buyya , and mihai alexandru .
energy - aware simulation with \{dvfs}. , 39:76  91 , december 2013 .
energy efficiency in grids and clouds .
doi:10.1016/j.simpat.2013.04.007 .
x.  li , x.  jiang , p.  huang , k.  ye , dartcsim : an enhanced user - friendly cloud simulation system based on cloudsim with better performance , in : 2nd international conference on cloud computing and intelligent systems ( ccis ) , vol .  1 , ieee , hangzhou , 2012 , pp . 392396
. doi:10.1109/ccis.2012.6664434 .
s.  sotiriadis , n.  bessis , n.  antonopoulos , a.  anjum , simic : designing a new inter - cloud simulation platform for integrating large - scale resource management , in : 27th international conference on advanced information networking and applications ( aina ) , 2013 , pp .
doi:10.1109/aina.2013.123 .
s.  sotiriadis , n.  bessis , n.  antonopoulos , towards inter - cloud simulation performance analysis : exploring service - oriented benchmarks of clouds in simic , in : 27th international conference on advanced information networking and applications workshops ( waina ) , 2013 , pp .
doi:10.1109/waina.2013.196 .
y.  shi , x.  jiang , k.  ye , an energy - efficient scheme for cloud resource provisioning based on cloudsim , in : ieee international conference on cluster computing ( cluster ) , ieee , austin , tx , 2011 , pp .
doi:10.1109/cluster.2011.63 .
alexandru - florian antonescu and torsten braun .
sla - driven simulation of multi - tenant scalable cloud - distributed enterprise information systems . in florin pop and maria potop - butucaru , editors ,
_ adaptive resource management and scheduling for cloud computing _ , lecture notes in computer science , pages 91102 .
springer international publishing , november 2014 .
doi:10.1007/978 - 3 - 319 - 13464 - 2_7 .
b.  wickremasinghe , r.  n. calheiros , r.  buyya , cloudanalyst : a cloudsim - based visual modeller for analysing cloud computing environments and applications , in : 24th ieee international conference on advanced information networking and applications ( aina ) , ieee , 2010 , pp .
doi:10.1109/aina.2010.32 .
thiago teixeira  s , rodrigo  n. calheiros , and danielo  g. gomes . .
in zaigham mahmood , editor , _ cloud computing _ , computer communications and networks , pages 127142 .
springer international publishing , october 2014 .
doi:10.1007/978 - 3 - 319 - 10530 - 7_6 .
h.  casanova , simgrid : a toolkit for the simulation of application scheduling , in : first ieee / acm international symposium on cluster computing and the grid , ieee , brisbane , qld . , 2001 , pp .
doi:10.1109/ccgrid.2001.923223 .
t.  hirofuchi , a.  lbre , l.  pouilloux , et  al . , adding a live migration model into simgrid , one more step toward the simulation of infrastructure - as - a - service concerns , in : 5th ieee international conference on cloud computing technology and science ( ieee cloudcom ) , bristol , uk , 2013 , pp . 96103 .
doi:10.1109/cloudcom.2013.20 .
d.  kliazovich , p.  bouvry , s.  u. khan , greencloud : a packet - level simulator of energy - aware cloud computing data centers , the journal of supercomputing 62  ( 3 ) ( 2012 ) 12631283 .
doi:10.1007/s11227 - 010 - 0504 - 1 .
a.  nez , g.  castane , j.  vazquez - poletti , a.  caminero , j.  carretero , i.  llorente , design of a flexible and scalable hypervisor module for simulating cloud computing environments , in : international symposium on performance evaluation of computer & telecommunication systems ( spects ) , ieee , 2011 , pp .
265270 .
a.  nez , j.  l. vzquez - poletti , a.  c. caminero , g.  g. casta , j.  carretero , i.  m. llorente , icancloud : a flexible and scalable cloud infrastructure simulator , journal of grid computing 10  ( 1 ) ( 2012 ) 185209 .
doi:10.1007/s10723 - 012 - 9208 - 5 .
s.  ostermann , k.  plankensteiner , d.  bodner , g.  kraler , r.  prodan , integration of an event - based simulation framework into a scientific workflow execution environment for grids and clouds , in : towards a service - based internet , vol .
6994 of lecture notes in computer science , springer , poznan , poland , 2011 , pp . 113 .
doi:10.1007/978 - 3 - 642 - 24755 - 2_1 .
i.  sriram , speci , a simulation tool exploring cloud - scale data centres , in : cloud computing , vol .
5931 of lecture notes in computer science , springer , 2009 , pp .
doi:10.1007/978 - 3 - 642 - 10665 - 1_35 .
m.  tighe , g.  keller , m.  bauer , h.  lutfiyya , dcsim : a data centre simulation tool for evaluating dynamic virtualized resource management , in : 8th international conference on network and service management ( cnsm ) , ieee , 2012 , pp .
385392 .
w.  piatek , dcworms  a tool for simulation of energy efficiency in data centers , in : energy efficiency in large scale distributed systems , vol .
8046 of lecture notes in computer science , springer , 2013 , pp . 118124 .
doi:10.1007/978 - 3 - 642 - 40517 - 4_11 .
m.  tighe , g.  keller , j.  shamy , m.  bauer , h.  lutfiyya , towards an improved data centre simulation with dcsim , in : proceedings of the 9th international conference on network and service management , cnsm 2013 , ieee , zurich , switzerland , 2013 , pp .
doi:10.1109/cnsm.2013.6727859 .
g.  kecskemeti , foundations of efficient virtual appliance based service deployments : new techniques for virtual appliance delivery and size optimization in infrastructure as a service clouds , isbn : 978 - 3 - 8484 - 0383 - 7 , lap lambert academic publishing , saarbrcken , 2012 .