Benchmarking

Após ter a certeza de que os resultados devolvidos eram os esperados e que o programa estava 100% funcional, passamos a fase de benchmarking para concluir se o protocolo SPDZ era eficaz ou não para a resolução do nosso problema. Para isso fez-se um shell script (bloco de código 6.7) para repetir a execução do programa cem vezes, em que se podiam alterar:

• O número de strikes a calcular. • O número de maturidades a calcular. • O número de servidores SPDZ.

• O número de bancos (os fornecedores de input).

Depois de cada execução do protocolo, o script “rawtocsv.py” vai aos logs gerados pela execução do protocolo e guarda os valores desejados num ficheiro csv, no final de tudo calcula-se a mediana de cada coluna para fazer a análise dos resultados.

 rm -rf /home/lol/Downloads/spdzupdated/SPDZ-2/Player-Data/* ./Scripts/setup-online.sh $1 128 40 ./client-setup.x $1 -nc $2 for i in {1..100} do

./Scripts/run-online.sh banktestComSec &

xterm -title "App 1" -e "./bank-client.x $1 $2 0 $3 $4 0x1000" & xterm -title "App 2" -e "./bank-client.x $1 $2 1 $3 $4 1x1000" & xterm -title "App 3" -e "./bank-client.x $1 $2 2 $3 $4 2x1000" & xterm -title "App 4" -e "./bank-client.x $1 $2 3 $3 $4 3x1000" &&

python rawtocsv.py

done

python median.py results0.csv



Resultados e análise

Neste capitulo serão apresentados e analisados os resultados do benchmarking. As variáveis consideradas para o benchmarking foram:

• O número de strikes a calcular. • O número de maturidades a calcular. • O número de servidores SPDZ.

• O número de bancos (os fornecedores de input).

Os dados medidos foram: o join timer, o finish timer, o tempo de processamento e o tempo total; os dados enviados, o número de chamadas de envio de dados e o número de bytes por chamada; e as triplas, os squares e os bits; entre outros. Desses dados nem todos foram relevantes para a análise ora porque dependem de outros ou porque são constantes. Temos também, o caso do join timer que depende de quanto tempo demora cada cliente a conetar-se aos servidores SPDZ, que num caso da vida real poderia fazer com que o sistema ficasse à espera do último cliente durante vários minutos. Para simplificar a apresentação dos resultados, utilizamos apenas os gráficos que representam os resultados obtidos pelo servidor que realizou um maior número de computações (o descrito na secção 4.1.5). Ou seja, não foi medida nem a performance dos outros servidores nem a do programa C++ dos clientes. Relativamente aos dados obtidos na execução dos servidores, os gráficos só representam o pior caso possível.

7.1

Número de strikes

Para testar o comportamento do SPDZ no que toca à variação de número de strikes, fizemos

benchmarking com os seguintes parâmetros:

• 4 servidores SPDZ.

• 4 bancos.

• Começamos com 2 strikes e duplicamos em cada iteração. • 4 maturidades.

Ao comparar as medianas resultantes deste benchmarking, os únicos valores relevantes obtidos, foram: o tempo de processamento, os dados enviados e as triplas, os squares e os bits.

Figura 7.1: Gráfico da evolução dos dados enviados.

Figura 7.3: Quantidade de triplas, squares e bits utilizados.

Pela análise das figuras 7.1 e 7.2 podemos verificar que a progressão de todas as variáveis é linear, ou seja, num número muito elevado de strikes o impacto no tempo de execução e nos dados enviados é o esperado. Assim sendo, podemos concluir que a variável número de strikes não tem um peso muito grande na performance do algoritmo. No entanto, como podemos ver no gráfico7.3, um maior número de strikes vai implicar um pré-processamento maior, o que pode ser um fator limitante devido ao forte poder computacional exigido pela fase offline.

7.2

Número de maturidades

Para testar o comportamento do SPDZ, no que toca à variação do número de maturidades, fizemos benchmarking com os seguintes parâmetros:

• 4 servidores SPDZ. • 4 bancos.

• 4 strikes.

• Começamos com 2 maturidades e duplicamos em cada iteração.

Os valores relevantes obtidos foram: o tempo de processamento, os dados enviados e as triplas, os squares e os bits.

Figura 7.5: Gráfico da evolução do tempo de processamento.

Figura 7.6: Quantidade de triplas, squares e bits utilizados .

Pela análise dos gráficos (7.4,7.5e 7.6) podemos verificar que os resultados são os mesmos ou aproximadamente os mesmos que os da secção 7.1, o que já era esperado, por isso podemos chegar às mesmas conclusões que eram previstas na secção 5.3.2.

7.3

Número de servidores SPDZ

Para testar o comportamento do SPDZ, no que toca à variação de número de servidores, fizemos

benchmarking com os seguintes parâmetros:

• Começamos com 2 servidores SPDZ e duplicamos em cada iteração. • 4 bancos.

• 4 strikes. • 4 maturidades.

Os resultados relevantes obtidos foram o tempo de processamento, o tempo total do protocolo e os dados enviados.

Figura 7.7: Gráfico da evolução do tempo de processamento.

Pela a análise da figura 7.7é possível concluir que cada duplicação do número de servidores aumenta, em média, o tempo de processamento em 53,16%, apesar de algumas irregularidades no gráfico, que podem ser explicadas por outros processos a correr na máquina em simultâneo. Os dados tornam-se claros a partir dos 16 Servidores e a progressão é linear.

Figura 7.8: Gráfico da evolução dos dados enviados.

É possível observar no gráfico (figura 7.8) um limite superior do número de dados enviados nos 13410768 bytes, atingido aos 16 servidores. Verifica-se também que a partir dos 16 servidores este valor é quase constante o que, em coerência com o gráfico anterior, comprova que os valores comportam-se como esperado. O limite superior deve-se ao protocolo de abertura parcial descrito na secção 4.1.5.

Figura 7.9: Gráfico da evolução do tempo total.

No gráfico da figura 7.9, podemos ver que o tempo do protocolo aumenta de uma forma linear, como esperado, devido às comunicações acrescentadas em cada iteração.

7.4

Número de bancos

Para testar o comportamento do SPDZ no que toca à variação do número de bancos, fizemos

benchmarking com os seguintes parâmetros:

• 4 servidores SPDZ.

• Começamos com 2 bancos e duplicamos em cada iteração. • 4 strikes.

• 4 maturidades.

Os valores relevantes obtidos foram o tempo de processamento, os dados enviados, o tempo total e as triplas, os squares e os bits.

Figura 7.10: Gráfico da evolução do tempo de processamento.

Como podemos ver (figura 7.10), o aumento do tempo de processamento por número de bancos segue uma progressão exponencial, o que significa que esta variável será a mais significativa em termos de impacto na execução do algoritmo. Podemos a partir dos valores obtidos estimar a função:

y = 0.0259161372 · x1.919114366

Conseguimos então estimar casos mais extremos, como para 2048 bancos, onde o tempo de execução estimado é de 58666 segundos (aprox. 16 horas e 20 minutos).

Figura 7.11: Gráfico da evolução dos dados enviados.

Este gráfico (figura7.11) permite concluir que uma duplicação do número de bancos utilizados aumenta os dados enviados em cerca de 295% para a escala utilizada (2 a 64 bancos). O gráfico segue uma progressão exponencial similar à progressão observada na figura 7.12, tal como seria de esperar. Para o caso de 2048 bancos podemos, através da função y = 289990.8 · x1.98438683, concluir que o total de dados enviados seria de 1079801104089 bytes (1 Terabyte).

Figura 7.13: Gráfico da evolução do tempo total.

Pela a análise da figura 7.13podemos verificar uma evolução polinominal no tempo total do protocolo em relação ao número de bancos. Observando então os gráficos todos, como já era esperado (secção 5.3.2), podemos concluir que a variável com mais impacto no tempo de processamento, dados enviados e utilizados e no tempo total de execução do protocolo é o número de bancos.