Motywacja

Dzięki szybkości sygnalizacji wynoszącej 480 MBit / s urządzenia USB 2.0 powinny być w stanie przesyłać dane z prędkością do 60 MB / s. Jednak dzisiejsze urządzenia wydają się być ograniczone do 30-42 MB / s podczas czytania [ Wiki: USB ]. To 30% narzutu.

USB 2.0 jest de facto standardem dla urządzeń zewnętrznych od ponad 10 lat. Jedną z najważniejszych aplikacji interfejsu USB od samego początku była przenośna pamięć masowa. Niestety, USB 2.0 szybko stał się wąskim gardłem ograniczającym prędkość w tych wymagających aplikacjach wymagających przepustowości, dzisiejszy dysk twardy jest na przykład zdolny do ponad 90 MB / s podczas sekwencyjnego odczytu. Biorąc pod uwagę długą obecność na rynku i stałą potrzebę większej przepustowości, należy spodziewać się, że system eco 2.0 USB 2.0 został zoptymalizowany na przestrzeni lat i osiągnął wydajność odczytu zbliżoną do granicy teoretycznej.

Jaka jest teoretyczna maksymalna przepustowość w naszym przypadku? Każdy protokół ma narzut, w tym USB i zgodnie z oficjalnym standardem USB 2.0 wynosi 53.248 MB / s [ 2 , Tabela 5-10]. Oznacza to, że teoretycznie dzisiejsze urządzenia USB 2.0 mogą być o 25 procent szybsze.

Analiza

Aby zbliżyć się do źródła tego problemu, poniższa analiza pokaże, co dzieje się w magistrali podczas odczytu danych sekwencyjnych z urządzenia pamięci masowej. Protokół jest podzielony warstwa po warstwie, a szczególnie interesuje nas pytanie, dlaczego 53,248 MB / s jest maksymalną liczbą teoretyczną dla masowych urządzeń nadrzędnych. Na koniec porozmawiamy o granicach analizy, które mogą dać nam pewne wskazówki dotyczące dodatkowych kosztów ogólnych.

Notatki

W tym pytaniu używane są tylko dziesiętne prefiksy.

Host USB 2.0 może obsługiwać wiele urządzeń (za pośrednictwem koncentratorów) i wiele punktów końcowych na urządzenie. Punkty końcowe mogą działać w różnych trybach przesyłania. Ograniczymy naszą analizę do pojedynczego urządzenia, które jest bezpośrednio podłączone do hosta i które jest zdolne do ciągłego wysyłania pełnych pakietów przez główny punkt końcowy w trybie szybkim.

Ramy

Szybka komunikacja USB jest zsynchronizowana w stałej strukturze ramki. Każda ramka ma długość 125 us i zaczyna się od pakietu początku ramki (SOF) i jest ograniczona sekwencją końca ramki (EOF). Każdy pakiet zaczyna się od SYNC i kończy się na oraz End-Of-Packet (EOF). Sekwencje te zostały dodane do diagramów dla jasności. EOP ma zmienny rozmiar i zależy od danych pakietowych, dla SOF jest to zawsze 5 bajtów.

Otwórz obraz w nowej karcie, aby zobaczyć większą wersję.

Transakcje

USB jest protokołem głównym i każda transakcja jest inicjowana przez host. Szczelina czasowa między SOF i EOF może być wykorzystana do transakcji USB. Jednak czas dla SOF i EOF jest bardzo ścisły, a host inicjuje tylko transakcje, które można w pełni zrealizować w wolnym czasie.

Transakcja, która nas interesuje, jest udaną transakcją zbiorczą IN. Transakcja rozpoczyna się od pakietu Tocken IN, następnie hosty czekają na pakiet danych DATA0 / DATA1 i potwierdzają transmisję za pomocą pakietu uzgadniania ACK. EOP dla wszystkich tych pakietów wynosi od 1 do 8 bitów, w zależności od danych pakietu, w tym przypadku przyjęliśmy najgorszy przypadek.

Pomiędzy każdym z tych trzech pakietów musimy wziąć pod uwagę czasy oczekiwania. Znajdują się one między ostatnim bitem pakietu IN hosta a pierwszym bitem pakietu DATA0 urządzenia oraz między ostatnim bitem pakietu DATA0 a pierwszym bitem pakietu ACK. Nie musimy brać pod uwagę żadnych dalszych opóźnień, ponieważ host może rozpocząć wysyłanie następnego IN bezpośrednio po wysłaniu ACK. Czas transmisji kabla określono na maksymalnie 18 ns.

