La motivación
Con una tasa de señalización de 480 MBit/s, USB 2.0 dispositivos deben ser capaces de transmitir datos con hasta 60 MB/s. Sin embargo hoy en día los dispositivos parecen estar limitado a 30-42 MB/s mientras que la lectura de [Wiki:USB]. Que es un 30 por ciento de sobrecarga.
USB 2.0, ha sido un estándar de facto para dispositivos externos por más de 10 años. Uno de los más importantes de la aplicación para la interfaz USB desde el principio ha sido de almacenamiento portátil. Por desgracia USB 2.0 fue rápidamente una limitación de velocidad de cuello de botella a estos ancho de banda de las aplicaciones más exigentes, hoy HDD es, por ejemplo, capaz de más de 90 MB/s en lectura secuencial. Considerando la larga presencia en el mercado y la constante necesidad de mayor ancho de banda, debemos esperar que el USB 2.0 eco sistema ha sido optimizado a lo largo de los años y ha alcanzado un rendimiento de lectura que está cerca del límite teórico.
¿Cuál es el ancho de banda máximo teórico en nuestro caso? Cada protocolo tiene la parte de arriba incluyendo USB y de acuerdo con el funcionario estándar USB 2.0 es 53.248 MB/s [2, Tabla 5-10]. Eso significa que, teóricamente, hoy en día los dispositivos USB 2.0 podría ser un 25% más rápido.
Análisis
Para llegar a ninguna parte cerca de la raíz de este problema, el siguiente análisis se demuestra lo que está sucediendo en el autobús, mientras que la lectura secuencial de datos desde un dispositivo de almacenamiento. El protocolo se divide capa por capa, y estamos especialmente interesados en la cuestión de por qué 53.248 MB/s es el máximo número teórico de carga a granel para arriba dispositivos. Por último vamos a hablar de los límites de los análisis que podría darnos algunas pistas de sobrecarga adicional.
Notas
A lo largo de esta pregunta sólo decimal se utilizan prefijos.
Un host USB 2.0 es capaz de manejar múltiples dispositivos (a través de hubs) y varios extremos por dispositivo. Las estaciones pueden operar en diferentes modos de transferencia. Vamos a limitar nuestro análisis a una sola dispositivos que está conectado directamente a la máquina y que es capaz de continuamente el envío completo de paquetes a través de una aguas arriba de un extremo masiva en el modo de Alta Velocidad.
El encuadre
USB de alta velocidad de comunicación que se sincroniza en un marco fijo de la estructura. Cada fotograma es de 125 nosotros mucho tiempo y comienza con una Start-Of-Frame de paquetes (SOF) y está limitada por y Final De la secuencia de Fotogramas (EF). Cada paquete comienza con SYNC y termina con y Final-De-Paquete (EF). Las secuencias se han añadido a los diagramas para mayor claridad. EOP es variable en tamaño y paquetes de datos dependientes, para SOF es siempre de 5 bytes.
Abrir imagen en una pestaña nueva para ver una versión más grande.
Las transacciones
USB es un maestro impulsado por el protocolo y que cada transacción es iniciado por el host. El intervalo de tiempo entre el SOF y EF pueden ser utilizados para USB transacciones. Sin embargo, el tiempo para la SOF y EF es muy estricta y el host inicia sólo las transacciones que puede ser completado dentro de los intervalo de tiempo.
La transacción que nos interesa es un éxito a granel EN la transacción. La transacción se inicia con un tocken paquete, a continuación, los anfitriones espera para un paquete de datos DATA0/DATA1 y confirma la transmisión con un apretón de manos paquete ACK. La EOP para todos estos paquetes es de 1 a 8 bits dependiendo de los paquetes de datos, hemos asumido el peor de los casos aquí.
Entre cada uno de estos tres paquetes tenemos que considerar los tiempos de espera. Esas son entre el último bit del paquete de la acogida y el primer bit de la DATA0 paquete del dispositivo, y entre el último bit de la DATA0 de paquetes y el primer bit del paquete ACK. No tenemos que considerar cualquier otra retrasos como el anfitrión puede empezar a enviar el siguiente EN la derecha después de que el envío de un ACK. El cable de tiempo de transmisión se define como una máxima de 18 ns.
Una transferencia masiva puede enviar hasta 512 bytes por EN la transacción. Y el anfitrión va a tratar de como muchos de transacción posible entre el bastidor delimitadores. Aunque transferencia masiva tiene una baja prioridad puede tomar todo el tiempo disponible en una ranura cuando no hay ninguna otra transacción pendiente.
Para garantizar la correcta recuperación del reloj de los estándares que define a una llamada de método de bits de relleno. Cuando el paquete requeriría una larga secuencia de la misma salida de un adicional de flanco, se añade. Que asegura un flanco después de un máximo de 6 bits. En el peor de los casos, esto podría aumentar el tamaño total del paquete por 7/6. La EOP no está sujeto a poco el relleno.
Abrir imagen en una pestaña nueva para ver una versión más grande.
Los Cálculos De Ancho De Banda
Un bulto EN la transacción 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 7487 bytes de ancho. Sin la necesidad de bits de relleno que hay espacio para la 13.968 paquetes. Tener 8000 Micro-Fotogramas por segundo que puede leer los datos con 13 * 512 * 8000 B/s = 53.248 MB/s
Para totalmente aleatoria, se espera que los bits de relleno es necesario en uno de 2**6 = 64 secuencias de 6 bits consecutivos. Eso es un aumento de (63 * 6 + 7) / (64 * 6). Multiplicando todos los bytes que están sujetas a poco el relleno por que los números da un total de transacciones de la longitud de (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537.38 Bytes. Que se traduce en 13.932 paquetes por Micro-Marco.
Hay otro caso especial que faltan de estos cálculos. El estándar define un máximo de dispositivos tiempo de respuesta de 192 bits veces [2, Capítulo 7.1.19.2]. Este tiene que ser considerado a la hora de decidir si el último paquete aún se ajusta a la estructura en caso de que el dispositivo requiere todo el tiempo de respuesta. Nos podría dar cuenta de que mediante el uso de una ventana de 7439 bytes. El ancho de banda resultante a pesar de que es idéntico.
Lo que queda
La detección de errores y la recuperación no ha sido cubierta. Tal vez el error son suficientemente frecuentes o el error de la recuperación es mucho tiempo lo suficiente como para tener un impacto en el rendimiento promedio.
Hemos asumido instante host y el dispositivo de reacción después de paquetes y la transacción. Yo personalmente no veo ninguna necesidad de las grandes tareas de procesamiento en la final de los paquetes o las transacciones en cualquiera de los lados y por lo tanto yo no puedo pensar en ninguna razón por la que el host o dispositivo no debe ser capaz de responder al instante con suficientemente optimizado implementaciones de hardware. Especialmente en el normal funcionamiento de la mayoría de los libros de contabilidad y detección de error en el trabajo podría realizarse durante la operación y la siguiente paquetes de transacciones y podría estar en la cola.
Transferencias de otros parámetros adicionales o la comunicación no ha sido considerado. Tal vez el protocolo estándar para dispositivos de almacenamiento requiere de algunos continua lado del canal de comunicación que consume valiosos de la ranura de tiempo.
Puede ser que exista un protocolo adicional a la sobrecarga de los dispositivos de almacenamiento para el controlador de dispositivo o sistema de archivo de capa. (carga útil del paquete == almacenamiento de datos?)
Pregunta
¿Por qué son hoy las implementaciones no es capaz de transmitir a los 53 MB/s?
Dónde está el cuello de botella en el día de hoy implementaciones?
Y un posible seguimiento: ¿por Qué nadie ha intentado eliminar un cuello de botella?
