Motivasyon

480 MBit / s sinyal hızında USB 2.0 cihazlarının 60 MB / sn'ye kadar veri iletebilmesi gerekir. Ancak bugünün cihazları [ Wiki: USB ] okurken 30-42 MB / s ile sınırlı gözüküyor . Bu yüzde 30 ek yük.

USB 2.0, 10 yıldan fazla bir süredir harici cihazlar için fiili bir standart olmuştur. USB arabirimi için ilk başlarda en önemli uygulamalardan biri taşınabilir depolama olmuştur. Maalesef USB 2.0 hızlı bir şekilde bu bant genişliği gerektiren uygulamalar için hız sınırlayıcı bir darboğaz oluşturuyordu; bugünün HDD'si, örneğin, sırasıyla 90 MB / sn'den fazla okuma yapabiliyor. Uzun pazar mevcudiyeti ve daha yüksek bant genişliğine olan sürekli ihtiyaç göz önüne alındığında, USB 2.0 eko sisteminin yıllar içinde optimize edilmesini ve teorik sınıra yakın bir okuma performansına ulaşmasını beklemeliyiz.

Olgumuzda teorik maksimum bant genişliği nedir? USB dahil her protokolün ek yükü vardır ve resmi USB 2.0 standardına göre 53.248 MB / s'dir [ 2 , Tablo 5-10]. Bu teorik olarak bugünün USB 2.0 cihazlarının yüzde 25 daha hızlı olabileceği anlamına geliyor .

analiz

Bu sorunun köküne yakın bir yere ulaşmak için, aşağıdaki analiz bir depolama cihazından sıralı verileri okurken veriyolunda neler olduğunu gösterecektir. Protokol katman katman katman ayrılır ve özellikle neden 53.248 MB / s toplu akış yukarı aygıtlar için maksimum teorik sayı olduğu sorusuyla ilgileniyoruz. Sonunda, analizin bize ek yükü hakkında bazı ipuçları verebilecek sınırları hakkında konuşacağız.

notlar

Bu soru boyunca sadece ondalık ön ekler kullanılır.

Bir USB 2.0 ana bilgisayarı, aygıt başına birden çok aygıtı (hub aracılığıyla) ve birden çok uç noktayı işleyebilir. Bitiş noktaları farklı transfer modlarında çalışabilir. Analizimizi doğrudan ana bilgisayara bağlı olan ve Yüksek Hızlı modda bir yukarı akış toplu uç noktası üzerinden sürekli olarak tam paketler gönderebilen tek bir cihazla sınırlayacağız.

çerçeveleme

USB yüksek hızlı iletişim, sabit bir çerçeve yapısında senkronize edilir. Her bir kare 125 usa uzunluğundadır ve bir Başlangıç ​​Çerçevesi paketi (SOF) ile başlar ve Sınır Sonu dizisi (EOF) ile sınırlandırılır. Her paket SYNC ile başlar ve Paket Sonu (EOF) ile biter. Bu diziler açıklık için diyagramlara eklenmiştir. EOP, boyut ve paket verilerine bağlı olarak değişkendir, SOF için her zaman 5 bayttır.

Daha büyük bir sürüm görmek için görüntüyü yeni bir sekmede açın.

işlemler

USB, ana yönlendirmeli bir protokoldür ve her işlem ana bilgisayar tarafından başlatılır. SOF ve EOF arasındaki zaman dilimi, USB işlemlerinde kullanılabilir. Bununla birlikte, SOF ve EOF için zamanlama çok katıdır ve ev sahibi sadece ücretsiz zaman dilimi içerisinde tamamen tamamlanabilecek işlemleri başlatır.

İlgilendiğimiz işlem, IN işleminde başarılı bir işlemdir. İşlem bir tocken paketi IN ile başlar, sonra ana bilgisayarlar DATA0 / DATA1 veri paketini bekler ve iletimi bir el sıkışma paketi ACK ile onaylar. Bütün bu paketler için EOP, paket verilerine bağlı olarak 1 - 8 bit arasında, burada en kötü durum olduğunu varsaydık.

Bu üç paketin arasında bekleme sürelerini göz önünde bulundurmalıyız. Bunlar, ana bilgisayardaki IN paketinin son biti ile cihazın DATA0 paketinin ilk biti arasında ve DATA0 paketinin son biti ile ACK paketinin ilk biti arasındadır. Bir ACK gönderdikten hemen sonra ana bilgisayar bir sonraki IN'i göndermeye başlayabileceğinden başka gecikmeler dikkate almamız gerekmez. Kablo iletim süresi maksimum 18 ns olarak tanımlanmıştır.