Przesyłanie zbiorcze może wysłać do 512 bajtów na transakcję IN. A host spróbuje wydać jak najwięcej transakcji między ogranicznikami ramki. Chociaż przesyłanie zbiorcze ma niski priorytet, może zająć cały dostępny czas w gnieździe, gdy nie ma żadnych innych oczekujących transakcji.

Aby zapewnić prawidłowe odzyskiwanie zegara, standardy definiują upychanie bitów wywołania metody. Gdy pakiet będzie wymagał bardzo długiej sekwencji tego samego wyjścia, dodawana jest dodatkowa flanka. To zapewnia bok po maksymalnie 6 bitach. W najgorszym przypadku zwiększyłoby to całkowity rozmiar pakietu o 7/6. EOP nie podlega upychaniu bitów.

Otwórz obraz w nowej karcie, aby zobaczyć większą wersję.

Obliczenia przepustowości

Masowa transakcja IN ma narzut 24 bajtów i ładunek 512 bajtów. To w sumie 536 bajtów. Szczelina czasowa między ma szerokość 7487 bajtów. Bez potrzeby wypychania bitów jest miejsce na 13,968 pakietów. Mając 8000 mikro-ramek na sekundę możemy odczytać dane z 13 * 512 * 8000 B / s = 53,248 MB / s

