cap-experimento.tex

\chapter{Experimentos}
\label{cap:experimentos}

Para analisar o desempenho da \textit{NAPI} em dispositivos de rede virtuais, foram feitos experimentos variando o parâmetro limite do \textit{driver} de rede e1000 da Intel em vários \textit{hypervisors} diferentes.
Esse \textit{driver} implementa NAPI e tem o código-fonte claro e bem escrito, sendo usado por vários \textit{hypervisors} como  Xen, VirtualBox, VMware e KVM para processar a recepção e transmissão de dados pela rede na máquina virtual. Outras soluções que os \textit{hypervisors} teriam são os \textit{drivers} de para-virtualização do Xen e do Virtio.
Ambos têm um desempenho superior ao e1000 por usarem técnicas de para-virtualização, porém, são mais complexos porque se comunicam diretamente com a máquina física.

Na implementação de recepção de pacotes do e1000, o limite define a quantidade limite de pacotes que a tarefa de recepção poderá coletar por ciclo de varredura. Se a quantidade de pacotes atingir esse limite ou esgotar o tempo limite de espera de pacotes, a tarefa é recolocada na fila de varredura, caso contrário, é removida da fila.
%-----------------------------------------------------------------------------------------------------

\section{Banda X Limite}
Nesse primeiro experimento estudamos a largura de banda em relação a variação de protocolo e limite.
Como \textit{hypervisor} foi usado o VirtualBox. 
A máquina física contém um processador i7-2620M de dois núcleos e quatro fluxos de execução, 8 Gigabytes de memória \textit{RAM} e sistema operacional Mac OS X 10.6.8 enquanto que a máquina virtual usa dois fluxos de execução, 5 Gigabytes de memória \textit{RAM} e sistema operacional Ubuntu 11.10 com núcleo Linux 3.0.43.

Foram analisadas a largura de banda na recepção do \texttt{iperf} e a quantidade total de pacotes processada pelo \textit{driver}. O limite variou de 1 a 10 de um em um, de 10 a 100 de dez em dez e com o valor 200. A banda de transmissão foi a máxima que a máquina poderia transmitir, no \textit{TCP} dependeria do seu mecanismo de controle de fluxo e no UDP configuramos para a transmitir 1 Gbit/s, mas a transmissão alcançou apenas 810 Mbits/s.

A escolha do intervalo reduzido quanto menor o limite foi feita considerando que as interrupções de \textit{hardware} irão reduzir significantemente nos primeiros limites e muito pouco nos próximos, sendo assim, é esperado que variações na banda ocorram com valores de limite baixos.
Também foram considerados o artigo de Corbet \cite{NAPI} e de Salah \cite{salah2009implementation}, que sugerem um melhor desempenho para valores baixos de limite.
A banda foi medida usando o programa \texttt{iperf} com protocolo \textit{TCP} e \textit{UDP} durante 30 segundos e a quantidade de pacotes pelo \texttt{ifconfig}.
Nos gráficos, são mostradas a média e intervalo de confiança de 95\% dos resultados do experimento. Cada experimento foi realizado 10 vezes.\newline

A Figura \ref{2tcp} mostra a largura de banda de recepção do \texttt{iperf} usando \textit{TCP}. Percebe-se que com limites baixos, o desempenho da largura de banda de recepção é menor em relação aos experimentos com limites altos.
Na Figura \ref{2tcp_packet}, é mostrada a quantidade de pacotes recebida pelo \textit{driver}. Nota-se que existe uma semelhança grande entre a Figura \ref{2tcp} e \ref{2tcp_packet}. 
Uma correlação linear foi feita com as informações a largura de banda e a quantidade de pacotes recebida. O resultado foi de 0.9999, uma forte correlação.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=250pt,height=183pt]{./img/banda/core2/iperf_tcp.eps}
\caption{Largura de banda na recepção de pacotes com protocolo TCP}
\label{2tcp}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=250pt,height=183pt]{./img/banda/core2/rx_packets_tcp.eps}
\caption{Quantidade de pacotes recebida pelo driver com protocolo TCP}
\label{2tcp_packet}
\end{center}
\end{figure}

