Motivação
Com uma taxa de sinalização de 480 MBit / s, os dispositivos USB 2.0 devem poder transmitir dados com até 60 MB / s. No entanto, os dispositivos atuais parecem estar limitados a 30-42 MB / s durante a leitura [ Wiki: USB ]. Isso representa uma sobrecarga de 30%.
O USB 2.0 é um padrão de fato para dispositivos externos há mais de 10 anos. Uma das aplicações mais importantes para a interface USB desde o início foi o armazenamento portátil. Infelizmente, o USB 2.0 foi rapidamente um gargalo limitador de velocidade para esses aplicativos exigentes de largura de banda, o HDD de hoje é capaz, por exemplo, de mais de 90 MB / s em leitura seqüencial. Considerando a longa presença no mercado e a constante necessidade de maior largura de banda, devemos esperar que o sistema eco USB 2.0 tenha sido otimizado ao longo dos anos e tenha atingido um desempenho de leitura próximo ao limite teórico.
Qual é a largura de banda máxima teórica no nosso caso? Todo protocolo possui sobrecarga, incluindo USB e, de acordo com o padrão oficial USB 2.0, é de 53.248 MB / s [ 2 , Tabela 5-10]. Teoricamente, isso significa que os dispositivos USB 2.0 atuais podem ser 25% mais rápidos.
Análise
Para chegar perto da raiz desse problema, a análise a seguir demonstrará o que está acontecendo no barramento durante a leitura de dados seqüenciais de um dispositivo de armazenamento. O protocolo é dividido camada por camada e estamos especialmente interessados na questão de por que 53.248 MB / s é o número teórico máximo para dispositivos upstream em massa. Finalmente, falaremos sobre os limites da análise que podem nos dar algumas dicas de sobrecarga adicional.
Notas
Ao longo desta pergunta, apenas prefixos decimais são usados.
Um host USB 2.0 é capaz de lidar com vários dispositivos (via hubs) e vários pontos de extremidade por dispositivo. Os terminais podem operar em diferentes modos de transferência. Limitaremos nossa análise a um único dispositivo diretamente conectado ao host e capaz de enviar pacotes completos continuamente por um endpoint em massa upstream no modo de alta velocidade.
Enquadramento
A comunicação USB de alta velocidade é sincronizada em uma estrutura de quadro fixo. Cada quadro tem 125 nós de comprimento e começa com um pacote Start-Of-Frame (SOF) e é limitado por uma sequência de fim de quadro (EOF). Cada pacote começa com SYNC e termina com E-Fim de pacote (EOF). Essas seqüências foram adicionadas aos diagramas para maior clareza. O EOP é variável em tamanho e depende dos dados do pacote, para SOF é sempre de 5 bytes.
Abra a imagem em uma nova guia para ver uma versão maior.
Transações
USB é um protocolo orientado a mestre e cada transação é iniciada pelo host. O intervalo de tempo entre SOF e EOF pode ser usado para transações USB. No entanto, o tempo para SOF e EOF é muito rigoroso e o host inicia apenas transações que podem ser totalmente concluídas dentro do intervalo de tempo livre.
A transação na qual estamos interessados é uma transação IN em massa bem-sucedida. A transação começa com um pacote tocken IN, então os hosts aguardam um pacote de dados DATA0 / DATA1 e confirma a transmissão com um pacote de handshake ACK. O EOP para todos esses pacotes é de 1 a 8 bits, dependendo dos dados do pacote, assumimos o pior caso aqui.
Entre cada um desses três pacotes, temos que considerar os tempos de espera. Esses estão entre o último bit do pacote IN do host e o primeiro bit do pacote DATA0 do dispositivo e entre o último bit do pacote DATA0 e o primeiro bit do pacote ACK. Não precisamos considerar atrasos adicionais, pois o host pode começar a enviar a próxima entrada imediatamente após o envio de um ACK. O tempo de transmissão do cabo é definido como sendo no máximo 18 ns.
Uma transferência em massa pode enviar até 512 bytes por transação IN. E o host tentará emitir o maior número possível de transações entre os delimitadores de quadros. Embora a transferência em massa tenha baixa prioridade, pode levar todo o tempo disponível em um slot quando não houver outra transação pendente.
Para garantir a recuperação adequada do relógio, os padrões definem um enchimento de bits de chamada de método. Quando o pacote exigiria uma sequência muito longa da mesma saída, um flanco adicional será adicionado. Isso garante um flanco após um máximo de 6 bits. Na pior das hipóteses, isso aumentaria o tamanho total do pacote em 7/6. O EOP não está sujeito a recheio de bits.
Abra a imagem em uma nova guia para ver uma versão maior.
Cálculos de largura de banda
Uma transação IN em massa tem uma sobrecarga de 24 bytes e uma carga útil de 512 bytes. Isso é um total de 536 bytes. O intervalo de tempo entre é 7487 bytes de largura. Sem a necessidade de preenchimento de bits, há espaço para 13.968 pacotes. Tendo 8000 micro-frames por segundo, podemos ler dados com 13 * 512 * 8000 B / s = 53,248 MB / s
Para dados totalmente aleatórios, esperamos que o preenchimento de bits seja necessário em uma das 2 ** 6 = 64 seqüências de 6 bits consecutivos. Isso é um aumento de (63 * 6 + 7) / (64 * 6). A multiplicação de todos os bytes sujeitos a preenchimento de bits por esses números fornece um comprimento total de transação de (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 bytes. O que resulta em 13.932 pacotes por Micro-Frame.
Há outro caso especial ausente nesses cálculos. O padrão define um tempo máximo de resposta do dispositivo de 192 bits vezes [ 2 , capítulo 7.1.19.2]. Isso deve ser considerado ao decidir se o último pacote ainda se encaixa no quadro, caso o dispositivo precise de um tempo de resposta completo. Poderíamos explicar isso usando uma janela de 7439 bytes. A largura de banda resultante é idêntica.
O que sobrou
A detecção e recuperação de erros não foram cobertas. Talvez os erros sejam frequentes o suficiente ou a recuperação de erros consuma tempo o suficiente para afetar o desempenho médio.
Assumimos uma reação instantânea ao host e ao dispositivo após pacotes e transações. Pessoalmente, não vejo necessidade de grandes tarefas de processamento no final de pacotes ou transações de ambos os lados e, portanto, não consigo pensar em nenhum motivo pelo qual o host ou o dispositivo não possa responder instantaneamente com implementações de hardware suficientemente otimizadas. Especialmente em operação normal, a maior parte do trabalho de manutenção de livros e detecção de erros pode ser realizada durante a transação e os próximos pacotes e transações podem ser colocados na fila.
Transferências para outros pontos de extremidade ou comunicação adicional não foram consideradas. Talvez o protocolo padrão para dispositivos de armazenamento exija alguma comunicação contínua de canal lateral que consome um tempo valioso no slot.
Pode haver uma sobrecarga de protocolo adicional para dispositivos de armazenamento para o driver de dispositivo ou a camada do sistema de arquivos. (carga útil do pacote == dados de armazenamento?)
Questão
Por que as implementações atuais não são capazes de transmitir a 53 MB / s?
Onde está o gargalo nas implementações de hoje?
E um possível acompanhamento: por que ninguém tentou eliminar esse gargalo?