W przypadku całkowicie losowych danych oczekujemy, że wypychanie bitów jest konieczne w jednym z 2 ** 6 = 64 sekwencji po 6 kolejnych bitów. To wzrost o (63 * 6 + 7) / (64 * 6). Pomnożenie wszystkich bajtów podlegających upychaniu bitów przez te liczby daje całkowitą długość transakcji (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 bajtów. Co daje 13,932 pakietów na Micro-Frame.

W tych obliczeniach brakuje jeszcze jednego specjalnego przypadku. Norma określa maksymalny czas reakcji urządzenia na 192 bity [ 2 , rozdział 7.1.19.2]. Należy wziąć to pod uwagę przy podejmowaniu decyzji, czy ostatni pakiet nadal mieści się w ramce na wypadek, gdyby urządzenie potrzebowało pełnego czasu reakcji. Możemy to wyjaśnić, używając okna o długości 7439 bajtów. Wynikowa przepustowość jest jednak identyczna.

Co zostało

• Wykrywanie błędów i odzyskiwanie nie zostało uwzględnione. Być może błędy występują wystarczająco często lub ich odzyskiwanie zajmuje wystarczająco dużo czasu, aby mieć wpływ na średnią wydajność.

• Przyjęliśmy natychmiastową reakcję hosta i urządzenia po pakietach i transakcji. Osobiście nie widzę potrzeby dużych zadań przetwarzania na końcu pakietów ani transakcji po żadnej stronie, dlatego nie mogę wymyślić żadnego powodu, dla którego host lub urządzenie nie byłoby w stanie natychmiast zareagować przy wystarczająco zoptymalizowanych implementacjach sprzętowych. Zwłaszcza podczas normalnej pracy większość prac związanych z prowadzeniem ksiąg rachunkowych i wykrywaniem błędów można wykonać podczas transakcji, a kolejne pakiety i transakcje mogą zostać umieszczone w kolejce.

• Transfery dla innych punktów końcowych lub dodatkowa komunikacja nie zostały uwzględnione. Być może standardowy protokół dla urządzeń pamięci masowej wymaga ciągłej komunikacji w kanale bocznym, która pochłania cenny czas w gnieździe.

• Może istnieć dodatkowy narzut protokołu dla urządzeń pamięci masowej dla sterownika urządzenia lub warstwy systemu plików. (ładunek pakietu == dane do przechowywania?)

Pytanie

• Dlaczego dzisiejsze implementacje nie są w stanie przesyłać strumieniowo z prędkością 53 MB / s?

• Gdzie jest wąskie gardło w dzisiejszych wdrożeniach?

I potencjalne działania następcze: dlaczego nikt nie próbował wyeliminować takiego wąskiego gardła?

Bibliografia

[1] Oficjalna specyfikacja USB 2.0

[2] Szybkie lustro pdf specyfikacji

W pewnym momencie mojego życia prowadziłem firmę USB dla dużej firmy. Najlepszy wynik, jaki pamiętam, to kontroler NEC SATA zdolny do zwiększenia faktycznej przepustowości 320 Mb / s dla pamięci masowej, prawdopodobnie obecne dyski sata są w stanie to osiągnąć lub nieco więcej. Używano BOT (niektóre protokoły pamięci masowej działają na USB).

Mogę udzielić szczegółowej odpowiedzi technicznej, ale myślę, że możesz wydedukować siebie. To, co musisz zobaczyć, to gra ekosystemowa, każda znacząca poprawa wymagałaby od kogoś takiego jak Microsoft zmiany stosu, optymalizacji itp., Co nie nastąpi. Interoperacyjność jest znacznie ważniejsza niż prędkość. Ponieważ istniejące stosy ostrożnie pokrywają błędy związane z mnóstwem urządzeń, ponieważ kiedy pojawiła się specyfikacja USB2, prawdopodobnie początkowe urządzenia nie potwierdziły specyfikacji tak dobrze, ponieważ specyfikacja była wadliwa, system certyfikacji był wadliwy itp. Itd. Jeśli zbudujesz domowy system zaparzania przy użyciu Linuxa lub niestandardowych sterowników hosta USB dla MS i szybkiego kontrolera urządzenia, prawdopodobnie zbliżysz się do teoretycznych limitów.

Jeśli chodzi o przesyłanie strumieniowe, ISO powinno być bardzo szybkie, ale kontrolery nie wdrażają tego zbyt dobrze, ponieważ 95% aplikacji korzysta z przesyłania zbiorczego.

Aby uzyskać dodatkowe informacje, na przykład, jeśli dzisiaj zbudujesz hub IC, postępując zgodnie ze specyfikacją do kropki, praktycznie sprzedasz zero żetonów. Jeśli znasz wszystkie błędy na rynku i upewniasz się, że Twój hub IC może je tolerować, prawdopodobnie możesz wejść na rynek. Nadal jestem dzisiaj zaskoczony, jak dobrze USB działa, biorąc pod uwagę liczbę złych programów i układów.

To bardzo stary temat, ale nie ma jeszcze odpowiedzi. To jest moja próba:

Dlaczego dzisiejsze implementacje nie są w stanie przesyłać strumieniowo z prędkością 53 MB / s?

Obliczenia są prawie prawidłowe, ale zapominasz o kilku rzeczach w dostępnej liczbie bajtów między znacznikami ramki:

1. Każda mikroframa ma dwa progi zwane EOF1 i EOF2. Aktywność magistrali nie może wystąpić w / po EOF1. Umieszczenie tego punktu jest skomplikowane, ale typowa pozycja to 560 bitów przed następnym SOF. Host musi zaplanować swoje transakcje w taki sposób, aby żadna możliwa odpowiedź z kanału nie osiągnęła tego progu. Który zjada około 70 bajtów z obliczonych 7487 bajtów.

2. Zakładasz „losowe dane”. Jest to całkowicie bezzasadne, dane mogą być dowolne. Dlatego host musi zaplanować transakcje dla najgorszego ładunku, przy maksymalnym napełnieniu bitów 512 * 7/6 = ~ 600 bajtów. Plus 24 bajty narzutu transakcyjnego, jak słusznie obliczyłeś. Daje to (7487-70) / 624 = 11,88 transakcji na mikroramkę.

3. Host musi zarezerwować około 10% przepustowości dla transakcji kontrolnych dla każdej innej działalności, więc otrzymujemy około 10,7 transakcji.

4. Kontroler hosta ma również pewne opóźnienia w zarządzaniu połączoną listą, więc istnieje dodatkowa luka między transakcjami.

5. Urządzenie może znajdować się w odległości 5 węzłów / przeskoków daleko od katalogu głównego, a opóźnienie odpowiedzi może wynosić do 1700 ns, co zjada kolejne 106 bajtów z każdego budżetu transakcji. W przybliżeniu dokonuje tylko 10,16 transakcji na ramkę uFrame, nie licząc zarezerwowanej przepustowości.

Host nie może wykonać adaptacyjnego ponownego planowania w oparciu o faktyczne przybycie transakcji w ramce uFr, byłoby to zabronione z punktu widzenia oprogramowania, więc sterownik stosuje najbardziej konserwatywny harmonogram, do 9 transakcji masowych na ramkę uFrame, co stanowi 36 Mb / s druga. To może zapewnić bardzo dobry pendrive USB.

Niektóre szalone sztuczne testy porównawcze mogą przejść do 11 transakcji na ramkę uFrame, co czyni ją 44 MBps. Jest to absolutne maksimum dla protokołu HS USB.

Gdzie jest wąskie gardło w dzisiejszych wdrożeniach?

Jak widać powyżej, nie ma botleneck, cała surowa przestrzeń bit-time jest zjadana przez narzut protokołu.