A Figura \ref{2udp} mostra a banda da recepção usando UDP. 
Percebe-se um comportamento diferente em relação ao \textit{TCP} visto na Figura \ref{2tcp}, enquanto no \textit{TCP}, o aumento no limite elevaria a banda, o contrário parece ocorrer no UDP, quanto menor o limite maior a banda. 
Nota-se também um resultado incomum, a banda do UDP apresenta resultados muito inferiores em relação ao \textit{TCP}. \newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=250pt,height=183pt]{./img/banda/core2/iperf_udp.eps}
\caption{Largura de banda na recepção de pacotes com protocolo UDP}
\label{2udp}
\end{center}
\end{figure}

Na Figura \ref{2udp_packet}, é mostrada a quantidade de pacotes recebida usando \textit{UDP}, nota-se que o gráfico se diferencia completamente em relação ao gráfico anterior da Figura \ref{2udp}. A correlação linear entre elas foi de -0.9999, um resultado contrário em relação ao experimento com \textit{TCP}.

Existe uma possível resposta para esse resultado:
no \textit{UDP}, os pacotes são processados em grandes quantidades no \textit{driver}, com exceção do experimento com limite igual a 1 que processa poucos pacotes.
Entre a chegada no \texttt{iperf} e o processamento de pacote pelo \textit{driver} pode ocorrer um transbordamento em uma fila de pacotes devido ao excesso de pacotes e isto faz o \texttt{iperf} perder muitos pacotes.
No \textit{TCP}, devido a característica do protocolo de controlar o fluxo, o envio de pacotes é mais lento e o sistema não consegue um fluxo o suficiente para transbordar a fila.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/core2/rx_packets_udp.eps}
\caption{quantidade de pacotes recebida pelo driver com protocolo UDP}
\label{2udp_packet}
\end{center}
\end{figure}

Sendo mais específico, esse transbordamento ocorreu no \textit{buffer} de recepção do \textit{socket} criado pelo \texttt{iperf}. Aumentando esse \textit{buffer}, percebemos um aumento expressivo da banda como é visto nas Figuras \ref{buffer_2udp} e \ref{buffer_2udp_packet}. A correlação linear foi de 0.9426. 
Talvez seja possível achar uma configuração de \textit{buffer} que se correlacione mais analisando-a com mais detalhes, mas esse resultado já mostra que limites altos têm uma largura de banda maior que limites baixos se configurarmos o \textit{buffer} corretamente.\newline

Assim, concluímos tanto com \textit{TCP} como com \textit{UDP} que configurações de limite alto e ajustes no \textit{buffer} resultam em uma largura de banda maior que configurações com limites baixos.
No próximo passo, será estudada a causa dos \textit{drivers} com limites altos terem uma banda de recepção maior que \textit{drivers} com limites baixos.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/buffer/iperf_udp.eps}
\caption{Largura de banda na recepção de pacotes com protocolo UDP modificando o buffer de recepção}
\label{buffer_2udp}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/buffer/rx_packets_udp.eps}
\caption{Quantidade de pacotes recebida pelo driver com protocolo UDP modificando o buffer de recepção}
\label{buffer_2udp_packet}
\end{center}
\end{figure}

\clearpage
%-----------------------------------------------------------------------------------------------------

\section{Interrupções}
Foram realizados experimentos com o limite em relação as interrupções com o protocolo \textit{UDP}.
Como \textit{hypervisor} foram usados o VirtualBox, o VMware e o Xen com virtualização completa.

No experimento com o VirtualBox e VMware foram usadas as mesmas configurações de \textit{hardware} e sistema operacional que o experimento anterior.
No Xen, a máquina física contém um processador i7 Ivy bridge de quatro núcleos e oito fluxos de execução, 16 Gigabytes de memória \textit{RAM} e sistema operacional Ubuntu 12.10 enquanto que a máquina virtual usa dois fluxos de execução, 5 Gigabytes de memória \textit{RAM} e sistema operacional Ubuntu 11.10 com núcleo Linux 3.0.12.

Foram variados a largura de banda de transmissão de 100 até 1000 Mbits/s de cem em cem e o limite em 1, 2, 60 e 200 usando protocolo \textit{UDP}.
A escolha do \textit{UDP} foi devido a possibilidade de controlar a banda de envio e a pouca intervenção no fluxo de pacotes em relação ao \textit{TCP}.
O Tamanho do \textit{buffer} de recepção do \textit{socket} foi definido para 8 Mbytes.
Foram medidos a largura de banda de recepção do \texttt{iperf}, a quantidade de pacotes recebida usando o \texttt{ifconfig}, o uso de \textit{CPU} total e o uso de \textit{CPU} pelas interrupções de software usando \texttt{sar}.
No uso de \textit{CPU}, é considerando 100\% o uso de uma linha inteira de execução e 200\% duas linhas e assim, sucessivamente.
Cada gráfico mostra a média dos resultados do experimento. Cada experimento foi rodado 5 vezes.
%-----------------------------------------------------------------------------------------------------

