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?

Referências

[1] A especificação oficial do USB 2.0

[2] Espelho pdf rápido da especificação

Em algum momento da minha vida, eu costumava administrar o negócio de USB para uma grande empresa semi. O melhor resultado que me lembro foi o controlador NEC SATA capaz de aumentar a taxa de transferência real de 320 Mbps para armazenamento em massa, provavelmente as unidades sata atuais são capazes disso ou um pouco mais. Este estava usando o BOT (algum protocolo de armazenamento em massa é executado em USB).

Posso dar uma resposta técnica detalhada, mas acho que você pode deduzir-se. O que você precisa ver é que, esse é um jogo do ecossistema, qualquer melhoria significativa exigiria que alguém como a Microsoft alterasse sua pilha, otimize etc., o que não vai acontecer. A interoperabilidade é muito mais importante que a velocidade. Como as pilhas existentes cobrem cuidadosamente os erros de grande quantidade de dispositivos por aí, porque quando as especificações USB2 são lançadas, provavelmente os dispositivos iniciais não confirmaram realmente as especificações, já que as especificações eram com erros, o sistema de certificação era com erros etc. Se você criar um sistema de fermentação doméstica usando Linux ou drivers de host USB personalizados para MS e um controlador de dispositivo rápido, provavelmente poderá se aproximar dos limites teóricos.

Em termos de streaming, o ISO deveria ser muito rápido, mas os controladores não o implementam muito bem, pois 95% dos aplicativos usam transferência em massa.

Como um insight adicional, por exemplo, se você construir um IC de hub hoje, se seguir as especificações até o ponto, praticamente venderá zero chips. Se você conhece todos os bugs do mercado e se certifica de que o IC do seu hub os tolera, provavelmente poderá entrar no mercado. Ainda estou surpreso hoje, como o USB está funcionando, dado o número de softwares e chips ruins por aí.

Este é um tópico muito antigo, mas ainda não tem resposta. Esta é a minha tentativa:

Por que as implementações atuais não são capazes de transmitir a 53 MB / s?

Os cálculos são quase bons, mas você está esquecendo algumas coisas no número disponível de bytes entre os marcadores de quadro:

1. Cada microframe possui dois limites chamados EOF1 e EOF2. Nenhuma atividade de barramento deve ocorrer no / após EOF1. A colocação desse ponto é uma coisa complicada, mas a posição típica é de 560 bits antes do próximo SOF. Um host deve agendar suas transações de forma que qualquer resposta possível do canal não atinja esse limite. Que consome cerca de 70 bytes dos 7487 bytes calculados.

2. Você assume "dados aleatórios". Isso é completamente infundado, os dados podem ser qualquer coisa. Portanto, o host deve agendar transações para a pior carga útil, com sobrecarga máxima de preenchimento de bits, 512 * 7/6 = ~ 600 bytes. Mais 24 bytes de sobrecarga de transação, como você calculou com razão. Isso fornece (7487-70) / 624 = 11,88 transações por micro-frame.

3. É necessário que o host reserve cerca de 10% das larguras de banda para transações de controle para qualquer outra atividade, para que possamos obter cerca de 10,7 transações.

4. O controlador host também possui certa latência ao gerenciar sua lista vinculada, portanto, há uma lacuna adicional entre as transações.

5. O dispositivo pode estar a 5 hubs / hops longe da raiz e o atraso da resposta pode chegar a 1700 ns, o que consome outros 106 bytes de cada orçamento de transação. Na estimativa bruta, ele realiza apenas 10,16 transações por uFrame, sem contar com a largura de banda reservada.

O host não pode realizar o agendamento adaptativo com base na chegada real da transação no uFrame, seria proibitivo da perspectiva do software; portanto, o driver usa o agendamento mais conservador, até 9 transações em massa por uFrame, o que equivale a 36 Mbytes / segundo. É isso que um pen drive USB muito bom pode oferecer.

Alguns benchmarks artificiais malucos podem chegar a 11 transações por uFrame, o que faz 44 MBps. E este é o máximo absoluto para o protocolo HS USB.

Onde está o gargalo nas implementações de hoje?

Como se pode ver acima, não há gargalo, todo o espaço de tempo em bits é consumido pela sobrecarga do protocolo.