Чи додає мостик затримку?


10

Якщо я використовую міст для здійснення нюху трафіку, як людина посередині, чи додасть міст затримку? І яке слово я повинен використовувати затримку чи затримку?


Якщо ви хочете нульової затримки, скористайтеся краном - сигнал електрично (або оптично) відтворюється, тож ви точно бачите, що було надіслано (помилки та все) [зауважте: вони дорогі, незважаючи на логіку, що коштує 5 доларів усередині них]
Рікі Бім

Відповіді:


12

Привіт і ласкаво просимо до мережевої інженерії.

Щодо "затримки" проти "затримки": Терміни не завжди використовуються послідовно. Деякі підказки можна знайти тут .

Я думаю, що загалом термін затримки використовується при перегляді часу в кінці часу для одного напрямку, які по суті складаються з суми всіх затримок розповсюдження, серіалізації, буферизації (і, можливо, обробки), введених різними компонентами на шляху від джерела до місця призначення (і назад, якщо хочеться поговорити про час поїздки в зворотному напрямку (RTT)). Тож ви можете сказати, що міст додає деяку затримку до загальної затримки.

(Наступний розділ відредагований після корисного коментаря) Міст, порівняно з прямим кабелем, додасть принаймні раз затримку серіалізації даного мережевого середовища (сторони виходу мосту) після його обробки, щоб відправити біти кадру знову на стороні виходу. Звичайно, додається одна кількість затримки серіалізації в одному напрямку , і оскільки для більшості випадків використання потрібні (принаймні деякі) дані для течії в будь-якому напрямку, міст з часом додасть затримку серіалізації вдвічі.

Також дивіться це запитання та wiki.geant.org для таблиці про затримки серіалізації).

Затримки серіалізації для різних медіа - https://wiki.geant.org/display/public/EK/SerializationDelay

У вашому випадку деякі додаткові затримки буферизації та обробки відбудуться через "людину в середині". Те, наскільки це буде, залежить повністю від оброблюваної здатності даного мостового програмного забезпечення на даній платформі, а також різних функцій та модулів, яким піддається кадр.


1
Хіба я не пив мою каву, тому, можливо, не думав прямо, але чи додавання мосту обов'язково додасть два рази затримку серіалізації? Очевидно, це завжди додаватиме одну затримку серіалізації (якщо не відбувається якесь прорізування), але серіалізація «відправлення» відбувається паралельно з десеріалізацією чергового приймача (що завжди все одно відбуватиметься), так що це не так це лише одна додаткова затримка загалом? Вибачте, якщо це не дуже зрозуміло ...
psmears

1
@psmears Затримка серіалізації, коли міст надсилає кадр у далекому кінці, у будь-якому випадку відбудеться, погоджено. Що стосується приймаючої сторони ... Давайте уявимо інакше ідентичний "прямий" кабель в обхід моста, куди однакова бітова послідовність передається синхронно, але в обхід моста. У кабелі біти просто поширюються вниз по лінії, поки міст чекає останнього біта, щоб почати обробку ... О. ви праві, спасибі! Тоді час для редагування.
Marc 'netztier' Luethi

Затримка серіалізації відбувається на швидкості проводів, тому це не велика затримка. Більшість сучасних корпоративних комутаторів будуть перемикатися на швидкості проводів, тому будь-яка затримка дуже-дуже мала, ймовірно, викликана перевантаженнями та чергами на інтерфейсі, що перераховується.
Рон

8

Так, міст / перемикач додає певну затримку до кадру - у порядку від 1 до 20 мкс.

Для комутаторів зазвичай говорять про затримку - затримку між отриманням кадру та переадресацією його на інший порт. Для перемикання потрібен певний час, щоб отримати адресу призначення та прийняти рішення про переадресацію. Перемикачі зберігання та перемоги (загальний вид) повинні отримувати весь кадр, перш ніж починати переходити. Високошвидкісні вимикачі можуть бути нижче 1 мкс. Редагувати : як правильно вказав @kasperd, прорізання можливе лише з портами джерела та пунктом призначення з однаковою швидкістю або зі зменшенням рівня.


3
Варто зауважити, що розріз досягає оптимальної продуктивності лише тоді, коли вхідні та вихідні посилання працюють на одному бітрейті. І може бути, що жоден постачальник навіть не покладався на реалізацію прорізування для змішаних бітрейт сценаріїв.
kasperd

2
@Kasperd Cisco для своєї серії Nexus 3000 заявляє про "прорізання" для однакових швидкостей та сценаріїв зменшення швидкості (40G -> 1 / 10G), але не для швидких кроків (1 / 10G -> 40g). cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/…
Marc 'netztier' Luethi

@kasperd & Marc'netztier'Luethi - Абсолютно, THX. Вирізання з посиленням неможливо, оскільки у вас швидко не вистачає даних (якщо ви зараз не встановите довжину кадру, якої у вас немає).
Zac67

@ Zac67 Довжина відома на деяких кадрах, але не на всіх кадрах. (І після того, як прочитав, як це працює, я, на жаль,
переживаю
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.