Bir toplu transfer, IN işlemi başına 512 bayta kadar gönderebilir. Ve ana bilgisayar, çerçeve sınırlayıcıları arasında mümkün olduğunca fazla işlem yapmaya çalışacaktır. Toplu aktarımın önceliği düşük olmasına rağmen, bekleyen başka bir işlem olmadığında, bir slotta mevcut tüm zamanı alabilir.

Saatin uygun şekilde kurtarılmasını sağlamak için standartlar bir yöntem çağrısı bit doldurmasını tanımlar. Paket, aynı çıktının çok uzun bir sekansını gerektirdiğinde, ilave bir yan kanat eklenir. Bu, maksimum 6 bitin ardından bir yan kanat sağlar. En kötü durumda, bu toplam paket büyüklüğünü 7/6 artıracaktır. ÇOP bit doldurmaya tabi değildir.

Daha büyük bir sürüm görmek için görüntüyü yeni bir sekmede açın.

Bant Genişliği Hesaplamaları

Bir toplu IN işlemi, 24 baytlık bir yük ve 512 baytlık bir yüke sahiptir. Bu toplam 536 bayt. Arasındaki zaman aralığı 7487 bayt genişliğindedir. Bit doldurma ihtiyacı olmadan 13.968 paket için alan var. Saniyede 8000 Mikro-Frame olan 13 * 512 * 8000 B / s = 53.248 MB / s ile verileri okuyabiliriz

