GPUShare

GPUShare is an OMNeT++ discrete-event simulation of GPU pooling and short-term leasing across a segmented campus network. GPU hosts advertise their capacity, a central scheduler assigns queued jobs to available hosts, and clients record end-to-end job completion time (JCT). The project implements its network and control-plane modules directly with OMNeT++; it does not depend on the INET Framework.

The included experiments compare the system with no background traffic and with light, medium, or heavy burst traffic. They record GPU utilization, scheduler queue length, JCT, routed traffic, and per-bus traffic volume.

Contents

• Features
• Architecture
• How a job is processed
• Requirements
• Getting started
• Simulation scenarios
• Configuration
• Results and analysis
• Project structure
• Model scope and limitations
• Documentation
• Contributing
• License

Features

• Custom VLAN-like broadcast bus with propagation and frame serialization delay
• Two network segments connected by a configurable-delay router
• Periodic GPU capacity beacons from heterogeneous hosts
• Central FIFO job queue and capacity-aware host selection
• Exponentially distributed job inter-arrival and service times
• Lease grant, job start, and job completion protocol messages
• Configurable burst traffic with packet size, rate, burst size, and flow count controls
• Qtenv support for interactive runs and Cmdenv support for repeatable batch runs
• OMNeT++ scalar, vector, histogram, count, sum, and time-average statistics
• Python analysis that produces comparison plots and a CSV summary
• Smaller smoke scenarios for testing individual modules before running the complete model

Architecture

The complete scenario contains four GPU hosts and four clients across two 100 Mbps segments. The scheduler resides on VLAN 10, while the router makes hosts and clients on VLAN 20 visible to the shared control plane.

flowchart LR
    subgraph V10["VLAN 10"]
        direction TB
        C10["Job clients 1-2"]
        H10["GPU hosts 10-11"]
        S["Central scheduler 100"]
        B10(("100 Mbps VlanBus"))
        F10["Optional burst flows"]
        C10 --- B10
        H10 --- B10
        S --- B10
        F10 --- B10
    end

    R["Router 200<br/>50 microsecond forwarding delay"]

    subgraph V20["VLAN 20"]
        direction TB
        B20(("100 Mbps VlanBus"))
        C20["Job clients 21-22"]
        H20["GPU hosts 30-31"]
        F20["Optional burst flows"]
        B20 --- C20
        B20 --- H20
        B20 --- F20
    end

    B10 --- R --- B20

Loading

Core modules

Module	Responsibility
VlanBus	Broadcasts each incoming frame to every port except the sender and accounts for frame-size serialization delay.
Router	Forwards frames between VLAN 10 and VLAN 20 after a configurable delay.
GPUHost	Advertises total/free slots, accepts assigned leases, executes jobs, and reports completion.
Scheduler	Learns host capacity from beacons, queues requests, selects a host, and issues leases.
JobClient	Generates jobs, tracks grants, and records JCT from submission through completion.
BackgroundFlow	Emits configurable bursts of DataPkt messages to add network load.

Protocol messages

All messages extend LanFrame, which carries source and destination addresses, a VLAN ID, and a frame type.

Message	Type	Modeled size	Purpose
Beacon	1	64 B	Advertise a GPU host's total and free slots.
JobRequest	2	96 B	Submit a job, requested duration, and GPU requirement.
LeaseGrant	3	80 B	Tell the client and selected host about an assignment.
JobStart	4	72 B	Acknowledge that the host started the job.
JobDone	5	72 B	Broadcast job completion to the originating client.
DataPkt	6	Configurable	Generate background network load.

How a job is processed

sequenceDiagram
    participant C as JobClient
    participant S as Scheduler
    participant H as GPUHost

    H-->>S: Periodic Beacon (free slots)
    C->>S: JobRequest
    Note over S: Enqueue request and select<br/>a host with sufficient capacity
    S-->>C: LeaseGrant
    S->>H: LeaseGrant
    H-->>S: JobStart acknowledgement
    Note over H: Reserve a slot and run<br/>for the lease duration
    H-->>C: JobDone (broadcast)
    Note over C: JCT = completion time - submit time

