commit c8ea05a70a56df016968ec9d7849f023e3bd91e6
parent 44525ad8662f00daec789bcbad866a9abf883952
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Tue, 14 Feb 2017 14:38:26 +0300
Sync p3.
Diffstat:
2 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2878,25 +2878,26 @@ TODO translate
иерархии управляющих объектов, в основном, прозрачно для программиста и требует
лишь маркировки главного объекта для его репликации на резервный узел.
-В ряде экспериментов производительность новой версии программы была измерена
-при выходе из строя различных типов узлов во время выполнения программы (номера
-пунктов соответствуют номерам графиков [[fig:benchmark]]):
-- без выхода из строя узлов,
-- выход из строя подчиненного узла (на котором генерируется часть взволнованной
- поверхности),
-- выход из строя главного узла (на котором запускается программа),
-- выход из строя резервного узла (на который копируется главный объект
- программы).
+В ряде экспериментов была измерена производительность новой версии программы при
+выходе из строя различных типов узлов во время выполнения программы (номера
+пунктов соответствуют номерам графиков рис.\nbsp{}[[fig:benchmark]]):
+1. без выхода из строя узлов,
+2. выход из строя подчиненного узла (на котором генерируется часть взволнованной
+ поверхности),
+3. выход из строя главного узла (на котором запускается программа),
+4. выход из строя резервного узла (на который копируется главный объект
+ программы).
Древовидная иерархия узлов со значением ветвления равного 64 использовалась в
-экспериментах, для того чтобы удостовериться, что все подчиненные узлы соединены
-с первым узлом подсети кластера. При каждом запуске программы главный объект
-запускался не на главном узле, чтобы оптимально отобразить иерархию объектов на
-иерархию узлов (наложить одну на другую). Узел-жертва выводился из строя по
-прошествии фиксированного временного интервала после запуска программы равного
-примерно \(1/3\) времени работы программы на одном узле. Способ запуска для
-каждого эксперимента представлен в [[tab:benchmark]] ("корень" и "лист" относятся к
-положению узла в древовидной иерархии). Результаты экспериментов приведены на
-[[fig:benchmark]] и [[fig:slowdown]].
+экспериментах, для того чтобы удостовериться, что все подчиненные узлы кластера
+соединены с узлом, имеющим первый IP-адрес в диапазоне адресов подсети.
+Узел-жертва выводился из строя по прошествии фиксированного временного интервала
+после запуска программы равного примерно \(1/3\) времени работы программы на
+одном узле. Приложение мгновенно узнавала о выходе из строя узла, поскольку
+закрывалось соответсвтвующие соединение; при реалистичном развитии событий,
+однако, выход из строя узла обнаружится по прошествии настраивомого тайм-аута.
+Способ запуска для каждого эксперимента представлен в табл.\nbsp{}[[tab:benchmark]].
+Результаты экспериментов приведены на рис.\nbsp{}[[fig:benchmark]]
+и\nbsp{}[[fig:slowdown]].
Графики 2 и 3 на [[fig:benchmark]] показывают, что производительность в
случае выхода из строя главного и подчиненного узлов примерно одинакова. В
@@ -2918,11 +2919,11 @@ TODO translate
#+caption: Параметры экспериментов.
#+name: tab:benchmark
#+attr_latex: :booktabs t
-| Номер эксп. | Главный узел | Узел-жертва | Время до выхода из строя, сек. |
-| 1 | корень | | |
-| 2 | корень | лист | 10 |
-| 3 | корень | лист | 10 |
-| 4 | корень | лист | 10 |
+| Номер эксп. | Время до выхода из строя, сек. |
+| 1 | |
+| 2 | 10 |
+| 3 | 10 |
+| 4 | 10 |
Для оценки количества времени, которое теряется при выходе из строя одного из
узлов, можно поделить общее время работы программы со сбоем на время работы
diff --git a/phd-diss.org b/phd-diss.org
@@ -2796,22 +2796,23 @@ changes involved modifying some parts to match the new API. So, providing fault
tolerance by means of kernel hierarchy is mostly transparent to the programmer
which only demands explicit marking of replicated kernels.
-In a series of experiments we benchmarked performance of the new version of the
-application in the presence of different types of failures (numbers correspond
-to the graphs in Figure [[fig:benchmark]]):
-- no failures,
-- failure of a slave node (a node where a part of wavy surface is generated),
-- failure of a master node (a node where the first kernel is run),
-- failure of a backup node (a node where a copy of the first kernel is stored).
-A tree hierarchy with fan-out value of 64 was chosen to make all cluster nodes
-connect directly to the first one. In each run the first kernel was launched on
-a different node to make mapping of kernel hierarchy to the tree hierarchy
-optimal. A victim node was made offline after a fixed amount of time after the
-programme start which is equivalent approximately to \(1/3\) of the total run time
-without failures on a single node. All relevant parameters are summarised in
-Table [[tab:benchmark]] (here ``root'' and ``leaf'' refer to a node in the
-tree hierarchy). The results of these runs were compared to the run without node
-failures (Figures [[fig:benchmark]]-[[fig:slowdown]]).
+In a series of experiments performance of the new version of the application in
+the presence of different types of failures was benchmarked (numbers correspond
+to the graphs in fig.\nbsp{}[[fig:benchmark]]):
+1. no failures,
+2. failure of a slave node (a node where a part of wavy surface is generated),
+3. failure of a master node (a node where the first kernel is run),
+4. failure of a backup node (a node where a copy of the first kernel is stored).
+A tree hierarchy with fan-out value of 64 was chosen to make all subordinate
+cluster nodes connect directly to the one having the first IP-address in the
+network IP address range. A victim node was made offline after a fixed amount of
+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
+[[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
@@ -2831,11 +2832,11 @@ chosen healthy node.
#+name: tab:benchmark
#+caption: Benchmark parameters.
#+attr_latex: :booktabs t
-| Experiment no. | Master node | Victim node | Time to offline, s |
-| 1 | root | | |
-| 2 | root | leaf | 10 |
-| 3 | leaf | leaf | 10 |
-| 4 | leaf | root | 10 |
+| Experiment no. | Time to offline, s |
+| 1 | |
+| 2 | 10 |
+| 3 | 10 |
+| 4 | 10 |
Finally, to measure how much time is lost due to a failure we divide the total
execution time with a failure by the total execution time without the failure
