30 GB network fan-out

t1→t2t3t4→t5

This complete SimGrid experiment makes network sharing visible. t1 produces three 10 GB dependencies. t2, t3, and t4 run concurrently on the three cores of M2, then each sends 10 GB to t5 on M3. The links are shared: a concurrent flow does not receive the full nominal bandwidth on its own.

Use it to inspect how a placement with parallel tasks can still be limited by its network endpoints. Do not treat the 36-second manual-plan estimate as a universal formula for 10 GB/s networks; the observed trace is the authoritative evidence for the configured sharing model.

Model at a glance

Resource	Cores	Activities
M1	1	t1
M2	3	t2, t3, t4 in parallel
M3	1	t5

Every dependency is 10,000,000,000 bytes. There are six dependencies, so a completed run must report 60,000,000,000 transferred bytes. The two bidirectional links are 80 Gbit/s (10 GB/s) and permit three concurrent transfers.

Download the model

Environment YAML ↓Execution scope YAML ↓Network topology YAML ↓Workflow YAML ↓Plan envelope ↓Execution envelope ↓Submission script ↓

AkôFlow Desktop

Explore with AkôFlow Desktop

1. Create a simulation environment with M1 (one core), M2 (three cores), and M3 (one core), and bind SimGrid to each resource.
2. Create the scope and attach the two shared, bidirectional 80 Gbit/s links from topology.yaml.
3. Import workflow.yaml. In its Definition graph, confirm that t1 fans out to three activities and that all three converge on t5.
4. Choose Generate plan. Use Create manually to reproduce the checked-in M1 → M2 → M3 assignment, or use Generate plans to compare PRISM Cost, PRISM Time, and HEFT on the same scope.
5. Expand a candidate Gantt. Verify that `t2`, `t3`, and `t4` occupy different M2 cores; then select the plan and start the simulation.
6. On the completed run, open Data to inspect six transfers and Plan vs execution to compare the 36-second estimate with the observed trace.

API

Register, plan, and execute through the API

From a fresh instance, run the versioned script. It submits the environment, scope, topology, workflow, manual plan, and execution envelope in dependency order:

export AKOFLOW_API_URL="http://127.0.0.1:8080/akoflow-api"
export AKOFLOW_API_TOKEN="<token>"
bash examples/simulation/30gb-fanout/run.sh

Poll the run until it reports completed:

curl -H "Authorization: Bearer $AKOFLOW_API_TOKEN" \
"$AKOFLOW_API_URL/execution-runs/simgrid-30gb-fanout-run-v1/"

Choose the simulation target before selecting algorithms. The two PRISM objectives are exclusive; HEFT remains a baseline candidate for the same frozen workflow and scope.

Verify the result

The current bundle completed on 2026-09-11 as simgrid-30gb-fanout-run-v1. It settled all five activities and recorded six transfers totaling 60,000,000,000 bytes. The observed makespan was 36.495 s; the run stored 50 s of accumulated compute time and 16.237 s of accumulated transfer time.

The trace is useful because it exposes the sharing rather than hiding it in one aggregate number:

• the three M1 → M2 transfers started together at 10 s and each lasted about 3.247 s;
• the M2 → M3 transfers became ready together after the parallel tasks and completed at different times, with the final transfer ending at about 26.495 s;
• t5 then ran for 10 s, giving the observed makespan.

Accumulated stage time is not additional wall-clock time: activities t2, t3, and t4 contribute compute time concurrently. If the run has fewer than six transfers, check that the manual plan still maps M1, M2, and M3 to distinct resources and that all six dataDependencies were retained after import.