\subsection{VirtualBox}
%-----------------------------------------------------------------------------------------------------

\subsubsection{Recepção de Pacotes}
Na Figura \ref{vbox_iperf} é mostrada a largura de banda recebida pelo \texttt{iperf} em relação a largura de banda transmitida.
Nota-se que todos os limites têm perdas de pacotes, mas conforme a banda aumenta, essa perda é reduzida.
Percebe-se também que com limite igual a 1, quando a banda tem transmissão maior que 600 Mbits/s a banda passa a processar aproximadamente 400 Mbits/s.
Nos próximos gráficos será analisada a causa desse comportamento. \newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/buffer/iperf.eps}
\caption{Largura de banda de recepção no VirtualBox}
\label{vbox_iperf}
\end{center}
\end{figure}

Na Figura \ref{vbox_if} é mostrada a quantidade de pacotes recebida pelo \textit{driver}, percebe-se que todas as curvas começam crescente e num determinado momento, elas ficam constantes limitada por algum fator. Esse é possivelmente o ponto de \textit{MLFRR} (máxima velocidade de recepção livre de perdas) citado em \cite{salah2005analysis}.
O gráfico com limite igual a 1 passa a ser constante quando a banda é maior que 500 Mbits/s. 
Provavelmente, o sistema começou a descartar pacotes pois percebeu que não seria capaz de processá-los, uma característica da \textit{NAPI}.
Já os outros limites passam a ficar constantes somente em 800 Mbits/s que é próximo do limite da banda de transmissão, nesse caso, o 
\textit{driver} conseguiu processar todos os pacotes e não houve perdas.
Assim, novamente entre o \textit{driver} e a recepção de pacotes do \texttt{iperf}, alguns pacotes deixaram de ser processados.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/buffer/ifconfig.eps}
\caption{Quantidade de pacotes recebida pelo driver no VirtualBox}
\label{vbox_if}
\end{center}
\end{figure}

\subsubsection{Interrupções de Software e Uso de CPU}
Na Figura \ref{vbox_soft} é mostrado o uso de \textit{CPU} pelas interrupções de software.
Notamos que com qualquer limite, houve inicialmente um aumento no uso de \textit{CPU} até chegar no intervalo entre 90\%-100\% onde o uso permanece entre esses valor e com exceção da configuração com limite igual a 1, todos tiveram uma redução com transmissão acima de 700 Mbits/s.
Esse aumento provavelmente foi limitado pela \textit{CPU} que será analisada no próximo gráfico.
Essa redução será analisada melhor no próximo experimento.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/buffer/soft.eps}
\caption{Uso da CPU pelas interrupções de software no VirtualBox}
\label{vbox_soft}
\end{center}
\end{figure}

Na Figura \ref{vbox_cpu} é mostrado o uso de \textit{CPU} dentro da máquina virtual. Percebemos que com limite igual a 1, a máquina virtual excedeu consideravelmente seu uso em relação aos demais.
Monitorando os processos em execução, notamos que com limite igual a 1 e largura de banda de transmissão maior que 500 Mbits/s o \texttt{ksoftirqd} estava usando a \textit{CPU} próximo de 100\%.
Possivelmente o \texttt{ksoftirqd} estava processando as interrupções de software. Isso ocupou uma \textit{CPU} inteira enquanto que  o \texttt{iperf} ocupou a outra \textit{CPU}.