Tamamen rastgele veriler için, art arda 6 bitin 2 ** 6 = 64 dizisinden birinde bit doldurmanın gerekli olmasını bekliyoruz. Bu bir artış (63 * 6 + 7) / (64 x 6). Bu sayılarla bit doldurmaya tabi olan tüm baytları çarpmak (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537.38 Bayt toplam işlem uzunluğunu verir. Mikro-Frame başına 13.932 pakette sonuçlanan.

Bu hesaplamalardan eksik olan başka bir özel durum var. Standart, 192 bitlik bir maksimum cihaz tepki süresini tanımlar [ 2 , Bölüm 7.1.19.2]. Cihazın tam tepki süresine ihtiyaç duyması durumunda son paketin çerçeveye hala uyup uymadığına karar verirken bu dikkate alınmalıdır. 7439 baytlık bir pencere kullanarak bunu yapabiliriz. Sonuçta ortaya çıkan bant genişliği aynıdır.

Ne kaldı

• Hata tespiti ve kurtarılması ele alınmamıştır. Belki de hata yeterince sık görülür veya hatanın kurtarılması, ortalama performans üzerinde etkili olacak kadar zaman alıcıdır.

• Paketler ve işlemlerden sonra anında host ve cihaz reaksiyonu üstlendik. Paketlerin ya da işlemlerin sonunda her iki tarafın da büyük işlem görevlerine ihtiyaç duymadığımı kişisel olarak görüyorum ve bu nedenle, ana bilgisayarın veya aygıtın yeterince optimize edilmiş donanım uygulamalarıyla anında yanıt verememesi için herhangi bir neden düşünemiyorum. Özellikle normal operasyonda, defter tutma ve hata tespit işlemlerinin çoğu işlem sırasında yapılabilir ve bir sonraki paketler ve işlem sıraya konulabilir.

• Diğer uç noktalar veya ek iletişim için yapılan transferler dikkate alınmamıştır. Belki de depolama cihazları için standart protokol, değerli slot zamanlarını tüketen bazı sürekli yan kanal iletişimi gerektirir.

• Aygıt sürücüsü veya dosya sistemi katmanı için depolama aygıtları için ek bir protokol ek olabilir. (paket yükü == depolama verisi?)

Soru

• Neden bugünün uygulamaları 53 MB / s hızında yayınlanamıyor?

• Bugünün uygulamalarında tıkanıklık nerede?

Ve potansiyel bir takip: Neden kimse böyle bir darboğazı ortadan kaldırmaya çalışmadı?

Referanslar

[1] Resmi USB 2.0 özelliği

[2] Hızlı pdf şartname ayna

Hayatımın bir noktasında, USB şirketini büyük yarı şirket için işletiyordum. Hatırladığım en iyi sonuç, toplu depolama için 320Mbps gerçek veri çıkışını zorlayabilen NEC SATA denetleyiciydi, muhtemelen güncel sata sürücüleri bunu ya da biraz daha fazlasını yapabilir. Bu BOT kullanıyordu (USB'de bazı toplu depolama protokolleri çalışıyor).

Teknik detaylı bir cevap verebilirim ama sanırım kendinizi çıkarabilirsiniz. Görmeniz gereken şey, bu ekosistem oyunudur, herhangi bir önemli gelişme Microsoft gibi birisinin yığınlarını değiştirmesini, optimize etmesini vb. Birlikte çalışabilirlik hızdan çok daha önemlidir. Var olan yığınlar, cihazların çevirme hatalarını dikkatle örttüğü için, çünkü USB2 özelliği ortaya çıktığında, muhtemelen ilk cihazlar, spesifikasyonun buggy olduğundan beri, belgelendirme sisteminin buggy vb. Olduğunu doğruladı. MS için Linux veya özel USB ana bilgisayar sürücüleri ve bir hızlı aygıt denetleyicisi kullanarak bir ev demleme sistemi kurarsanız, muhtemelen teorik sınırlara yaklaşabilirsiniz.

Akış açısından, ISO'nun çok hızlı olması gerekiyordu, ancak uygulamaların% 95'i Toplu aktarım kullandığından kontrolörler bunu çok iyi uygulamıyor.

Bonus bir bakış açısı olarak, örneğin, bugün bir hub IC'si kuruyorsanız, noktadaki belirtimi izlerseniz pratikte sıfır cips satarsınız. Piyasadaki tüm hataları biliyorsanız ve hub IC'nizin bunlara tahammül edebileceğinden eminseniz, muhtemelen pazara girebilirsiniz. Bugün hala şaşırdım, USB'nin ne kadar iyi çalıştığı ve kötü amaçlı yazılımlar verildiği için ne kadar iyi çalıştığı.

Bu çok eski bir konudur, ancak henüz bir cevabı yoktur. Bu benim girişimim:

Neden bugünün uygulamaları 53 MB / s hızında yayınlanamıyor?

Hesaplamalar neredeyse iyi, ancak çerçeve işaretleyicileri arasındaki kullanılabilir bayt sayısında birkaç şeyi unutuyorsunuz:

1. Her mikro çerçevenin, EOF1 ve EOF2 olarak adlandırılan iki eşiği vardır. EOF1'de / sonrasında veri yolu etkinliği olmamalıdır. Bu noktanın yerleştirilmesi karmaşık bir şeydir, ancak tipik konum bir sonraki SOF'den 560 bit öncedir. Bir ev sahibi, işlemlerini kanaldan gelebilecek herhangi bir cevabın bu eşiğe çarpmayacağı şekilde planlamalıdır. Hesaplanan 7487 bayttan yaklaşık 70 bayt yer.

2. "Rasgele veri" olduğunu varsayıyorsunuz. Bu tamamen temelsiz, veriler herhangi bir şey olabilir. Bu nedenle, ana bilgisayar en kötü durum yükü için işlemleri planlamalı, maksimum bit doldurma ek yükü, 512 * 7/6 = ~ 600 bayt. Artı doğru olarak hesapladığınız gibi işlem yükü 24 bayt. Bu işlem, mikro çerçeve başına (7487-70) / 624 = 11.88 işlem verir.

3. Ev sahibi, diğer herhangi bir faaliyet için kontrol işlemleri için bant genişliklerinin yaklaşık% 10'unu ayırması gerekir, bu nedenle yaklaşık 10.7 işlem gerçekleştiririz.

4. Ana bilgisayar denetleyicisi ayrıca, bağlı listesini yönetirken belirli bir gecikme süresi vardır, bu nedenle işlemler arasında ek boşluk vardır.

5. Aygıt, kökten uzakta 5 hub / atlama noktası olabilir ve yanıt gecikmesi, her işlem bütçesinin 106 baytını yiyen 1700 ns'ye kadar çıkabilir. Ham tahminde, ayrılmış bant genişliği için sayılmaz, uFrame başına sadece 10.16 işlem yapar.

Ana bilgisayar, uFrame içindeki gerçek işlem varışına bağlı olarak uyarlamalı yeniden zamanlama yapamaz; yazılım perspektifinden yasaklayıcı olur, bu nedenle, sürücü en muhafazakar zamanlamayı kullanır; ikinci. Çok iyi bir USB kalem sürücünün sunabileceği şey budur.

Bazı çılgın yapay benchmarklar uFrame başına 11 işlem yapabilir ve bu da 44 MBps yapar. Ve bu HS USB protokolü için mutlak maksimumdur.

Bugünün uygulamalarında tıkanıklık nerede?

Yukarıda görülebileceği gibi, herhangi bir botleneck yoktur, tüm ham bit zaman alanı protokol ek yükü tarafından yenir.