Mengapa ethernet memiliki ukuran bingkai minimum yang ditentukan?


Jawaban:


16

Melakukan beberapa bacaan cepat, tampaknya itu terkait dengan bagian Deteksi Tabrakan CSMA / CD. Jika bingkai terlalu kecil pada media siaran lama, maka beberapa tabrakan tidak akan terdeteksi. Melanjutkan tema analogi mobil saya hari ini, untuk alasan yang sama kita tidak mengizinkan sepeda di jalan raya berkecepatan tinggi - tidak aman bagi mereka.


3
+1, saya tidak tahu tentang sepeda ...
Kyle Brandt

6
+1 Pendeteksian tabrakan adalah alasannya. 64 byte adalah 0,04ms pada kecepatan ethernet 10Mb. Setiap yang lebih kecil dan tabrakan akan tidak terdeteksi (pada 1982).
sysadmin1138

Jika saya memahami Anda, alasan untuk minimum 64 byte adalah untuk memberikan waktu yang cukup bagi stasiun lain untuk memperhatikannya?
CodyBugstein

1
Bisakah Anda jelaskan mengapa tabrakan tidak terdeteksi?
problemofficer

1
Saya yakin tabrakan sepeda di jalan raya berkecepatan tinggi akan terdeteksi. Lagi pula, sepeda diperbolehkan di Interstate di sebagian besar negara bagian AS bagian barat, jadi saya tidak yakin seberapa tepat analoginya. :)
Michael Hampton

4

Selain jawaban mfinni (benar-benar benar), pengaturan ukuran bingkai minimum memungkinkan Anda menghabiskan banyak siklus penerimaan untuk memverifikasi checksum frame Anda. Dalam Ye Olde Days, orang dapat dengan mudah membayangkan sebuah chip yang memproses satu bit per siklus, tetapi membutuhkan banyak siklus untuk menghitung sebuah checksum pada jalur khusus yang berjalan paralel dengan jalur penerimaan. Menerima banyak pesan singkat dapat mengakibatkan logika checksum ini menjadi kacau karena memiliki beberapa operasi simultan yang dipicu di dalamnya. Membuang apa pun di bawah ambang ukuran tertentu memungkinkan Anda menghindari masalah ini dengan cara sederhana.


Saya percaya jawaban ini salah; itu ada hubungannya dengan keterlambatan propagasi di media dan deteksi tabrakan.
Andrew Wagner

@AndrewWagner, Seperti yang sudah saya katakan dalam jawaban saya, jawaban mfinni di atas, yaitu tentang deteksi tabrakan, sudah benar. Maksud saya adalah bahwa "kekhasan" dari spesifikasi ini juga memungkinkan perancang perangkat keras untuk mengambil beberapa cara pintas mereka sendiri.
BMDan

2

Ethernet dirancang untuk bekerja melalui media bersama (eter!). Pengirim mampu merasakan ketika sinyal mereka mengemudi eter berbeda dari apa yang ada di eter.

Sayangnya semua media mengalami keterlambatan propagasi (sayangnya bahkan cahaya bergerak dengan kecepatan terbatas).

Misalkan Anda mengirim kerangka yang sangat singkat. Untuk mendeteksi apakah penerima mentransmisikan tepat pada saat yang sama ketika mereka menerima bingkai Anda, Anda harus menunggu sinyal yang mereka kirim untuk mencapai Anda, jadi karena itu Anda harus menunggu / mendengarkan dua kali keterlambatan propagasi media sebelum Anda tahu apakah ada tabrakan di ujung penerima

Sekarang, alih-alih hanya mendengarkan (mengirim diam) selama waktu itu, Anda sebaiknya meneruskan dan mengirim beberapa informasi yang berguna selama waktu itu.

Oleh karena itu standar menetapkan ukuran bingkai minimum menjadi jumlah data yang dapat Anda kirim dalam DUA KALI keterlambatan propagasi terburuk di media bersama.

Jadi, jika Anda tidak senang karena frame besar merasa "tidak dioptimalkan" untuk pesan kecil Anda, pikirkan ruang ekstra dalam paket sebagai peluang untuk menemukan sesuatu untuk dikirim, ketika Anda sebaliknya harus mengirim nol.

Tentu saja ada banyak cara lain untuk menangani tabrakan dan keterlambatan propagasi dalam standar jaringan lokal, tetapi kemudian itu tidak akan menjadi ethernet, dan saya pikir kita semua bisa sepakat bahwa ethernet cukup manis.


Pertanyaan: Jadi saya mengerti mengapa Anda membutuhkan minimum atau 2 x PDtetapi dari mana 64 byte berasal? Tidakkah itu tergantung pada panjang / jenis kabel? 64 byte tampaknya sewenang
CodyBugstein

Itu kembali ke efisiensi tradeoff VS kompleksitas lama. Anda dapat membangun beberapa sistem untuk secara otomatis mengukur jaringan dan memilih ukuran paket minimum yang sesuai tetapi akan menambah kompleksitas nontrivial untuk keuntungan yang relatif kecil.
Peter Green

0

Agar CSMA / CD berfungsi dengan benar, Anda ingin deteksi tabrakan yang konsisten.

Jika penerima melihat tabrakan dan pengirim tidak maka paket itu akan hilang. Demikian pula jika pengirim melihat tabrakan tetapi penerima tidak Anda akan mendapatkan paket duplikat setelah pengirim mengirim ulang. Tidak diinginkan.

Karena data bergerak dengan kecepatan terbatas, ukuran paket minimum diperlukan untuk memastikan bahwa jika terjadi tabrakan itu terjadi di mana-mana. Semakin besar Anda membuat ukuran paket minimum semakin besar dan / atau lebih cepat Anda dapat membuat jaringan sebelum CSMA / CD rusak.

Adapun mengapa 64-byte saya tidak tahu pasti tapi saya berharap itu hanya angka bulat yang "kelihatannya tepat pada saat itu", mengingat kecepatan mereka beroperasi, ukuran yang diharapkan dari jaringan Ethernet dan ukuran yang diharapkan paket tingkat yang lebih tinggi.


0

Panjang paket minimum 64 byte bukan angka yang arbitrer. Dalam lapisan fisik 10Base5 ("Fat Ethernet" coaxial, salah satu lapisan fisik yang ditentukan sebelumnya, yang memiliki kabel terpanjang diizinkan) itu menghasilkan panjang paket minimum, dalam mikrodetik, yang dua kali waktu perjalanan bolak-balik dari panjang maksimum kabel, yaitu 2.500 meter, terdiri dari lima segmen 500 meter dengan empat repeater. Ini untuk memastikan bahwa paket-paket yang ditransmisikan dari sisi berlawanan dari kabel bertabrakan sepenuhnya pada setiap titik kabel, untuk deteksi tabrakan yang dapat diandalkan di semua node.

Hal sepele:

  • Ini dua kali jumlah minimum untuk overhead keamanan
  • Deteksi tabrakan pada kabel koaksial dapat dilakukan oleh pembanding tegangan analog (karena paket bertabrakan menghasilkan dua kali tegangan sinyal normal)
  • Kecepatan listrik dalam kabel tembaga adalah sekitar 200000 kilometer per detik
  • Setiap bit dalam 10Base5 Ethernet memiliki panjang 20 meter pada kabel
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.