| Age | Commit message (Collapse) | Author |
|---|
|
This change updates reimplements the performance interference model to
work on top of the universal resource model in
`opendc-simulator-resources`. This enables us to model interference and
performance variability of other resources such as disk or network in
the future.
|
|
This change adds initial support for storage devices in the OpenDC
simulator. Currently, we focus on local disks attached to the machine.
In the future, we plan to support networked storage devices using the
networking support in OpenDC.
|
|
This change bridges the compute and network simulation module by
adding support for network adapters in the compute module. With these
network adapters, compute workloads can communicate over the network
that the adapters are connected to.
|
|
This change re-organizes the classes of the compute simulator module to
make a clearer distinction between the hardware, firmware and software
interfaces in this module.
|
|
This change adds the CPU frequency scaling governors including the conservative and on-demand governors that are found in the Linux kernel.
# Implementation Notes
* A `ScalingPolicy` has been added to aid the frequency scaling process.
|
|
This change adds the CPU frequency scaling governors that are found in
the Linux kernel, which include the conservative and on-demand governor.
|
|
This pull request adds a subsystem to OpenDC for modelling power components in datacenters,
such as UPSes, PDUs and PSUs.
These components also take into account electrical losses that occur in real-world scenarios.
- Add module for datacenter power components (UPS, PDU)
- Integrate power subsystem with compute subsystem (PSU)
- Model power loss in power components
**Breaking API Changes**
1. `SimBareMetalMachine.powerDraw` is replaced by `SimBareMetalMachine.psu.powerDraw`
|
|
This change introduces power loss to the PSU component.
|
|
This change integrates the power subsystem of the simulator with the
compute subsystem by exposing a new field on a SimBareMetalMachine, psu,
which provides access to the machine's PSU, which in turn can be
connected to a SimPowerOutlet.
|
|
This change introduces a memory resource which can be used to model
memory usage. The SimMachineContext now exposes a memory field of type
SimMemory which provides access to this resource and allows workloads to
start a consumer on this resource.
|
|
This change moves the CPU frequency scaling governors from the
bare-metal/firmware layer (SimBareMetalMachine) to the OS/Hypervisor
layer (SimHypervisor) where it can make more informed decisions about
the CPU frequency based on the load of the operating system or
hypervisor.
|
|
This change splits the functionality present in the CPUFreq subsystem of
the compute simulation. Currently, the DVFS functionality is embedded in
SimBareMetalMachine. However, this functionality should not exist within
the firmware layer of a machine. Instead, the operating system should
perform this logic (in OpenDC this should be the hypervisor).
Furthermore, this change moves the scaling driver into the power
package. The power driver is a machine/firmware specific implementation
that computes the power consumption of a machine.
|
|
This change adds a new interface to the resources library for accessing
metrics of resources such as work, demand and overcommitted work. With
this change, we do not need an implementation specific listener
interface in SimResourceSwitchMaxMin anymore.
Another benefit of this approach is that updates will be scheduled more
efficiently and progress will only be reported once the system has
reached a steady-state for that timestamp.
|
|
This change introduces the SimResourceInterpreter which centralizes the
logic for scheduling and interpreting the communication between resource
consumer and provider.
This approach offers better performance due to avoiding invalidating the
state of the resource context when not necessary. Benchmarks show in the
best case a 5x performance improvement and at worst a 2x improvement.
|
|
This change introduces the SimResourceScheduler interface, which is a
generic interface for scheduling the coordination and synchronization
between resource providers and resource consumers.
This interface replaces the need for users to manually specify the clock
and coroutine context per resource provider.
|
|
This change updates the project structure to become flattened.
Previously, the simulator, frontend and API each lived into their own
directory.
With this change, all modules of the project live in the top-level
directory of the repository. This should improve discoverability of
modules of the project.
|