Já com limites maiores que 1, o uso de \textit{CPU} se limitou a 100\%.
Isso foi devido tanto ao sistema quanto ao \texttt{iperf} dividirem a mesma \textit{CPU} e não conseguirem processar os pacotes paralelamente.
Em 300 Mbits/s, o sistema atingiu 100\% e houve perda de pacotes, mas diferentemente do que aconteceu com limite igual a 1, as interrupções não ocuparam 100\% da \textit{CPU} como mostrado na Figura \ref{vbox_soft}. 
Nesse caso, o sistema perdeu os pacotes no \texttt{iperf}, que divide a \textit{CPU} com as interrupções, e não conseguiu \textit{CPU} o suficiente para processar os pacotes.
Somente quando a largura de banda de transmissão se aproximou de 800 Mbits/s, o sistema teve uma considerável redução de uso de \textit{CPU} pelas interrupções de software permitindo o \texttt{iperf} usar mais a \textit{CPU}.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/buffer/cpu.eps}
\caption{Uso da CPU no VirtualBox}
\label{vbox_cpu}
\end{center}
\end{figure}

Na Figura \ref{vbox_cpu_f} mostramos o uso da \textit{CPU} da máquina virtual usando o monitor \texttt{top} na máquina física. 
Comparando com a medição feita dentro da máquina virtual mostrada na Figura \ref{vbox_cpu}, percebemos que existe uma carga adicional de \textit{CPU} pela virtualização da máquina.
Nesse caso, consideramos o resultado da máquina física, pois a máquina virtual não considera o uso da \textit{CPU} da emulação do sistema e  dos dispositivos de rede.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/buffer/cpu_maquina_pura.eps}
\caption{Uso da CPU pela máquina física}
\label{vbox_cpu_f}
\end{center}
\end{figure}

\subsubsection{Conclusão}
Nesse experimento percebemos que uma única \textit{CPU} é dividida entre as interrupções de software e o \texttt{iperf} o que causa perda de pacotes no \texttt{iperf}.
Vimos que com exceção da configuração com limite igual a 1, todos tiveram uma redução no uso de \textit{CPU} com transmissão acima de 700 Mbits/s. Isso será melhor analisado no próximo experimento.
Também vimos que o processamento das interrupções de software quando ocupa uma \textit{CPU} inteira, faz o sistema alocar processos, nesse caso o \texttt{iperf}, para outra \textit{CPU}.
Percebemos uma diferença no resultado da medição dentro e fora da máquina virtual, foi considerado o resultado da medição fora da máquina virtual.
No próximo experimento separaremos em diferentes \textit{CPUs} as interrupções de software do \texttt{iperf} para que o sistema possa ter um melhor proveito da \textit{CPU}.
\clearpage
%-----------------------------------------------------------------------------------------------------
\subsection{VirtualBox com Afinidade de CPU}
No experimento anterior, vimos que as interrupções de software e o \texttt{iperf} usam a mesma \textit{CPU} e como resultado, o \texttt{iperf} não conseguiu processar todos os pacotes. Assim, temos duas soluções: definir uma \textit{CPU} para o \texttt{iperf} ser executado ou definir uma \textit{CPU} para a interrupção.
A configuração de associar um processo a uma determinada \textit{CPU} é chamada de afinidade de \textit{CPU}, já a de associar uma interrupção a uma \textit{CPU} é chamada de balanceamento de interrupções.
Decidimos associar uma \textit{CPU} para o \texttt{iperf} por ser uma solução simples feita através da ferramenta \texttt{taskset}.
Nesse experimento, foram usados o mesmo \textit{hardware} e sistema operacional do experimento anterior.

\subsubsection{Largura de Banda e Recepção pelo \textit{Driver}}
As Figuras \ref{vbox_core_iperf} e \ref{vbox_core_if} mostram respectivamente a largura de banda recebida pelo \texttt{iperf} e a quantidade de pacotes recebida pelo \textit{driver} no VirtualBox. 
Percebemos que são muito semelhantes e não existe uma queda na banda como no experimento anterior (Figura \ref{vbox_iperf}). Notamos também que com limite igual a 1 continua tendo perdas de pacotes no \textit{driver}. 

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/iperf.eps}
\caption{Largura de banda de recepção no VirtualBox com afinidade de CPU}
\label{vbox_core_iperf}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/ifconfig.eps}
\caption{Quantidade de pacotes recebida pelo driver no VirtualBox com afinidade de CPU}
\label{vbox_core_if}
\end{center}
\end{figure}

\subsubsection{Uso de CPU}
Na Figura \ref{vbox_core_cpu_f} é mostrado o uso da \textit{CPU} pelo VirtualBox na máquina física. 
Vemos que o uso de \textit{CPU} muito foi maior que em relação ao experimento passado (Figura \ref{vbox_cpu_f}) chegando a ultrapassar 200\%. Esse aumento foi devido a configuração de afinidade de \textit{CPU}.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/cpu_maquina_pura.eps}
\caption{uso da CPU pela máquina física com afinidade de CPU}
\label{vbox_core_cpu_f}
\end{center}
\end{figure}

