Tutorial 14: Open Cluster
We model an open cluster: a single open class of jobs flows from a Source through a Router (the dispatcher) into one of M=3 parallel processor-sharing servers, after which it leaves the system through a Sink. We illustrate two equivalent ways of building this model: a one-liner factory (Network.clusterPs), and the more flexible Cluster builder, which we use to compare two dispatching policies on the same cluster.
Block 1: One-liner factory
We start with the one-liner factory. The arrival rate is λ = 0.4 and each server has a mean service time of D = 1, giving a per-server utilization of λ/M ≈ 0.133 under random dispatching.
lambda = 0.4;
D = ones(3,1);
model = Network.clusterPs(lambda, D, RoutingStrategy.RAND);
avgTable = MVA(model).getAvgTable()
Matrix lambda = new Matrix("[0.4]");
Matrix D = new Matrix("[1.0; 1.0; 1.0]");
Network model = Network.clusterPs(lambda, D, RoutingStrategy.RAND);
new MVA(model).getAvgTable().print();
val lambda = Matrix("[0.4]")
val D = Matrix("[1.0; 1.0; 1.0]")
val model = Network.clusterPs(lambda, D, RoutingStrategy.RAND)
MVA(model).getAvgTable().print()
from line_solver import *
lam = [0.4]
D = [[1.0], [1.0], [1.0]]
model = Network.cluster_ps(lam, D, RoutingStrategy.RAND)
print(MVA(model).get_avg_table())
Expected MVA output (traffic split evenly across the three servers)
Station JobClass QLen Util RespT ResidT ArvR Tput
_______ ________ _______ _______ ______ _______ _______ _______
Source Class1 0 0 0 0 0 0.4
Server1 Class1 0.15263 0.13333 1.1448 0.38158 0.13333 0.13333
Server2 Class1 0.15263 0.13333 1.1448 0.38158 0.13333 0.13333
Server3 Class1 0.15263 0.13333 1.1448 0.38158 0.13333 0.13333
Block 2: Cluster builder with multi-server queues
We now switch to the chainable Cluster builder to introduce non-uniform multi-server queues, replacing PS with FCFS and giving Server 1 two parallel cores (M/M/2, the others stay M/M/1):
cluster = Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0);
cluster.setScheduling(SchedStrategy.FCFS);
cluster.setStationServers([2; 1; 1]); % Server1 = M/M/2, Server2/3 = M/M/1
avgTableFcfs = MVA(cluster.build()).getAvgTable()
Cluster cluster = new Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0)
.setScheduling(SchedStrategy.FCFS)
.setStationServers(new int[] {2, 1, 1});
new MVA(cluster.build()).getAvgTable().print();
val cluster = Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0)
.setScheduling(SchedStrategy.FCFS)
.setStationServers(intArrayOf(2, 1, 1))
MVA(cluster.build()).getAvgTable().print()
cluster = (Cluster().set_num_stations(3).set_arrival_rate(0.4).set_service_rate(1.0)
.set_scheduling(SchedStrategy.FCFS)
.set_station_servers([2, 1, 1]))
print(MVA(cluster.build()).get_avg_table())
Block 3: Cross-check JMT, LDES, and SSA on the FCFS cluster
We then cross-check the same FCFS cluster under three simulators. JMT is the XML-driven Java Modelling Tools simulator; LDES is the LINE Discrete Event Simulator built on the SSJ library, invoked as a subprocess; SSA is LINE's native next-reaction-method stochastic simulator. All three produce statistically equivalent results on this open-class cluster and exercise the multi-server FCFS path.
disp(JMT(cluster.build(), 'seed', 23000, 'samples', 20000).getAvgTable());
disp(LDES(cluster.build(), 'seed', 23000, 'samples', 20000).getAvgTable());
disp(SSA(cluster.build(), 'seed', 23000, 'samples', 20000).getAvgTable());
new JMT(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print();
new LDES(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print();
new SSA(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print();
JMT(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print()
LDES(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print()
SSA(cluster.build(), "seed", 23000, "samples", 20000).getAvgTable().print()
print(JMT(cluster.build(), seed=23000, samples=20000).get_avg_table())
print(LDES(cluster.build(), seed=23000, samples=20000).get_avg_table())
print(SSA(cluster.build(), seed=23000, samples=20000).get_avg_table())
Block 4: Compare dispatching policies
Finally, we compare random and round-robin dispatching on a uniform PS cluster. Round-robin is non-product-form, so we drop to JMT with a small sample budget. The compareDispatching helper runs the same cluster under each policy and returns one result table per policy.
cluster2 = Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0);
cluster2.setScheduling(SchedStrategy.PS);
solverFcn = @(m) JMT(m, 'seed', 23000, 'samples', 5000).getAvgTable();
results = cluster2.compareDispatching(solverFcn, ...
[RoutingStrategy.RAND, RoutingStrategy.RROBIN]);
keys_ = results.keys;
for k = 1:numel(keys_)
fprintf('\n=== Dispatching: %s ===\n', keys_{k});
disp(results(keys_{k}));
end
Cluster cluster2 = new Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0)
.setScheduling(SchedStrategy.PS);
Function<Network, NetworkAvgTable> solverFcn =
m -> new JMT(m, "seed", 23000, "samples", 5000).getAvgTable();
cluster2.compareDispatching(solverFcn,
RoutingStrategy.RAND, RoutingStrategy.RROBIN)
.forEach((policy, table) -> {
System.out.println("=== Dispatching: " + policy + " ===");
table.print();
});
val cluster2 = Cluster().setNumStations(3).setArrivalRate(0.4).setServiceRate(1.0).setScheduling(SchedStrategy.PS)
val solverFcn: (Network) -> NetworkAvgTable =
{ m -> JMT(m, "seed", 23000, "samples", 5000).getAvgTable() }
cluster2.compareDispatching(solverFcn,
RoutingStrategy.RAND, RoutingStrategy.RROBIN)
.forEach { (policy, table) ->
println("=== Dispatching: $policy ===")
table.print()
}
cluster2 = (Cluster().set_num_stations(3).set_arrival_rate(0.4).set_service_rate(1.0)
.set_scheduling(SchedStrategy.PS))
solver_fcn = lambda m: JMT(m, seed=23000, samples=5000).get_avg_table()
for policy in (RoutingStrategy.RAND, RoutingStrategy.RROBIN):
cluster2.set_dispatching(policy)
print(f"=== Dispatching: {policy} ===")
print(solver_fcn(cluster2.build()))
For this lightly loaded cluster both policies produce very similar response times; differences become visible only at higher utilization, where round-robin reduces variability across servers compared with the i.i.d. split produced by random dispatching.