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?

Referencias

[1] La especificación oficial de USB 2.0

[2] Espejo pdf rápido de la especificación

En algún momento de mi vida, solía dirigir el negocio de USB para una gran semi empresa. El mejor resultado que recuerdo fue el controlador NEC SATA capaz de impulsar un rendimiento de datos real de 320 Mbps para almacenamiento masivo, probablemente las unidades sata actuales son capaces de esto o un poco más. Esto estaba usando BOT (algunos protocolos de almacenamiento masivo se ejecutan en USB).

Puedo dar una respuesta técnica detallada, pero supongo que puede deducirse. Lo que necesita ver es que, esto es un juego del ecosistema, cualquier mejora significativa requeriría que alguien como Microsoft cambie su stack, optimice, etc., lo que no va a suceder. La interoperabilidad es mucho más importante que la velocidad. Debido a que las pilas existentes cubren cuidadosamente los errores de una gran cantidad de dispositivos por ahí, porque cuando sale la especificación USB2, probablemente los dispositivos iniciales realmente no confirmaron bien la especificación ya que la especificación tenía errores, el sistema de certificación tenía errores, etc., etc. Si crea un sistema de preparación casera utilizando Linux o controladores de host USB personalizados para MS y un controlador de dispositivo rápido, probablemente pueda acercarse a los límites teóricos.

En términos de transmisión, se supone que el ISO es muy rápido, pero los controladores no lo implementan muy bien, ya que el 95% de las aplicaciones usan la transferencia masiva.

Como información adicional, por ejemplo, si vas y construyes un IC de centro hoy, si sigues las especificaciones hasta el punto, prácticamente venderás cero chips. Si conoce todos los errores en el mercado y se asegura de que su IC de centro pueda tolerarlos, probablemente pueda ingresar al mercado. Todavía estoy asombrado hoy, qué tan bien está funcionando el USB dada la cantidad de software y chips defectuosos que existen.

Este es un tema muy antiguo, pero aún no tiene respuesta. Este es mi intento:

¿Por qué las implementaciones de hoy no son capaces de transmitir a 53 MB / s?

Los cálculos son casi correctos, pero está olvidando un par de cosas en el número de bytes disponibles entre los marcadores de trama:

1. Cada microframe tiene dos umbrales llamados EOF1 y EOF2. No debe haber actividad del bus en / después de EOF1. La ubicación de este punto es algo complicado, pero la posición típica es 560 bits veces antes del próximo SOF. Un host debe programar sus transacciones de tal manera que cualquier respuesta posible del canal no alcance este umbral. Que consume alrededor de 70 bytes de los 7487 bytes calculados.

2. Asumes "datos aleatorios". Esto es completamente infundado, los datos pueden ser cualquier cosa. Por lo tanto, el host debe programar las transacciones para la peor carga útil, con una sobrecarga máxima de relleno de bits, 512 * 7/6 = ~ 600 bytes. Más 24 bytes de sobrecarga de transacciones, como lo calculó correctamente. Esto da (7487-70) / 624 = 11.88 transacciones por micro-frame.

3. Se requiere que el host reserve aproximadamente el 10% de los anchos de banda para las transacciones de control para cualquier otra actividad, por lo que obtenemos aproximadamente 10.7 transacciones.

4. El controlador de host también tiene cierta latencia al administrar su lista vinculada, por lo que hay una brecha adicional entre las transacciones.

5. El dispositivo puede estar a 5 concentradores / saltos lejos de la raíz, y el retraso de respuesta puede ser de hasta 1700 ns, lo que consume otros 106 bytes del presupuesto de cada transacción. En una estimación sin procesar, solo realiza 10.16 transacciones por uFrame, sin contar el ancho de banda reservado.

El host no puede hacer una reprogramación adaptativa basada en la llegada real de la transacción dentro del uFrame, sería prohibitivo desde la perspectiva del software, por lo que el controlador utiliza el programa más conservador, hasta 9 transacciones masivas por uFrame, que asciende a 36 Mbytes / segundo. Esto es lo que puede ofrecer una muy buena memoria USB.

Algunos puntos de referencia artificiales locos pueden ir hasta 11 transacciones por uFrame, lo que hace que sea 44 MBps. Y este es el máximo absoluto para el protocolo USB HS.

¿Dónde está el cuello de botella en las implementaciones de hoy?

Como se puede ver arriba, no hay botleneck, todo el espacio de tiempo de bits en bruto se consume por la sobrecarga del protocolo.