Notamos que como no experimento anterior, em transmissões acima de 700 Mbits/s houve uma redução no uso de \textit{CPU}. 
Usando o \texttt{dmesg}, programa que imprime as mensagens do núcleo do sistema, e modificando o código fonte do \textit{driver} para imprimir a quantidade de pacotes por ciclo de varredura, veremos a causa dessa redução.
Iremos dividir essa explicação em dois cenários: entre 700 Mbits/s e 800 Mbits/s e acima de 800 Mbits/s. 
\newline

\clearpage
Entre 700 Mbits/s e 800 Mbits/s, as Figuras \ref{vbox_dmesg700} e \ref{vbox_dmesg800} mostram a frequência de pacotes processada por ciclo de varredura com limite igual a 60 e respectivamente largura de banda de transmissão igual a 700 e 800 Mbits/s.
Com transmissão de 700 Mbits/s, nota-se que o sistema processa num intervalo entre 5 e 12 pacotes, já com 800 Mbits/s o sistema passa a processar quantidades maiores de pacotes, ainda na maioria das vezes é processado entre 5 e 12 pacotes, mas em frequência menor.
Com o aumento de pacotes processados por ciclo de varredura, a quantidade de ciclos para processar todos os pacotes é reduzida e, consequentemente, o uso de \textit{CPU} pelas interrupções de software.

\begin{figure}[h!]
\centering
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/dmesg_700.eps}
\caption{Quantidade de pacotes processada por ciclo de varredura com largura de banda de transmissão de 700 Mbits/s}
\label{vbox_dmesg700}
\end{figure}

\begin{figure}[h!]
\centering
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/dmesg_800.eps}
\caption{Quantidade de pacotes processada por ciclo de varredura com largura de banda de transmissão de 800 Mbits/s}
\label{vbox_dmesg800}
\end{figure}
 
Com limite igual a 2, o sistema é capaz de processar no máximo 2 pacotes por ciclo. 
Nesse caso, não teria como reduzir a quantidade de ciclos de varredura, então o sistema processa continuamente os pacotes em vários ciclos contínuos de varredura.
Como exemplo, se 10 pacotes foram processados em um ciclo com limite igual a 60,
com limite igual a 2, seriam necessários 5 ciclos, em que 2 pacotes serão processados a cada ciclo. 
Entre ciclos, normalmente o sistema reabilita as interrupções de \textit{hardware} e espera a chegada de pacotes, mas como o limite de 2 foi atingido e há pacotes esperando serem processados, o sistema não reabilita as interrupções e executa outro ciclo de varredura.
\newline

A Figura \ref{vbox_core_int} mostra a taxa de interrupções de \textit{hardware} por segundo em relação a largura de banda. 
Com limite igual a 1 e largura de banda igual a 500 Mbits/s a taxa de interrupções de \textit{hardware} se aproximou de 0 e, nesse caso, os pacotes foram processados continuamente em vários ciclos de varredura. Consequentemente, a quantidade de tarefas de varredura sobrecarregou o sistema e este passou a descartar pacotes.
Com limite igual a 2 a taxa de interrupções não se aproximou de 0, mas comparando com limite igual a 60 e 200, teve maiores agregações de interrupções de \textit{hardware}, pois muitas vezes o sistema teve que processar em ciclos contínuos de varredura.
Com limite igual a 60 e 200 houve uma redução na taxa de interrupções quando a banda foi maior que 800 Mbits/s. Isto pode ser explicado pelo gráfico de frequência de pacotes por ciclo de varredura mostradas nas Figuras \ref{vbox_dmesg700} e \ref{vbox_dmesg800}.
Com o aumento na frequência de pacotes, menos ciclos de varredura são necessários e menor a taxa de interrupções de \textit{hardware}.
Pelos resultados de largura de banda e uso de \textit{CPU} não houve muita diferença entre reduzir a quantidade de ciclos de varredura e agregar as interrupções através de ciclos contínuos de varredura variando o limite.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/int.eps}
\caption{Quantidade de interrupções de hardware gerada pela placa de rede virtual no VirtualBox}
\label{vbox_core_int}
\end{center}
\end{figure}

