finding an offered load which would result in zero loss
during the re-configuration process would be time-consuming.
-Instead, reconf tests find a througput value (lower bound for NDR)
+Instead, reconf tests first find a througput value (lower bound for NDR)
without re-configuration, and then maintain that ofered load
during re-configuration. The measured loss count is then assumed to be caused
by the re-configuration process. The result published by reconf tests
Each reconf suite is based on a similar MLRsearch performance suite.
MLRsearch parameters are changed to speed up the throughput discovery.
-For example, PDR is not searched for, and final trial duration is shorter.
+For example, PDR is not searched for, and the final trial duration is shorter.
The MLRsearch suite has to contain a configuration parameter
-that can be scaled up, e.g. number of routes or number of service chains.
+that can be scaled up, e.g. number of tunnels or number of service chains.
Currently, only increasing the scale is supported
as the re-configuration operation. In future, scale decrease
or other operations can be implemented.
The traffic profile is not changed, so the traffic present is processed
-only by the smaller scale configuration. The added routes / chains
+only by the smaller scale configuration. The added tunnels / chains
are not targetted by the traffic.
For the re-configuration, the same Robot Framework and Python libraries
allowing full NIC buffers to drain quickly between worker pauses.
For other suites, lower bound for NDR still has quite a large probability
of non-zero packet loss even without re-configuration.
-
-But the results show very high effective blocked time,
-so the two objections related to NDR lower bound are negligible in comparison.
Code Review / csit.git / blobdiff