Loading

The supplied configurations use the leastLoaded policy, which selects the eligible host with the most free slots. Requests remain FIFO in the scheduler queue when no host currently has enough advertised capacity.

Requirements

Simulation

• OMNeT++ 6.2.0 with its bundled C++ toolchain
• GNU Make and the OMNeT++ command-line tools on PATH
• A shell from the configured OMNeT++ environment

The repository was configured and tested as an OMNeT++ IDE project on Windows. The generated makefiles and simulation wrapper also support the usual OMNeT++ command-line workflow.

Optional analysis

• Python 3.9 or newer
• pandas, matplotlib, and numpy

Install the analysis dependencies with:

python -m pip install pandas matplotlib numpy

Getting started

1. Clone the repository

git clone https://github.com/Mofazzal874/gpu_share.git
cd gpu_share

Run the remaining commands from an OMNeT++ terminal so that tools such as opp_makemake and the OMNeT++ runtime libraries are available.

2. Build

The repository contains a generated src/Makefile, so a normal build from the project root is:

make -j4

Regenerate the makefile after adding or removing C++, NED, or message files:

cd src
opp_makemake -f --deep -I.
make -j4
cd ..

To remove compiled output:

make clean

In the OMNeT++ IDE, import the repository as an existing project and use Project > Build Project. The checked-in .project, .cproject, .oppbuildspec, and .nedfolders files contain the project configuration.

3. Run the complete experiment

The simulations/run wrapper supplies the required NED search paths. From an OMNeT++ shell:

cd simulations
./run -f gpu_share_background/omnetpp.ini -c NoBackground -u Qtenv

Replace Qtenv with Cmdenv for a non-interactive run:

./run -f gpu_share_background/omnetpp.ini -c HeavyBackground -u Cmdenv

To run all configurations and their three seeded repetitions, omit -c:

./run -f gpu_share_background/omnetpp.ini -u Cmdenv

From the IDE, right-click simulations/gpu_share_background/omnetpp.ini, select Run As > OMNeT++ Simulation, and choose a configuration.

Simulation scenarios

Scenario	Configuration	Purpose
scaffold_test	General	Verify the project scaffold and simple-module loading.
vlan_smoke	General	Verify VLAN bus broadcast and serialization behavior.
gpu_host_test	General	Verify GPU host beacon generation.
gpu_share_min	GPUShareMin_Basic	Exercise the single-VLAN end-to-end job lifecycle.
gpu_share_two_vlan	TwoVlan_Basic	Exercise normal cross-VLAN GPU sharing.
gpu_share_two_vlan	TwoVlan_HighLoad	Increase job frequency and extend the run to 120 seconds.
gpu_share_two_vlan	TwoVlan_Unbalanced	Put heavier demand on VLAN 20 to exercise cross-VLAN sharing.
gpu_share_background	NoBackground	Establish a 90-second baseline with no burst flows.
gpu_share_background	LightBackground	Add two low-rate 512-byte flows per VLAN.
gpu_share_background	MediumBackground	Add two medium-rate 1024-byte flows per VLAN.
gpu_share_background	HeavyBackground	Add two high-rate 1500-byte flows per VLAN.

Example for another scenario:

cd simulations
./run -f gpu_share_two_vlan/omnetpp.ini -c TwoVlan_Unbalanced -u Qtenv

Configuration

Experiments are configured in each scenario's omnetpp.ini. Frequently adjusted parameters include:

Area	Parameters
GPU capacity	gpuSlots, beaconInterval
Job workload	jobIaMean, jobDurationMean, gpuRequirement, maxJobs, startTime
Scheduling	policy
Network	datarate, channel delay, router forwardingDelay
Background traffic	numBackgroundFlowsPerVlan, burstInterval, burstSize, packetSize, packetInterval, maxBursts
Reproducibility	repeat, seed-set, sim-time-limit

