Task 4 — Task Distributor | EdgeGuard SS2026

What is Task Distributor?

Task Distributor is a non-MPI parallel tool written by Prof. Dr. Christian Baun (published in SpringerPlus 2016, DOI: 10.1186/s40064-016-2254-x). It distributes a POV-Ray ray-tracing render job across multiple nodes using SSH — each node renders an equal horizontal band of rows and writes its result to a shared NFS path. The master node polls a shared lockfile and stitches all parts together with ImageMagick.

Unlike MPI which launches all processes simultaneously via mpirun, Task Distributor dispatches jobs sequentially via SSH and checks completion sequentially — making the coordination itself a measurable serial fraction, exactly what Amdahl's Law predicts.

ℹ️ Why node-based and not core-based?

Task Distributor is architecturally node-based by design — it dispatches one POV-Ray process per node via SSH. The tool's own README and -n flag explicitly say "number of nodes". This matches Prof. Baun's own published methodology where he used 1, 2, 4, 8 nodes. We followed the same approach.

How It Works — 3 Timing Parts

Task Distributor explicitly reports three timing components per run. This makes the serial and parallel fractions directly measurable — a perfect Amdahl's Law demonstration.

seq1

1st Sequential Part

SSH dispatch to all nodes. Fixed overhead ~0.003s regardless of node count or resolution.

parallel

Parallel Part

Actual POV-Ray rendering on all nodes simultaneously. This is the part that scales with more nodes.

seq2

2nd Sequential Part

ImageMagick stitching of all image parts. Grows with node count as more parts need combining.

textExample output

Required time to process the 1st sequential part:    0.003s  ← SSH dispatch (fixed)
Required time to process the parallel part:          55.134s  ← POV-Ray render (scales)
Required time to process the 2nd sequential part:    0.012s  ← ImageMagick stitch (grows)

Test Setup

Tool

task-distributor

~/task-distributor/task-distributor-master.sh

Renderer

POV-Ray

/usr/bin/povray · benchmark.pov scene

Node counts

1, 2, 4, 8

Node-based (not core-based)

Runs per config

5

Min/max/mean reported

Cooldown

30s

Between runs

Baseline node

pi3-02

~53s render at 3200×2400

Resolution Ladder — Why These Sizes?

We tested a ladder of resolutions from small to large to show the progression from poor scaling (small problem, overhead dominates) to better scaling (large problem, compute dominates) — directly demonstrating Amdahl's and Gustafson's Laws.

400×300

Poor scaling — SSH overhead dominates. 8 nodes SLOWER than 1 node. Clear Amdahl demonstration.

800×600

Slight improvement. Render time still close to dispatch overhead.

1600×1200

Scaling improves. 8 nodes achieves ~1.5× over 1 node.

3200×2400

Best scaling — 8 nodes achieves 1.93×. Compute clearly dominates. Gustafson visible.

4800×3600 ❌

Confirmed failure — POV-Ray intermediate storage needs >453MB tmpfs. Pi3 limit reached.

❌ Memory limit at 4800×3600

POV-Ray writes intermediate .pov-state files to /tmp during rendering. At 4800×3600 this requires more than 453MB — exceeding Pi3's tmpfs limit (half of 1GB RAM). Confirmed independently by another student group in the same course. Maximum feasible resolution: 3200×2400.

How to Reproduce

Pre-Benchmark Setup

bashStep 1 — Stop k3s and mount NFS on all Pi3s

# Stop k3s-agent
for ip in 10.10.10.21 10.10.10.22 10.10.10.23 10.10.10.24 \
          10.10.10.25 10.10.10.26 10.10.10.27 10.10.10.28; do
    ssh admin@$ip "sudo systemctl stop k3s-agent" &
done
wait

# Mount shared NFS (required for lockfile and image parts)
for ip in 10.10.10.21 10.10.10.22 10.10.10.23 10.10.10.24 \
          10.10.10.25 10.10.10.26 10.10.10.27 10.10.10.28; do
    ssh admin@$ip "sudo mkdir -p /nfs/shared && \
        sudo mount -t nfs 10.10.10.1:/nfs/shared /nfs/shared" &
done
wait

bashStep 2 — Clean up before each run

# Always clean lockfile and old image parts before running
rm -f /nfs/shared/povray/lockfile
rm -f /nfs/shared/povray/*.png
rm -f /tmp/output_*.png

# Also clean tmp on all Pi3 nodes
for ip in 10.10.10.21 10.10.10.22 10.10.10.23 10.10.10.24 \
          10.10.10.25 10.10.10.26 10.10.10.27 10.10.10.28; do
    ssh admin@$ip "rm -f /tmp/benchmark*.png /tmp/pov-state* /tmp/pov*" &
done
wait

bashStep 3 — Run Task Distributor

# Replace <NODES> with: 1, 2, 4, or 8
# Replace <WIDTH> x <HEIGHT> with resolution:
#   400x300 | 800x600 | 1600x1200 | 3200x2400

cd ~/task-distributor
./task-distributor-master.sh \
    -n <NODES> \
    -x <WIDTH> \
    -y <HEIGHT> \
    -p /nfs/shared/povray \
    -f -c

# Example: 4 nodes, 1600x1200
./task-distributor-master.sh -n 4 -x 1600 -y 1200 -p /nfs/shared/povray -f -c

# Flags:
#   -n  number of nodes
#   -x  image width
#   -y  image height
#   -p  path for lockfile and image parts (must be NFS)
#   -f  force (overwrite existing lockfile)
#   -c  cleanup after (remove image parts)

Results — Chart Overview

Full results with timing breakdown (seq1, parallel, seq2) per resolution and node count are on the Results page.

📊 td_scaling_all_resolutions.png Total Time vs Node Count — All Resolutions

Figure 1 — Scaling across all resolutions. Small resolutions get worse with more nodes; large resolutions improve.

⏱️ td_timing_breakdown.png Stacked Bar: seq1 + parallel + seq2 per Node Count

Figure 2 — Three timing parts stacked. Shows how seq2 (ImageMagick stitch) grows as a serial bottleneck.

⚡ td_speedup_3200x2400.png Speedup vs Node Count at 3200×2400 (best scaling)

Figure 3 — Speedup at largest feasible resolution. 8 nodes achieves 1.93× — limited by sequential lockfile checking.

Key Findings

❌ Small resolutions: more nodes = slower (Amdahl's Law)

At 400×300 — 8 nodes is consistently SLOWER than 1 node. Render time per node is ~0.05s but SSH dispatch + sequential lockfile checking takes ~3s fixed. The serial fraction completely dominates. This is the clearest Amdahl's Law demonstration in our benchmarks.

✅ Large resolutions: scaling improves (Gustafson's Law)

At 3200×2400 — 1 node baseline is 55s, 8 nodes achieves 28.5s (1.93× speedup). Render time per node (~7s) now significantly exceeds coordination overhead, so compute dominates. Increasing the problem size pushed the parallelization limit.

⚠️ Sequential lockfile checking limits maximum speedup

The master script checks node completion sequentially — it waits for node 1, then node 2, etc. This means even if all nodes finish simultaneously, the master processes them one by one. This architectural serial fraction caps the maximum achievable speedup regardless of how large the render job is.

🔍 Contrast with MPI

MPI's mpirun launches all processes simultaneously and collects results in parallel. Task Distributor's sequential SSH dispatch is fundamentally different. This is why Monte Carlo Pi achieves 16.2× at 32 cores while Task Distributor achieves only 1.93× at 8 nodes — the coordination mechanism matters as much as the hardware.