commit c09758a0687aa841149cc25e4e76d6cba418f34e
parent c8ea05a70a56df016968ec9d7849f023e3bd91e6
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Tue, 14 Feb 2017 15:03:05 +0300
Sync p4.
Diffstat:
2 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2899,24 +2899,26 @@ TODO translate
Результаты экспериментов приведены на рис.\nbsp{}[[fig:benchmark]]
и\nbsp{}[[fig:slowdown]].
-Графики 2 и 3 на [[fig:benchmark]] показывают, что производительность в
-случае выхода из строя главного и подчиненного узлов примерно одинакова. В
-случае отказа главного узла резервный узел сохраняет копию главного объекта и
-восстанавливает главный объект из нее, когда не обнаруживает, что главный узел
-вышел из строя. В случае отказа подчиненного узла, главный узел
-перераспределяет невернувшиеся объекты между оставшимися подчиненными узлами. В
-обоих случая состояние главного объекта программы не теряется, а значит не
-тратится время на его восстановление, что объясняет схожую производительность.
-
-График 4 на [[fig:benchmark]] показывает, что производительность в случае
-выхода из строя резервного узла гораздо ниже, чем в других случаях. Это
+Эксперименты показали большую разницу в общей производительности приложения при
+выходе из строя различных типов узлов. Графики\nbsp{}2 и\nbsp{}3 на
+рис.\nbsp{}[[fig:benchmark]] показывают, что производительность в случае выхода из
+строя руководящего и подчиненного узлов одинакова. В случае отказа руководящего
+узла резервный узел сохраняет копию главного объекта и восстанавливает главный
+объект из нее, когда обнаруживает, что главный узел вышел из строя. В случае
+отказа подчиненного узла, главный узел перераспределяет невернувшиеся объекты
+между оставшимися подчиненными узлами. В обоих случая состояние главного объекта
+программы не теряется, а значит не тратится время на его восстановление, что
+объясняет схожую производительность.
+
+График\nbsp{}4 на\nbsp{}[[fig:benchmark]] показывает, что производительность в
+случае выхода из строя резервного узла гораздо ниже, чем в других случаях. Это
происходит, потому что главный узел сохраняет состояние только текущего
последовательного этапа программы, в то время как резервный узел не только
хранит копию этого состояния, но и выполняет параллельные части этапа вместе с
другими подчиненными узлами. Так что, когда резервный узел выходит из строя,
главный узел начинает выполнение текущего этапа с самого начала.
-#+caption: Параметры экспериментов.
+#+caption: Параметры экспериментов с алгоритмово восстановления после сбоев.
#+name: tab:benchmark
#+attr_latex: :booktabs t
| Номер эксп. | Время до выхода из строя, сек. |
diff --git a/phd-diss.org b/phd-diss.org
@@ -2810,27 +2810,30 @@ time after the programme start which is equivalent approximately to \(1/3\) of
the total run time without failures on a single node. The application
immediately recognised node as offline, because the corresponding connection was
closed; in real-world scenario, however, the failure is detected after a
-configurable time-out. All relevant parameters are summarised in Table
+configurable time-out. All relevant parameters are summarised in table
[[tab:benchmark]]. The results of these runs were compared to the run without node
failures (fig.\nbsp{}[[fig:benchmark]] and\nbsp{}[[fig:slowdown]]).
-There is considerable difference in net performance for different types of
-failures. Graphs 2 and 3 in Figure [[fig:benchmark]] show that performance in
-case of master or slave node failure is the same. In case of master node failure
-a backup node stores a copy of the first kernel and uses this copy when it fails
-to connect to the master node. In case of slave node failure, the master node
-redistributes the load across remaining slave nodes. In both cases execution
-state is not lost and no time is spent to restore it, that is why performance is
-the same. Graph 4 in Figure [[fig:benchmark]] shows that performance in case
-of a backup node failure is much lower. It happens because master node stores
-only the current step of the computation plus some additional fixed amount of
-data, whereas a backup node not only stores the copy of this information but
-executes this step in parallel with other subordinate nodes. So, when a backup
-node fails, the master node executes the whole step once again on arbitrarily
-chosen healthy node.
+There is considerable difference in overall application performance for
+different types of failures. Graphs\nbsp{}2 and\nbsp{}3 in
+fig.\nbsp{}[[fig:benchmark]] show that performance in case of principal and
+subordinate node failure is the same. In case of principal node failure a backup
+node stores a copy of the main kernel and uses this copy when it detects failure
+of the principal node. In case of subordinate node failure, the principal node
+redistributes the non-returning kernels between remaining subordinate nodes. In
+both cases the state of the main kernel is not lost and no time is spent to
+restore it, which explains similar performance.
+
+Graph\nbsp{}4 in fig.\nbsp{}[[fig:benchmark]] shows that performance in case of a
+backup node failure is much lower. It happens because master node stores only
+the current step of the computation plus some additional fixed amount of data,
+whereas a backup node not only stores the copy of this information but executes
+this step in parallel with other subordinate nodes. So, when a backup node
+fails, the master node executes the whole step once again on arbitrarily chosen
+healthy node.
#+name: tab:benchmark
-#+caption: Benchmark parameters.
+#+caption: Benchmark parameters for experiments with fail over algorithm.
#+attr_latex: :booktabs t
| Experiment no. | Time to offline, s |
| 1 | |
