ODL Helium SR3 stability results
In this section we present indicative results regarding the stability of OpenDaylight Helium SR3 controller with MT-Cbench switches. The objective is to investigate controller performance trends as time passes.
We used the stress_test/stress_test_confs/sb_active/stability_mtcbench.json
configuration file as a baseline, running it for 500 and 16 switches.
Configuration:
- 32-core server, 256GB RAM
- Controller: OpenDaylight Helium SR3 ("DS drop-test" mode)
- MT-Cbench emulator ("Latency" mode)
- 50 switches per thread, 10 threads
- 360 internal repeats, 10 seconds each (1h total running time)
- 8 seconds delay between thread creation
The plots below show performance and memory usage in time.
Configuration:
- 32-core server, 256GB RAM
- Controller: OpenDaylight Helium SR3 ("DS drop-test" mode)
- MT-Cbench emulator ("Latency" mode)
- 16 switches per thread, 1 thread
- 360 internal repeats, 10 seconds each (1h total running time)
Configuration:
- 32-core server, 256GB RAM
- Controller: OpenDaylight Helium SR3 ("RPC drop-test" mode)
- MT-Cbench emulator ("Latency" mode)
- 16 switches per thread, 1 thread
- 360 external repeats, 10 seconds each (1h total running time)
Configuration:
- 32-core server, 256GB RAM
- Controller: OpenDaylight Helium SR3 ("RPC drop-test" mode)
- MT-Cbench emulator ("Latency" mode)
- 16 switches per thread, 1 thread
- 360 internal repeats, 10 seconds each (1h total running time)
NSTAT makes accurate stability measurements exactly because it uses a separate thread to track performance online, at internal repeats boundaries, without having to restart the network topology.
We have indeed observed significantly different performance between this approach, and the approach of consistently restarting the emulator externally. The tests were ran with OpenDaylight Helium SR3 at "RPC drop-test" configuration. The NSTAT approach showed steady performance in time, while the external repeats approach showed declining throughput (we will provide relevant results in some future update, yet both scenarios could be easily reproduced with NSTAT). We didn't investigate this issue in depth, nevertheless we speculate that external repeats trigger somehow the DataStore (e.g. due to remove's/add's of the topology info on the DS, as a result of continuous topology dis/re-connections), giving the degrading performance we saw above.