lab: update Arm lab docs

[csit.git] / docs / report / introduction / methodology_reconf.rst

diff --git a/docs/report/introduction/methodology_reconf.rst b/docs/report/introduction/methodology_reconf.rst
index 32e0fd7..1a1f4cc 100644 (file)
--- a/docs/report/introduction/methodology_reconf.rst
+++ b/docs/report/introduction/methodology_reconf.rst
@@ -25,7 +25,7 @@ with somewhat long durations, and the re-configuration process can also be long,
 finding an offered load which would result in zero loss
 during the re-configuration process would be time-consuming.
 
 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
 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


@@ -38,16 +38,16 @@ Current Implementation
 Each reconf suite is based on a similar MLRsearch performance suite.
 
 MLRsearch parameters are changed to speed up the throughput discovery.
 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
 
 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
 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
 are not targetted by the traffic.
 
 For the re-configuration, the same Robot Framework and Python libraries


@@ -73,6 +73,3 @@ are expected without re-configuration. But different suites show different
 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.
 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.