Motivación
Con una velocidad de señalización de 480 MBit / s, los dispositivos USB 2.0 deberían poder transmitir datos con hasta 60 MB / s. Sin embargo, los dispositivos actuales parecen estar limitados a 30-42 MB / s mientras se lee [ Wiki: USB ]. Esa es una sobrecarga del 30 por ciento.
USB 2.0 ha sido un estándar de facto para dispositivos externos durante más de 10 años. Una de las aplicaciones más importantes para la interfaz USB desde el principio ha sido el almacenamiento portátil. Desafortunadamente, USB 2.0 fue rápidamente un cuello de botella que limitaba la velocidad de estas aplicaciones exigentes de ancho de banda, un HDD de hoy es capaz, por ejemplo, de más de 90 MB / s en lectura secuencial. Teniendo en cuenta la larga presencia en el mercado y la necesidad constante de un mayor ancho de banda, deberíamos esperar que el sistema eco USB 2.0 se haya optimizado a lo largo de los años y haya alcanzado un rendimiento de lectura cercano al límite teórico.
¿Cuál es el ancho de banda máximo teórico en nuestro caso? Cada protocolo tiene una sobrecarga que incluye USB y de acuerdo con el estándar oficial USB 2.0 es de 53.248 MB / s [ 2 , Tabla 5-10]. Eso significa que, en teoría , los dispositivos USB 2.0 actuales podrían ser un 25 por ciento más rápidos.
Análisis
Para acercarse a la raíz de este problema, el siguiente análisis demostrará lo que sucede en el bus mientras lee datos secuenciales de un dispositivo de almacenamiento. El protocolo se desglosa capa por capa y estamos especialmente interesados en la pregunta de por qué 53.248 MB / s es el número teórico máximo para dispositivos ascendentes masivos. Finalmente, hablaremos sobre los límites del análisis que podrían darnos algunos indicios de sobrecarga adicional.
Notas
En esta pregunta solo se utilizan prefijos decimales.
Un host USB 2.0 es capaz de manejar múltiples dispositivos (a través de hubs) y múltiples puntos finales por dispositivo. Los puntos finales pueden operar en diferentes modos de transferencia. Limitaremos nuestro análisis a un solo dispositivo que esté conectado directamente al host y que sea capaz de enviar continuamente paquetes completos a través de un punto final masivo ascendente en modo de alta velocidad.
Enmarcado
La comunicación USB de alta velocidad se sincroniza en una estructura de trama fija. Cada trama tiene una longitud de 125 us y comienza con un paquete de inicio de trama (SOF) y está limitada por una secuencia de fin de trama (EOF). Cada paquete comienza con SYNC y termina con y End-Of-Packet (EOF). Esas secuencias se han agregado a los diagramas para mayor claridad. EOP es de tamaño variable y depende del paquete de datos, para SOF siempre es de 5 bytes.
Abra la imagen en una pestaña nueva para ver una versión más grande.
Actas
USB es un protocolo controlado por el maestro y el host inicia cada transacción. El intervalo de tiempo entre SOF y EOF se puede usar para transacciones USB. Sin embargo, el tiempo para SOF y EOF es muy estricto y el host solo inicia transacciones que se pueden completar por completo dentro del intervalo de tiempo libre.
La transacción que nos interesa es una transacción masiva exitosa. La transacción comienza con un paquete token IN, luego los hosts esperan un paquete de datos DATA0 / DATA1 y confirman la transmisión con un paquete de protocolo de enlace ACK. El EOP para todos estos paquetes es de 1 a 8 bits dependiendo de los datos del paquete, asumimos el peor de los casos aquí.
Entre cada uno de estos tres paquetes tenemos que considerar los tiempos de espera. Estos se encuentran entre el último bit del paquete IN del host y el primer bit del paquete DATA0 del dispositivo y entre el último bit del paquete DATA0 y el primer bit del paquete ACK. No tenemos que considerar más demoras ya que el host puede comenzar a enviar la próxima IN justo después de enviar un ACK. El tiempo de transmisión del cable se define como máximo 18 ns.
Una transferencia masiva puede enviar hasta 512 bytes por transacción IN. Y el host intentará emitir tantas transacciones como sea posible entre los delimitadores de trama. Aunque la transferencia masiva tiene baja prioridad, puede ocupar todo el tiempo disponible en un espacio cuando no hay otra transacción pendiente.
Para garantizar una recuperación adecuada del reloj, los estándares definen un método de relleno de bits de llamada. Cuando el paquete requeriría una secuencia muy larga de la misma salida, se agrega un flanco adicional. Eso asegura un flanco después de un máximo de 6 bits. En el peor de los casos, esto aumentaría el tamaño total del paquete en 7/6. El EOP no está sujeto a relleno de bits.
Abra la imagen en una pestaña nueva para ver una versión más grande.
Cálculos de ancho de banda
Una transacción de entrada masiva tiene una sobrecarga de 24 bytes y una carga útil de 512 bytes. Eso es un total de 536 bytes. El intervalo de tiempo entre es de 7487 bytes de ancho. Sin la necesidad de relleno de bits, hay espacio para 13.968 paquetes. Con 8000 Micro-marcos por segundo, podemos leer datos con 13 * 512 * 8000 B / s = 53.248 MB / s
Para datos totalmente aleatorios, esperamos que el relleno de bits sea necesario en una de 2 ** 6 = 64 secuencias de 6 bits consecutivos. Eso es un aumento de (63 * 6 + 7) / (64 * 6). Multiplicar todos los bytes que están sujetos al relleno de bits por esos números da una longitud de transacción total de (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537.38 Bytes. Lo que resulta en 13.932 paquetes por Micro-Frame.
Hay otro caso especial que falta en estos cálculos. El estándar define un tiempo máximo de respuesta del dispositivo de 192 bit veces [ 2 , Capítulo 7.1.19.2]. Esto debe tenerse en cuenta al decidir si el último paquete todavía cabe en el marco en caso de que el dispositivo necesite el tiempo de respuesta completo. Podríamos explicar eso usando una ventana de 7439 bytes. Sin embargo, el ancho de banda resultante es idéntico.
Lo que queda
La detección y recuperación de errores no se ha cubierto. Tal vez los errores son lo suficientemente frecuentes o la recuperación del error lleva tiempo suficiente como para tener un impacto en el rendimiento promedio.
Asumimos una reacción instantánea del host y el dispositivo después de los paquetes y la transacción. Personalmente, no veo la necesidad de grandes tareas de procesamiento al final de los paquetes o transacciones en ninguno de los lados y, por lo tanto, no puedo pensar en ninguna razón por la cual el host o el dispositivo no puedan responder instantáneamente con implementaciones de hardware suficientemente optimizadas. Especialmente en el funcionamiento normal, la mayor parte del trabajo de contabilidad y detección de errores podría realizarse durante la transacción y los siguientes paquetes y transacciones podrían ponerse en cola.
No se han considerado transferencias para otros puntos finales o comunicaciones adicionales. Tal vez el protocolo estándar para dispositivos de almacenamiento requiere alguna comunicación continua de canal lateral que consuma un valioso tiempo de ranura.
Puede haber una sobrecarga de protocolo adicional para dispositivos de almacenamiento para el controlador del dispositivo o la capa del sistema de archivos. (paquete de carga útil == datos de almacenamiento?)
Pregunta
¿Por qué las implementaciones de hoy no son capaces de transmitir a 53 MB / s?
¿Dónde está el cuello de botella en las implementaciones de hoy?
Y un posible seguimiento: ¿por qué nadie ha tratado de eliminar ese cuello de botella?