Acima de 800 Mbits/s de transmissão, percebe-se que mesmo com o limite de largura de banda de transmissão sendo de 810 Mbits/s, existe uma diferença entre o uso da \textit{CPU}.
Na Figura \ref{vbox_dmesg1000} é mostrada a frequência de pacotes processada por ciclo de varredura com banda de transmissão igual a 1000 Mbits/s e limite igual a 60.
Observa-se que em relação ao gráfico de 800 Mbits/s, com 1000 Mbits/s, o sistema processou mais pacotes por ciclo de varredura. Um resultado curioso, pois como a transmissão máxima é de 810 Mbits/s, ambos deveriam mostrar resultados semelhantes.
Este resultado ocorreu pela forma como o \texttt{iperf} transmite os pacotes. Olhando o código-fonte do \texttt{iperf}, quando se é usado o protocolo \textit{UDP}, existe um atraso entre envios de pacotes que é calculado pela formula: 

\begin{gather*}
atraso\_entre\_envios = \frac{tamanho\_do\_pacote}{largura\_de\_banda\_de\_transmissão} + reajuste
\end{gather*}

Onde reajuste é o valor reajuste de acordo com o tempo gasto no laço para transmitir o pacote. 
Assim, quanto maior a largura de banda de transmissão, menor o atraso entre envios. 
Quando a taxa de transmissão do \texttt{iperf} é maior que o máximo que o dispositivo de rede é capaz de transmitir, os pacotes são enviados inicialmente em atrasos menores e conforme o dispositivo é sobrecarregado de pacotes para transmitir, o \texttt{iperf} reajusta o valor de atraso.
Com esse ajuste dinâmico de envios, é muito provável que ocorra mais rajadas de grande quantidade de pacotes, do que se tentasse transmitir com o atraso entre envios constante podendo alterar o desempenho na recepção de pacotes.

\begin{figure}[h!]
\centering
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/dmesg_1000.eps}
\caption{Quantidade de pacotes processada por ciclo de varredura com largura de banda de transmissão de 1000 Mbits/s}
\label{vbox_dmesg1000}
\end{figure}
\clearpage
\subsubsection{Interrupções de Software}
Nas Figuras \ref{vbox_core_soft} e \ref{vbox_core_cpu} é mostrado o uso da \textit{CPU} respectivamente pelas interrupções de software e total. 
Comparando com os resultados sem afinidade de \textit{CPU}, percebemos que o uso de \textit{CPU} pelas interrupções de software e total foram muito menores.
Mas como já foi mostrado na Figura \ref{vbox_core_cpu_f}, o uso da \textit{CPU} pelo VirtualBox foi muito maior em relação ao experimento anterior.
Não foi possível descobrir o motivo do \texttt{sar} mostrar uma redução do uso de \textit{CPU} dentro da máquina. É possível que seja um problema do próprio VirtualBox.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/soft.eps}
\caption{Uso da CPU pelas interrupções de software no VirtualBox com afinidade de CPU}
\label{vbox_core_soft}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/virtualbox/core/cpu.eps}
\caption{Uso da CPU no VirtualBox com afinidade de CPU}
\label{vbox_core_cpu}
\end{center}
\end{figure}
\clearpage
\subsubsection{Conclusão}
Concluímos que separando o \texttt{iperf} das interrupções, é possível aproveitar melhor a \textit{CPU} para o processamento de pacotes. Porém, isso gera uma carga extra no processamento, quando não necessita usar duas \textit{CPUs}. 
Assim, é interessante saber se os processos usarão mais de uma \textit{CPU} ou se uma será o suficiente.

Novamente, com exceção do experimento com limite igual a 1, vimos o uso de \textit{CPU} reduzir entre 700 Mbits/s e 800 Mbits/s. 
Há duas explicações, a agregação de interrupções através do processamento contínuo de pacotes e a redução de ciclos de varredura.

Percebemos que o \texttt{iperf} configurado para enviar pacotes em taxas maiores que a capacidade do dispositivo passa a ajustar a transmissão dinamicamente, alterando a frequência de envio e aumentando a quantidade de rajadas longas de pacotes. 
Isso provavelmente fez reduzir o uso da \textit{CPU} com 900 Mbits/s e 1000 Mbits/s em relação ao resultado com 800 Mbits/s.

