Ambang RTS, fragmentasi, dan pengaturan WiFi lanjutan lainnya


19

Latar Belakang: Saya berada di lingkungan yang bising, dan saya mencoba mengoptimalkan jaringan WiFi saya untuk memiliki koneksi yang lebih stabil untuk volume pengguna yang agak tinggi (~ 50-75 pada hari yang sibuk). Ada 4 AP, dan saya sudah menyesuaikan saluran dan daya pancar, dan secara keseluruhan saya memiliki jangkauan yang cukup baik. Namun, saya masih mendapatkan sekitar ~ 10% paket drop ketika melakukan ping Google dan berjalan di sekitar gedung, roaming dari AP ke AP.

Di sebagian besar WiFi AP yang pernah saya lihat, RTS Threshold default ditetapkan pada 2347 (dari apa yang saya baca di berbagai tempat, pengaturan ini dianggap sebagai "dinonaktifkan"), dan Ambang Batas Fragmentasi ditetapkan pada 2346. Merek router khusus saya diatur pada 2346 dan 2346. Saya punya beberapa pertanyaan ...

  1. Dari mana nilai 2346 berasal? Tampaknya agak sewenang-wenang, bagaimanapun, catatan untuk Frag. Ambang batas menunjukkan bahwa itu harus lebih dari 256 dan nomor genap.

  2. Bagaimana RTS dan Frag. Ambang terkait? Nilai-nilai mereka tidak bisa kebetulan.

  3. Jika dimodifikasi, haruskah mereka diubah bersama?

  4. Apa nilai aman untuk mencoba menurunkannya, sebagai permulaan?

Prioritas saya tidak selalu mendapatkan bandwidth puncak untuk setiap perangkat, tetapi memberikan pengguna bandwidth / koneksi yang stabil dan konsisten.


1
Apakah Anda menjalankan jaringan b / g campuran? Jika demikian, itu dapat menyebabkan banyak masalah.
Greg Askew

Yup, dan tidak ada cara untuk menonaktifkan B atau menetapkan kecepatan data minimum pada perangkat ini.
Bigbio2002

Jawaban:


15
  1. 2346 adalah ukuran bingkai 802.11 maksimum . Mengatur RTS dan ambang batas fragmentasi ke maksimum berarti bahwa tidak ada paket yang memenuhi ambang batas.

  2. Ambang fragmentasi membatasi ukuran bingkai maksimum. Ini mengurangi waktu yang diperlukan untuk mengirimkan frame, dan karena itu mengurangi kemungkinan bahwa itu akan rusak (dengan biaya lebih banyak data overhead). Ambang RTS menentukan ukuran bingkai di mana pemancar harus menggunakan protokol RTS / CTS , yang sebagian besar untuk menyelesaikan masalah simpul tersembunyi . Ini jelas juga menambah overhead.

  3. Belum tentu - jika Anda tidak memiliki masalah simpul tersembunyi maka mengubah ambang RTS tidak akan meningkatkan kinerja. Agar RTS / CTS menendang ambang RTS harus sama atau lebih kecil dari ambang fragmentasi.

  4. Saya akan mulai dengan mengatur mereka sedemikian rupa sehingga frame Ethernet standar terfragmentasi menjadi dua frame 802.11 (1500/2 = 750 byte payload + 34 byte overhead = 784 byte) dan setiap frame lebih besar dari sepertiga dari frame Ethernet standar menggunakan RTS (534 byte).

Sejauh yang saya tahu, kedua pengaturan ini hanya memengaruhi pemancar, yaitu mengonfigurasikannya pada AP hanya membuat AP menggunakannya untuk transmisinya dan tidak membuat klien menggunakannya untuk transmisi mereka.


2

Skenario b / g campuran itu sangat suboptimal. Anda mungkin ingin meninjau beberapa diskusi sebelumnya tentang topik tersebut, seperti:

Klien nirkabel paling lambat menentukan kualitas koneksi semua orang lain?

Juga, pembunuh kinerja lain terjadi ketika titik A dapat menerima sinyal titik B, tetapi B tidak dapat menerima sinyal A. Orang lain di ServerFault menunjukkan ini sebagai "efek pemancar tersembunyi". Lebih lanjut tentang fenomena itu di tautan di bawah ini. Mereka menunjukkan bahwa:

"... Sementara polarisasi horizontal diinginkan, kurangnya antena omni-directional komersial murah terpolarisasi horizontal mungkin memerlukan penggunaan antena terpolarisasi vertikal. Antena yang dipolarisasi vertikal omni-directional yang baik akan menelan biaya hampir sama dengan antena parabola. Penggunaan antena omni-directional membantu meminimalkan efek "transmitter tersembunyi". "

http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules


0