OMNeT++ units are used directly, for example 100Mbps, 50us, 20ms, and 3s. Set a module's debug parameter to false when running large batches to reduce event-log output.

Results and analysis

Runs produce OMNeT++ scalar (.sca), vector (.vec), and vector-index (.vci) files under the configured result directory. Recorded metrics include:

• JCT, jobs submitted, and jobs completed per client
• GPU utilization, beacon count, and completed jobs per host
• Scheduler queue length, grants, and discovered host count
• Frames and bytes processed by each VLAN bus
• Total and directional frames forwarded by the router
• Packets, bytes, and bursts generated by each background flow

After running the four background configurations, generate the plots and summary table from the scenario directory:

cd simulations/gpu_share_background
python analyze_phase5_results.py

The script writes:

• summary_statistics.csv
• plots/jct_comparison.png
• plots/gpu_utilization.png
• plots/queue_length.png

The repository includes a representative summary from the committed result set:

Traffic	Mean JCT	Mean GPU utilization	Mean queue length
None	3.565 s	0.128	0.004
Light	3.549 s	0.122	0.001
Medium	3.549 s	0.122	0.001
Heavy	3.727 s	0.088	0.000

These values are simulation outputs, not general performance guarantees. Rerun the experiment after changing the workload, seeds, topology, or model implementation.

Project structure

gpu_share/
|-- src/
|   |-- gpu/messages/          # LanFrame protocol definitions and generated C++
|   `-- gpu/modules/           # C++ simple modules and their NED declarations
|-- simulations/
|   |-- scaffold_test/         # Basic module-loading smoke test
|   |-- vlan_smoke/            # VLAN broadcast smoke test
|   |-- gpu_host_test/         # Beacon-generation test
|   |-- gpu_share_min/         # Minimal single-VLAN system
|   |-- gpu_share_two_vlan/    # Routed two-VLAN experiments
|   `-- gpu_share_background/  # Full workload, results, plots, and analysis
|-- docs/                      # Phase notes, validation, and test guides
|-- Makefile                   # Project build entry point
`-- project_report.tex         # Detailed project report source

Model scope and limitations

• The VLAN bus is a compact broadcast abstraction, not an IEEE 802.1Q Ethernet implementation.
• The router forwards frames between exactly two modeled segments and does not implement routing tables or IP protocols.
• Background flows generate deterministic packet bursts after their configured start times; they do not implement TCP congestion control, acknowledgements, or retransmission.
• The bundled experiments request one GPU slot per job. Although the scheduler checks gpuRequirement, the current host execution path reserves one slot per lease.
• leastLoaded is the fully implemented selection policy. The accepted roundRobin value currently chooses the eligible host with the lowest ID rather than maintaining a rotating cursor.
• Host liveness is learned from beacons, but stale hosts are not expired.
• The model focuses on control-plane and timing behavior. It does not execute GPU workloads or model GPU memory, compute kernels, power, failures, or data locality.

Documentation

Detailed development records are available in docs/:

• Build and run notes
• VLAN test guide
• Two-VLAN validation
• Background-traffic validation
• Metrics testing guide
• Project questions and analysis

The phase-specific files are retained as implementation history; this README is the current project-level reference.

Contributing

Contributions should keep the C++ implementation, NED declarations, omnetpp.ini parameters, and documentation synchronized.

1. Create a focused branch.
2. Add or update a smoke scenario for behavior changes.
3. Regenerate the OMNeT++ makefile and message classes when their sources change.
4. Build in both the IDE or CLI environment used by the project.
5. Run the affected scenario in Cmdenv and inspect its .sca/.vec outputs.
6. Open a pull request describing the model change and its effect on recorded metrics.

License

No license file is currently included. Unless the repository owner adds one, permission to copy, modify, or redistribute this project is not granted by default.