Motivasi

Dengan kecepatan pensinyalan 480 MBit / s, perangkat USB 2.0 harus dapat mentransmisikan data hingga 60 MB / s. Namun perangkat saat ini tampaknya terbatas pada 30-42 MB / s saat membaca [ Wiki: USB ]. Itu adalah overhead 30 persen.

USB 2.0 telah menjadi standar de facto untuk perangkat eksternal selama lebih dari 10 tahun. Salah satu aplikasi terpenting untuk antarmuka USB sejak awal adalah penyimpanan portabel. Sayangnya USB 2.0 dengan cepat menjadi penghambat kecepatan untuk aplikasi bandwidth yang menuntut ini, HDD saat ini misalnya mampu lebih dari 90 MB / s dalam pembacaan berurutan. Mempertimbangkan kehadiran pasar yang panjang dan kebutuhan konstan untuk bandwidth yang lebih tinggi kita harus berharap bahwa sistem eco USB 2.0 telah dioptimalkan selama bertahun-tahun dan mencapai kinerja baca yang dekat dengan batas teoritis.

Apa bandwidth maksimum teoretis dalam kasus kami? Setiap protokol memiliki overhead termasuk USB dan menurut standar resmi USB 2.0 adalah 53.248 MB / s [ 2 , Tabel 5-10]. Itu berarti secara teoritis perangkat USB 2.0 saat ini bisa 25 persen lebih cepat.

Analisis

Untuk mendekati akar masalah ini, analisis berikut akan menunjukkan apa yang terjadi di bus saat membaca data berurutan dari perangkat penyimpanan. Protokol ini dipecah lapis demi lapis dan kami sangat tertarik pada pertanyaan mengapa 53.248 MB / s adalah angka teoritis maksimum untuk perangkat hulu massal. Akhirnya kita akan berbicara tentang batasan analisis yang mungkin memberi kita beberapa petunjuk tambahan biaya tambahan.

Catatan

Sepanjang pertanyaan ini hanya awalan desimal yang digunakan.

Host USB 2.0 mampu menangani beberapa perangkat (melalui hub) dan beberapa titik akhir per perangkat. Titik akhir dapat beroperasi dalam berbagai mode transfer. Kami akan membatasi analisis kami untuk satu perangkat yang secara langsung dilampirkan ke host dan yang mampu mengirimkan paket penuh secara terus menerus melalui titik akhir curah hulu dalam mode Kecepatan Tinggi.

Pembingkaian

Komunikasi kecepatan tinggi USB disinkronkan dalam struktur bingkai tetap. Setiap frame panjangnya 125 us dan dimulai dengan paket Start-Of-Frame (SOF) dan dibatasi oleh dan urutan End-Of-Frame (EOF). Setiap paket dimulai dengan SYNC dan diakhiri dengan dan End-Of-Packet (EOF). Urutan-urutan itu telah ditambahkan ke diagram untuk kejelasan. EOP adalah variabel dalam ukuran dan paket data tergantung, untuk SOF selalu 5 byte.

Buka gambar di tab baru untuk melihat versi yang lebih besar.

Transaksi

USB adalah protokol berbasis master dan setiap transaksi dimulai oleh tuan rumah. Slot waktu antara SOF dan EOF dapat digunakan untuk transaksi USB. Namun penetapan waktu untuk SOF dan EOF sangat ketat dan tuan rumah hanya melakukan transaksi yang dapat diselesaikan sepenuhnya dalam slot waktu bebas.

Transaksi yang kami minati adalah transaksi massal IN yang berhasil. Transaksi dimulai dengan paket tocken IN, kemudian host menunggu paket data DATA0 / DATA1 dan mengonfirmasi transmisi dengan paket ACK handshake. EOP untuk semua paket ini adalah 1 hingga 8 bit tergantung pada paket data, kami mengasumsikan kasus terburuk di sini.

Di antara masing-masing dari ketiga paket ini kita harus mempertimbangkan waktu tunggu. Yaitu antara bit terakhir paket IN dari host dan bit pertama paket DATA0 perangkat dan antara bit terakhir paket DATA0 dan bit pertama paket ACK. Kami tidak perlu mempertimbangkan penundaan lebih lanjut karena tuan rumah dapat mulai mengirim IN berikutnya setelah mengirim ACK. Waktu transmisi kabel didefinisikan maksimum 18 ns.