Saya tidak setuju bahwa "jika Anda tidak memiliki masalah simpul tersembunyi maka mengubah ambang RTS tidak akan meningkatkan kinerja." Menggunakan CTR / RTS selalu menurunkan kemungkinan tabrakan data. Karena setiap tabrakan data menyebabkan korupsi data dan karenanya membutuhkan data untuk dikirim kembali, lebih sedikit tabrakan berarti lebih sedikit pengiriman ulang data dan lebih sedikit pengiriman ulang data yang sebagian besar dapat meningkatkan kinerja WiFi Anda; tentu saja hanya jika ada banyak tabrakan di jaringan Anda.

Untuk menjelaskan detailnya: Suatu node selalu harus menunggu selama periode waktu tertentu dan merasakan saluran untuk kemungkinan transmisi sebelum menyatakannya sendiri. Hanya jika tidak merasakan transmisi, ia dapat memulai transmisi sendiri. Tanpa RTS / CTS, transmisi ini secara langsung merupakan transmisi data. Jika sekarang dua node keduanya memiliki ide yang sama dan memulai transmisi data hampir pada saat yang sama, maka transmisi ini akan bertabrakan. Hasilnya adalah, bahwa tidak ada transmisi yang membuatnya di mana pun karena semua data yang diterima akan rusak untuk semua node lain dan AP.

Jika RTS / CTS digunakan, transmisi dimulai dengan paket RTS yang dikirim oleh node setelah penginderaan. Hanya jika permintaan RTS dijawab oleh balasan CTS, transmisi data dimulai. Tentu saja, jika dua node ingin mentransmisikan secara bersamaan, permintaan RTS mereka juga dapat bertabrakan dengan efek negatif yang sama sehingga tidak ada RTS yang diterima sama sekali. Perbedaannya adalah, seluruh jaringan akan pulih lebih cepat dari tabrakan RTS daripada dari tabrakan data. Jadi tabrakan RTS kurang berbahaya bagi seluruh kinerja jaringan daripada tabrakan data.

Kelemahannya adalah bahwa RTS / CTS sendiri membutuhkan beberapa bandwidth jaringan sendiri dan memperkenalkan waktu penginderaan baru selama tidak ada transmisi data lain atau transmisi RTS / CTS yang terjadi. Untuk membuat segalanya lebih buruk, tentu saja RTS / CTS harus selalu dilakukan menggunakan kecepatan paling lambat yang didukung jaringan karena jika tidak, node yang hanya mendukung kecepatan ini tidak akan melihatnya. Jadi pada dasarnya Anda dapat mengatakan bahwa RTS / CTS selalu menurunkan throughput teoritis seluruh jaringan Anda, namun jika jaringan Anda menderita banyak tabrakan, baik oleh masalah simpul tersembunyi (yang juga dapat disebabkan oleh node dari jaringan lain hanya menggunakan yang sama saluran sebagai jaringan Anda) atau karena WiFi Anda penuh sesak (karena lebih banyak node meningkatkan peluang untuk tabrakan acak), itu sebenarnya dapat meningkatkan throughput aktual. Bukan jumlah node tersembunyi,

Saya membaca sebuah penelitian (saya akan memperbarui dan menambahkan tautan di sini setelah saya dapat menemukannya lagi), yang menunjukkan bahwa kecuali jaringan Anda benar-benar kecil (kurang dari 6 node dan hanya mencakup area kecil) dan tidak terisolasi dari yang lain jaringan yang menggunakan saluran yang sama, menggunakan RTS / CTS hampir selalu memiliki efek yang agak positif dalam praktiknya. Jadi mengapa nilai ambang? Jika mengirim data akan memakan waktu sebanyak yang dibutuhkan oleh jabat tangan RTS / CTS, ada sedikit keuntungan menggunakan RTS / CTS, karena apakah jaringan harus pulih dari tumbukan data yang sangat kecil atau dari tumbukan RTS tidak akan menghasilkan banyak perbedaan. Pemulihan yang lebih baik dari dari tabrakan RTS adalah karena paket RTS sangat kecil sedangkan paket data biasanya tidak. Tetapi untuk paket data yang sangat kecil, RTS / CTS hanya menambahkan overhead tanpa keuntungan praktis.

Dan sekarang Anda juga tahu bagaimana ambang fragmentasi dapat meningkatkan kinerja jaringan. Di satu sisi itu membatasi ukuran paket yang dikirim dan seperti yang dijelaskan di atas, semakin kecil paket dalam sebuah tabrakan, semakin cepat jaringan akan pulih dari itu. Dan di sisi lain, jika ada tabrakan, hanya fragmen yang terpengaruh perlu dikirim ulang, bukan seluruh paket. Namun, setiap fragmen yang dikirim memiliki overhead sendiri, sehingga semakin banyak fragmen yang dikirim, semakin banyak overhead yang akan ditambahkan dan overhead pada dasarnya adalah bandwidth yang terbuang yang bisa juga digunakan untuk transmisi data.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.