[SD] Enhance "Tempo e Sincronização" page

content/sd/0003-tempo-e-sincronizacao.md

@@ -95,6 +95,12 @@ $$
 t' > t \Rightarrow C_p(t') > C_p(t)
 $$
 
+:::tip[Nota]
+
+Garantir a monotonia de um relógio é fundamental para o correto funcionamento de programas que se baseiam no tempo. Por exemplo, a ferramenta _make_ do UNIX é utilizada para compilar apenas os ficheiros que foram modificados desde a última compilação. Se o tempo retroceder entre compilações, a ferramenta não funciona como desejado.
+
+:::
+
 Para conjuntos de relógios, pode-se ainda falar de **precisão** e **exatidão**.
 
 ![Precisão e Exatidão](./assets/0003-precision-vs-accuracy.png#dark=2)
@@ -136,11 +142,11 @@ O processo $p$ envia uma mensagem $m_1$ ao servidor de tempo $S$ e espera pela
 resposta $m_2$, que inclui $C_S(t_{S,m_2})$, com $t_{S,m_2}$ sendo o momento em
 que a resposta $m_2$ sai de $S$.
 
-<!-- ```mermaid
+```mermaid
 sequenceDiagram
     p->>Servidor de tempo: m₁: What is the time?
     Servidor de tempo->>p: m₂: My clock says this.
-``` -->
+```
 
 O processo $p$ não pode usar o tempo incluído na mensagem $m_2$, pois estaria a
 desprezar o tempo de transmissão. Assim, $p$ mede o $RTT$ e, assumindo que o
@@ -163,13 +169,42 @@ demora $RTT$, o tempo estimado estará errado por $\frac{RTT}{2}$.
 A precisão deste algoritmo é, portanto, $\frac{RTT}{2}$.
 
 Pode-se melhorar a precisão caso se conheça o tempo mínimo de transmissão,
-ficando $\frac{RTT - RTT_{min}}{2}$.
+ficando $\frac{RTT}{2} - RTT_{min}$.
 
 Este algoritmo é simples, no entanto, tem um único ponto de falha. Se o
 servidor de tempo falhar, o sistema não consegue sincronizar os relógios.
 Cristian propõe que o pedido seja feito em _multicast_ a vários servidores de
 tempo, selecionando o que responder primeiro, resultando na melhor precisão.
 
+:::info[Exercício]
+
+Um cliente pretende sincronizar-se com um servidor e para tal regista o RTT e os tempos
+enviados pelo servidor:
+
+| RTT (ms)            | Time (hh\:mm\:ss)             |
+| ------------------- | ----------------------------- |
+| <center>22</center> | <center>10:54:23.674</center> |
+| <center>25</center> | <center>10:54:25.450</center> |
+| <center>20</center> | <center>10:54:28.342</center> |
+
+> **1\. Com qual dos valores deve o servidor se sincronizar de modo a obter a melhor precisão?**
+
+**R:** Com o terceiro (10:54:28.342), pois apresenta o menor RTT ($20~ms$)
+
+> **2\. Qual o valor do relógio após o acerto?**
+
+**R:** $C(t) = t + \frac{RTT}{2} =$ 10:54:28.342 $+ \frac{20ms}{2} =$ 10:54:28.352
+
+> **3\. Qual a precisão do acerto?**
+
+**R:** $\pm~10~ms$
+
+> **4\. E se soubermos que o tempo de envio de uma mensagem é no mínimo de 8ms, essa precisão é alterada? Se sim, qual o novo valor?**
+
+**R:** $\pm~(\frac{RTT}{2}-RTT_{min}) = \pm~(\frac{20}{2}-8) = \pm~2~ms$
+
+:::
+
 #### Algoritmo de Berkeley
 
 O Algoritmo de Berkeley é um algoritmo de **sincronização interna**.
@@ -178,9 +213,9 @@ processo coordenador $C$ e os processos $p$ e $q$, mas o algoritmo pode ser
 estendido a qualquer número de processos.
 
 Neste algoritmo, é eleito um coordenador $C$, responsável por periodicamente
-envir pedidos a todos os outros processos, que devem responder com o seu tempo.
+enviar pedidos a todos os outros processos, que devem responder com o seu tempo.
 
-<!-- ```mermaid
+```mermaid
 sequenceDiagram
     participant p
     Coordenador->>p: m₁: What is the time?
@@ -189,7 +224,7 @@ sequenceDiagram
     q->>Coordenador: m₄: My clock says this.
     Coordenador->>p: m₅: Offset your clock by this.
     Coordenador->>q: m₆: Offset your clock by this.
-``` -->
+```
 
 O coordenador recebe as respostas $m_2$ e $m_4$ e calcula a média dos
 tempos, incluindo o próprio:
@@ -218,16 +253,47 @@ $$
 Cada processo ajusta o seu relógio, de acordo com a diferença recebida.
 
 O algoritmo apresentado foi simplificado, na versão real é tido em conta o
-tempo de transmissão, da forma como foi feito no Algoritmo de Cristian.
+tempo de transmissão, da forma como foi feito no Algoritmo de Cristian. É ainda definido um valor máximo para o RTT (dependendo da exatidão desejada), permitindo ao coordenador eliminar ocasionais leituras que ultrapassem esse valor.
 
 Em caso de falha do coordenador, um novo coordenador é eleito. Falar-se-á de
 eleições na próxima publicação.
 
+:::info[Exercício]
+
+Existem 3 máquinas `A`, `B` e `C`, sendo o _master_ `A`. `A` enviou a sua hora (13:15:15)
+a todos e recebeu as seguintes respostas:
+
+| Time (hh\:mm\:ss)                 |
+| --------------------------------- |
+| <center>[ A = 13:15:15 ]</center> |
+| <center>B = 13:15:05</center>     |
+| <center>C = 13:16:07</center>     |
+
+> **Qual é o acerto enviado pelo _master_ a cada máquina?**
+
+$$
+T_{avg} = \frac{C_B(t_{B,m}) + C_C(t_{C,m}) + C_A(t)}{3} = 13:15:29
+$$
+
+$$
+\Delta t_{B} = T_{avg} - C_B(t_{B,m}) = +~24s
+$$
+
+$$
+\Delta t_{C} = T_{avg} - C_C(t_{C,m}) = -~38s
+$$
+
+$$
+\Delta t_{A} = T_{avg} - C_A(t) = +~14s
+$$
+
+:::
+
 #### Network Time Protocol (NTP)
 
 Tanto o Algoritmo de Cristian como o Algoritmo de Berkeley são algoritmos
-desenhados para operar em intranets. O NTP define um protocolo distribuir
-informação de tempo através da internet.
+desenhados para operar em intranets. O NTP define um protocolo para distribuir
+informação de tempo através da Internet.
 
 Os objetivos de desenho do NTP são:
 
@@ -244,13 +310,13 @@ O protocolo NTP baseia-se no Algoritmo de Cristian, mas em vez apenas medir o
 $RTT$, registam-se os valores reportados por $p$ para o envio de $m_1$ e
 recepção de $m_2$, $C_p(t_{p,m_1})$ e $C_p(t_{p,m_2})$, e os valores reportados
 por $q$ para a recepção de $m_1$ e envio de $m_2$, $C_q(t_{q,m_1})$ e
-$C_q(t_{q,m_2})$.
+$C_q(t_{q,m_2})$. Desta forma, o tempo entre a chegada de uma mensagem e o envio da próxima não é contabilizado.
 
-<!-- ```mermaid
+```mermaid
 sequenceDiagram
     p->>q: m₁: When do you receive this message?
     q->>p: m₂: I got it then and am sending it now.
-``` -->
+```
 
 Calcula-se a diferença entre os tempos reportados entre o envio e recepção de
 cada mensagem:
@@ -304,14 +370,6 @@ Para resolver este problema, o NTP divide as máquinas em níveis (ou _strata_):
 
 Uma máquina só ajusta o seu relógio com uma máquina de nível inferior.
 
-:::details[help pls]
-Honestamente, não fiquei com grande intuição sobre como é que o NTP funciona.
-Se estás a ler isto e tens uma explicação melhor, que transmita intuição sobre
-o protocolo e não seja só debitar fórmulas, por favor, diz-me algo no discord.
-
-\- Luís
-:::
-
 ## Eventos e Relógios Lógicos
 
 Nem sempre é necessário contar o tempo de forma exata.
@@ -380,6 +438,12 @@ Algumas relações de concorrência encontradas no diagrama:
 
 :::
 
+:::tip[Nota]
+
+Se dois eventos têm uma relação _happened-before_, então o primeiro pode ou não ter causado o segundo. Esta relação apenas sugere potenciais causalidades, podendo não haver qualquer ligação entre os eventos (eventos independentes).
+
+:::
+
 ### Relógio Lógico de Lamport
 
 Leslie Lamport propôs um algoritmo simples para capturar a ordem de eventos num
@@ -566,6 +630,12 @@ $$
 
 :::
 
+:::tip[Nota]
+
+Em comparação com os _timestamps_ de Lamport, os _vector timestamps_ têm a desvantagem de precisar de uma maior capacidade de armazenamento e transmissão de mensagens, proporcional ao número de processos. No entanto, existem técnicas para armazenar e transmitir quantidades menores de dados, com o custo adicional de processamento para reconstruir os vetores.
+
+:::
+
 ## Referências
 
 - Coulouris et al - Distributed Systems: Concepts and Design (5th Edition)