Também concluímos que o parâmetro de limite não afeta a largura de banda ou o uso real da \textit{CPU}, a não ser que o valor seja muito baixo.
As medições de dentro da máquina virtual não mostraram com precisão o uso da \textit{CPU} pelas interrupções de software quando usamos duas \textit{CPUs}, não foi possível descobrir a causa.

%\subsubsection{Interrupções de Hardware}
%Na Figura \ref{vbox_core_int}, em todos limites vemos que a quantidade de interrupções por segundo tem um intervalo de crescimento seguido de uma queda. Quanto menor o limite, mais rápida é a queda e com menos banda ela começa a decrescer. Esse crescimento pode ser explicado pela chegada de pacotes em taxas cada vez maiores enquanto que a queda pode ser explicada pelo mecanismo de varredura da \textit{NAPI}.
%
%Com o limite igual a 1, a redução das interrupções se inicia com banda de 300 Mbits/s e em 600 Mbits/s o núcleo do sistema chega ao máximo dessa redução passando a processar os pacotes sem a necessidade de tratar interrupções.
%O mesmo comportamento ocorre com limite igual a 2, 60 e 200, iniciando a redução um pouco mais lenta em relação ao experimento com limite igual a 1 com banda respectivamente igual a 300 Mbits/s, 700 Mbits/s e 700 Mbits/s, mas a redução não chega ao máximo porque a banda de transmissão não é capaz de ultrapassar 810 Mbits/s.
%


\clearpage
%-----------------------------------------------------------------------------------------------------

\subsection{Xen}
Nos experimentos com o Xen, ocorreram problemas tanto no \textit{buffer} do \textit{socket} quanto no uso da mesma \textit{CPU} pelo \texttt{iperf} e as interrupções de software como no experimento com o VirtualBox. 
Para resolvê-los, novamente aumentamos o tamanho do \textit{buffer} e associamos uma \textit{CPU} para o \texttt{iperf}.\newline

Nas Figuras \ref{xen_iperf} e \ref{xen_if} que mostram respectivamente a banda de recepção, a quantidade de pacotes recebida pelo \textit{driver}, ocorreu uma situação semelhante a vista no VirtualBox, ambos os gráficos ficaram iguais e com limite igual a 1, houve perda de pacotes, porém, ao invés da perda ocorrer quando a transmissão é maior que 400 Mbits/s como no caso do VirtualBox, esta ocorre com transmissões maiores que 600 Mbits/s. O limite da transmissão novamente é próximo de 810 Mbits/s. \newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/xen/buffer/iperf.eps}
\caption{Largura de banda de recepção no Xen}
\label{xen_iperf}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/xen/buffer/ifconfig.eps}
\caption{Quantidade de pacotes recebida pelo driver no Xen}
\label{xen_if}
\end{center}
\end{figure}

Na Figura \ref{xen_cpu}, vemos o uso de \textit{CPU} da máquina virtual. 
Esses dados foram obtidos através do \texttt{xentop}, aplicação de monitoramento que o Xen fornece. 
Percebe-se que o uso de \textit{CPU} é maior quanto maior o limite, mas entre experimentos com limite igual a 60 ou 200 quase não existe diferença.
Nota-se também que o uso de \textit{CPU} não excedeu 100\%, mas com limite igual a 1 e largura de banda maior que 600 Mbits/s o sistema parece estar no máximo não conseguindo exceder o uso da \textit{CPU}.
Acima de 800 Mbits/s o sistema parece reduzir pouco o uso da \textit{CPU}.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/xen/buffer/cpu_puro.eps}
\caption{uso da CPU no Xen}
\label{xen_cpu}
\end{center}
\end{figure}

Nas medições de uso de \textit{CPU} dentro da máquina virtual ocorreu algo semelhante ao experimento do VirtualBox. Houve uma diferença entre a medição interna e externa. Então, desconsideramos a medição interna.

\subsubsection{Conclusão}
No Xen, percebemos que o uso de \textit{CPU} pelo tráfego de rede foi menor em relação ao VirtualBox. 
Também notamos que com limite igual a 1, o sistema é capaz de processar mais pacotes. 
Entre 700 Mbits/s e 800 Mbits/s novamente com exceção do experimento com limite igual a 1, houve uma redução no uso da \textit{CPU} mas muito menor em relação ao VirtualBox.
Com limites igual a 1 vimos que novamente houve perda de pacotes já com limite igual a 2 houve um uso maior da \textit{CPU} em relação aos limites iguais a 60 e 200.
%-----------------------------------------------------------------------------------------------------

