commit afabec23af376eb4318935a2f67563e1f6a75862
parent 82284c8238536345bcc33f3f726aa4403a27c88f
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Tue, 14 Feb 2017 15:22:25 +0300
Sync the last paragraph. Finished syncing evaluation results.
Diffstat:
2 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2928,20 +2928,22 @@ TODO translate
| 3 | 10 |
| 4 | 10 |
-Для оценки количества времени, которое теряется при выходе из строя одного из
-узлов, можно поделить общее время работы программы со сбоем на время работы
-программы без сбоев, но с количеством узлов минус один. Это отношение
-представлено на [[fig:slowdown]]. Разница в производительности в случае выхода из
-строя главного узла и подчиненного узла находится в пределах 5%, а в случае
-выхода из строя резервного узла --- в пределах 50% для количества узлов меньше
-6[fn::Измерение разницы для большего количества узлов не имеет смысла, поскольку
-программа завершается еще до наступления сбоя.]. Разница в 50% больше, чем \(1/3\)
-времени работы программы, после которого происходит сбой, однако отказ
+Для оценки количества времени, которое теряется при выходе узла из строя, можно
+поделить общее время работы программы со сбоем на время работы программы без
+сбоев, но с количеством узлов минус один. Это отношение получается из того же
+самого эксперимента и представлено на рис.\nbsp{}[[fig:slowdown]]. Разница в
+производительности в случае выхода из строя руководящего и подчиненного узлов
+находится в пределах 5%, а в случае выхода из строя резервного узла --- в
+пределах 50% для количества узлов меньше 6[fn::Измерение разницы для большего
+количества узлов не имеет смысла, поскольку программа завершается еще до
+наступления сбоя.]. Увеличение времени выполнения на 50% --- это больше, чем
+\(1/3\) времени работы программы, после которого происходит сбой, однако отказ
резервного узла требует некоторого времени, чтобы быть обнаруженным другими
-узлами. Сбой узла обнаруживается только тогда, когда подчиненный объект
-завершает свое выполнение и пытается вернуться на исходный узел к родителю.
-Мгновенное обнаружение сбоя узла требует остановки выполнения объектов, что
-может быть неприменимо для программ со сложной логикой.
+узлами: сбой узла обнаруживается только тогда, когда подчиненный объект, имеющий
+копию главного объекта, завершает свое выполнение и пытается вернуться на
+исходный узел к родителю. Мгновенное обнаружение сбоя узла требует внезапной
+остановки выполнения объектов, что может быть неприменимо для программ со
+сложной логикой.
#+name: fig:benchmark
#+begin_src R
@@ -2951,11 +2953,11 @@ TODO translate
#+caption: Производительность программы генерации взволнованной морской поверхности при различных типах сбоев узлов.
#+RESULTS: fig:benchmark
-Результаты экспериментов позволяют сделать вывод о том, что /не важно,
-вышел ли из строя главный узел или подчиненный, итоговое время работы программы
-будет примерно равно времени ее работы без сбоев, но с уменьшенным на единицу
-количеством узлов/, однако, в случае выхода из строя резервного узла теряется
-гораздо больше времени.
+Результаты экспериментов позволяют сделать вывод о том, что /не важно, вышел ли
+из строя руководящий узел или подчиненный, общее время работы параллельной
+программы примерно равно времени ее работы без сбоев, но с уменьшенным на
+единицу количеством узлов/, однако, в случае выхода из строя резервного узла
+потери в производительности гораздо больше.
#+name: fig:slowdown
#+begin_src R
diff --git a/phd-diss.org b/phd-diss.org
@@ -2841,21 +2841,21 @@ once again on arbitrarily chosen survived node.
| 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
-but with the number of nodes minus one. The results for this calculation are
-obtained from the same benchmark and are presented in Figure [[fig:slowdown]]. The
-difference in performance in case of master and slave node failures lies within
-5% margin, and in case of backup node failure within 50% margin for the number
-of node less than 6[fn::Measuring this margin for higher number of nodes does
-not make sense since time before failure is greater than total execution time
-with these numbers of nodes, and programme's execution finishes before a failure
+To measure how much time is lost due to a node failure the total execution time
+with a failure was divided by the total execution time without the failure but
+with the number of nodes minus one. This relation is obtained from the same
+benchmark and presented in fig.\nbsp{}[[fig:slowdown]]. The difference in
+performance in case of principal and subordinate node failures lies within 5%
+margin, and in case of backup node failure within 50% margin for the number of
+node less than 6[fn::Measuring this margin for higher number of nodes does not
+make sense since time before failure is greater than total execution time with
+these numbers of nodes, and programme's execution finishes before a failure
occurs.]]. Increase in execution time of 50% is more than \(1/3\) of execution
-time after which a failure occurs, but backup node failure need some time to be
-discovered: they are detected only when subordinate kernel carrying the copy of
-the first kernel finishes its execution and tries to reach its parent. Instant
+time after which a failure occurs, but backup node failure needs some time to be
+discovered: it is detected only when subordinate kernel carrying the copy of the
+main kernel finishes its execution and tries to reach its parent. Instant
detection requires abrupt stopping of the subordinate kernel which may be
-undesirable for programmes with complicated logic.
+inapplicable for programmes with complicated logic.
#+name: fig:benchmark
#+begin_src R
@@ -2865,10 +2865,10 @@ undesirable for programmes with complicated logic.
#+caption: Performance of hydrodynamics HPC application in the presence of node failures.
#+RESULTS: fig:benchmark
-To summarise, the benchmark showed that /no matter a master or a slave node
-fails, the resulting performance roughly equals to the one without failures with
-the number of nodes minus one/, however, when a backup node fails performance
-penalty is much higher.
+The results of the benchmark allows concluding that /no matter a principal or a
+subordinate node fails, the overall performance of a parallel programme roughly
+equals to the one without failures with the number of nodes minus one/, however,
+when a backup node fails performance penalty is much higher.
#+name: fig:slowdown
#+begin_src R