Transfer massal dapat mengirim hingga 512 byte per transaksi IN. Dan tuan rumah akan mencoba untuk mengeluarkan transaksi sebanyak mungkin di antara pembatas frame. Meskipun transfer massal memiliki prioritas rendah, itu dapat mengambil semua waktu yang tersedia di slot ketika tidak ada transaksi lain yang tertunda.

Untuk memastikan pemulihan jam yang tepat, standar mendefinisikan isian bit panggilan metode. Ketika paket akan membutuhkan urutan yang sangat panjang dari output yang sama, sebuah sisi tambahan ditambahkan. Itu memastikan sisi setelah maksimal 6 bit. Dalam kasus terburuk ini akan meningkatkan ukuran paket total 7/6. EOP tidak dikenakan bit stuffing.

Buka gambar di tab baru untuk melihat versi yang lebih besar.

Perhitungan Bandwidth

Transaksi massal IN memiliki overhead 24 byte dan payload 512 byte. Itu total 536 byte. Slot waktu antara lebarnya 7487 bytes. Tanpa perlu sedikit isian ada ruang untuk paket 13.968. Memiliki 8000 Mikro-Frame per detik kita dapat membaca data dengan 13 * 512 * 8000 B / s = 53,248 MB / s

Untuk data yang benar-benar acak kami berharap bahwa bit stuffing diperlukan dalam salah satu dari 2 ** 6 = 64 urutan 6 bit berturut-turut. Itu peningkatan (63 * 6 + 7) / (64 * 6). Mengalikan semua byte yang terkena bit stuffing dengan angka-angka tersebut memberikan total transaksi total (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 Bytes. Yang menghasilkan 13.932 paket per Micro-Frame.

Ada kasus khusus lain yang hilang dari perhitungan ini. Standar ini menetapkan waktu respons perangkat maksimum 192 bit kali [ 2 , Bab 7.1.19.2]. Ini harus dipertimbangkan ketika memutuskan apakah paket terakhir masih sesuai dengan bingkai jika perangkat memerlukan waktu respons penuh. Kita dapat menjelaskannya dengan menggunakan jendela 7439 byte. Bandwidth yang dihasilkan meskipun identik.

Apa yang tersisa

• Pendeteksian dan pemulihan kesalahan belum tercakup. Mungkin kesalahan cukup sering atau pemulihan kesalahan cukup memakan waktu untuk berdampak pada kinerja rata-rata.

• Kami telah mengasumsikan reaksi host dan perangkat instan setelah paket dan transaksi. Saya pribadi tidak melihat adanya kebutuhan tugas pemrosesan besar pada akhir paket atau transaksi di kedua sisi dan oleh karena itu saya tidak dapat memikirkan alasan mengapa tuan rumah atau perangkat tidak dapat merespons secara instan dengan implementasi perangkat keras yang dioptimalkan secara memadai. Khususnya dalam operasi normal, sebagian besar pekerjaan pembukuan dan deteksi kesalahan dapat dilakukan selama transaksi dan paket-paket dan transaksi berikutnya dapat diantrikan.

• Transfer untuk titik akhir lain atau komunikasi tambahan belum dipertimbangkan. Mungkin protokol standar untuk perangkat penyimpanan memerlukan beberapa komunikasi saluran sisi kontinu yang menghabiskan waktu slot yang berharga.

• Mungkin ada overhead protokol tambahan untuk perangkat penyimpanan untuk driver perangkat atau lapisan sistem file. (paket payload == data penyimpanan?)

Pertanyaan

• Mengapa implementasi saat ini tidak mampu streaming pada 53 MB / s?

• Di mana hambatan dalam implementasi hari ini?

Dan tindak lanjut potensial: Mengapa tidak ada yang mencoba menghilangkan hambatan seperti itu?

Referensi

[1] Spesifikasi USB 2.0 resmi

[2] Cermin pdf cepat dari spesifikasi

Pada titik tertentu dalam hidup saya, saya dulu menjalankan bisnis USB untuk perusahaan semi besar. Hasil terbaik yang saya ingat adalah NEC SATA controller yang mampu mendorong throughput data aktual 320Mbps untuk penyimpanan massal, mungkin drive sata saat ini mampu melakukan ini atau sedikit lebih. Ini menggunakan BOT (beberapa protokol penyimpanan massal berjalan pada USB).

Saya dapat memberikan jawaban rinci teknis tetapi saya kira Anda dapat menyimpulkan sendiri. Yang perlu Anda lihat adalah bahwa ini adalah permainan ekosistem, setiap peningkatan signifikan akan membutuhkan seseorang seperti Microsoft untuk mengubah tumpukan mereka, mengoptimalkan dll, yang tidak akan terjadi. Interoperabilitas jauh lebih penting daripada kecepatan. Karena tumpukan yang ada dengan hati-hati menutupi kesalahan membunuh perangkat di luar sana karena ketika spesifikasi USB2 keluar mungkin perangkat awal tidak benar-benar mengkonfirmasi dengan spesifikasi yang baik karena spek itu kereta, sistem sertifikasi kereta dll. Dll. Jika Anda membangun sistem pembuatan rumah menggunakan Linux atau driver host USB khusus untuk MS dan pengontrol perangkat cepat, Anda mungkin dapat mendekati batas teoritis.

Dalam hal streaming, ISO seharusnya sangat cepat tetapi pengontrol tidak mengimplementasikannya dengan sangat baik, karena 95% aplikasi menggunakan transfer Massal.

Sebagai wawasan bonus, misalnya, jika Anda pergi dan membangun IC hub hari ini, jika Anda mengikuti spesifikasi ke titik, Anda praktis akan menjual nol chip. Jika Anda tahu semua bug di pasar dan memastikan IC hub Anda bisa mentolerir mereka, Anda mungkin bisa masuk ke pasar. Saya masih kagum hari ini, seberapa baik USB bekerja mengingat sejumlah perangkat lunak dan chip yang buruk di luar sana.

Ini adalah topik yang sangat lama, tetapi belum ada jawaban. Ini adalah usaha saya:

Mengapa implementasi saat ini tidak mampu streaming pada 53 MB / s?

Perhitungannya hampir baik, tetapi Anda lupa beberapa hal dalam jumlah byte yang tersedia di antara penanda bingkai:

1. Setiap mikroframe memiliki dua ambang yang disebut EOF1 dan EOF2. Tidak boleh ada aktivitas bus pada / setelah EOF1. Penempatan titik ini adalah hal yang rumit, tetapi posisi tipikal adalah 560 bit sebelum SOF berikutnya. Tuan rumah harus menjadwalkan transaksinya sedemikian rupa sehingga kemungkinan respons dari saluran tidak akan mencapai ambang ini. Yang memakan sekitar 70 byte dari 7474 byte yang dihitung.

2. Anda menganggap "data acak". Ini sama sekali tidak berdasar, data bisa apa saja. Oleh karena itu host harus menjadwalkan transaksi untuk payload kasus terburuk, dengan overhead pengisian bit maksimum, 512 * 7/6 = ~ 600 byte. Ditambah 24 byte overhead transaksi, saat Anda menghitung dengan benar. Ini memberikan (7487-70) / 624 = 11,88 transaksi per mikro-frame.

3. Host diharuskan untuk mencadangkan sekitar 10% dari bandwidth untuk mengontrol transaksi untuk aktivitas lain, jadi kami mendapatkan sekitar 10,7 transaksi.

4. Pengontrol host juga memiliki latensi tertentu saat mengelola daftar tertautnya, sehingga ada kesenjangan tambahan antara transaksi.

5. Perangkat bisa 5 hub / hop jauh dari root, dan penundaan respons bisa hingga 1700 ns, yang memakan 106 byte lagi dari setiap anggaran transaksi. Dalam perkiraan mentah, itu hanya membuat 10,16 transaksi per uFrame, tidak termasuk bandwidth yang disediakan.

Tuan rumah tidak dapat melakukan penjadwalan ulang adaptif berdasarkan kedatangan transaksi aktual dalam uFrame, itu akan menjadi penghalang dari perspektif perangkat lunak, sehingga pengemudi menggunakan jadwal paling konservatif, hingga 9 transaksi massal per uFrame, yang berjumlah 36 Mbytes / kedua. Inilah yang dapat dilakukan oleh pen drive USB yang sangat bagus.

Beberapa tolok ukur buatan yang gila dapat mencapai hingga 11 transaksi per uFrame, yang membuatnya menjadi 44 MBps. Dan ini adalah maksimum mutlak untuk protokol USB HS.

Di mana hambatan dalam implementasi hari ini?

Seperti yang dapat dilihat di atas, tidak ada botleneck, semua ruang bit-time mentah dimakan oleh overhead protokol.