\clearpage
\subsection{VMware}
No VMware, ocorreram os mesmos problemas do Xen e do VirtualBox então reconfiguramos o \textit{buffer} do \textit{socket} e a afinidade de \textit{CPU} do \texttt{iperf}.\newline

Nas Figuras \ref{vmware_iperf} e \ref{vmware_if}, que mostram respectivamente a banda de recepção e a quantidade de pacotes recebida pelo \textit{driver}, ambos os gráficos ficaram iguais.
Com limite igual a 1 e 2, houve perda de pacotes quando a transferência é maior que 400 Mbits/s. Notamos que houve perda de pacotes com banda de transmissão maior que 800 Mbits/s. O limite da transmissão, novamente, é próximo de 810 Mbits/s.\newline

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/vmware/buffer/iperf.eps}
\caption{Largura de banda de recepção no VMware}
\label{vmware_iperf}
\end{center}
\end{figure}

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/vmware/buffer/ifconfig.eps}
\caption{Quantidade de pacotes recebida pelo driver no VMware}
\label{vmware_if}
\end{center}
\end{figure}

Na Figura \ref{vmware_cpu}, observamos que o uso de \textit{CPU} chega ao máximo quando a largura de banda é maior que 200 Mbits/s, tendo uma queda entre 700 Mbits/s e 800 Mbits/s provavelmente pela transmissão rápida de pacotes. Acima de 800 Mbits/s nota-se que o uso de \textit{CPU} não variou.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=300pt,height=220pt]{./img/banda/vmware/buffer/cpu_puro.eps}
\caption{Uso da CPU no VMware}
\label{vmware_cpu}
\end{center}
\end{figure}

\subsubsection{Conclusão}
Vimos que, com largura de banda maior que 800 Mbits/s, há perda de pacotes, enquanto que nos outros \textit{hypervisors}, a banda permanece constante e o uso de \textit{CPU} é reduzida. 
Provavelmente, o sistema não conseguiu processar os pacotes em grandes rajadas.
Com limite igual a 1 e 2 houve perda de pacotes com transferência maior que 400 Mbits/s.

%-----------------------------------------------------------------------------------------------------

\section{Análise dos Resultados}
Na Tabela \ref{hypervisors}, é comparado os resultados com diferentes hypervisors.
Em todos experimentos, tivemos que configurar o tamanho do \textit{buffer} do \textit{socket} e selecionar a \textit{CPU} na qual o \texttt{iperf} seria executado pois estavam comprometendo a medição.

Em nossos experimentos, percebemos que o parâmetro limite com valores baixos (1 e 2) causou perda de pacotes ou aumento de uso da \textit{CPU} comparado com os limites altos (60 e 200).
Houve um bom desempenho tanto em uso de \textit{CPU} como largura de banda com limites altos na maioria dos casos e não houve diferença no resultado entre limites altos.

Entre 700 e 800 Mbits/s em todos experimentos, houve uma redução de uso de \textit{CPU} devido a agregação de interrupções através do processamento contínuo de pacotes e a redução de ciclos de varredura.
Valores de banda de transmissão acima de 800 Mbits/s causaram um aumento de rajadas longas de pacotes. 
No VMware, isso gerou perdas de pacotes, no VirtualBox e no Xen houve uma redução de uso de \textit{CPU}.

Houve uma grande diferença no uso de \textit{CPU} pelas máquinas virtuais. 
O VirtualBox foi o que mais gastou \textit{CPU} com até 270\% de uso. 
Já o Xen foi o que menos gastou com até 80\% de uso. 
Por fim, o VMware gastou até 175\% da \textit{CPU}, porém, ele chegou ao limite de uso de \textit{CPU} mais rápido, enquanto que os outros \textit{hypervisors}, atingiram o máximo com 700 Mbits/s, o VMware atingiu o máximo em 300 Mbits/s.

\begin{figure}[h!]
\begin{center}
	\includegraphics[angle=90,origin=c,width=1.0\textwidth]{planilha.pdf}
  \caption{Planilha comparando os resultados com diferentes hypervisors}
\label{hypervisors}
\end{center}
\end{figure}

\clearpage