Jump to content
Калькуляторы

Нагрузка на канал Ethernet

Доброго времени суток!

Мне тут сказали, что в Ethernet нагрузка на канал не должна превышать 30% от производительности канала, мол требуется это для защиты от коллизии или ещё чего-то. Но я нигде не могу найти доказательств этого. Может кто-нибудь рассказать, или кинуть ссылку, где об этом написано.

И вопрос ещё такой: если тогда нагрузка на канал составляет где-то 60% от общей производителности канала, то что произойдет?

Спасибо!

Share this post


Link to post
Share on other sites

Эзернет это L2, коллизии они ближе к L1, соотвественно там и нужно искать коллизии.

То что вам сказали, вероятно, относится к старым сетям на коаксиале или / и хабах. В современных сетях используются коммутаторы, и коллизий там нет потому что соединения точка-точка и каждая сторона передаёт по своим парам (медь) / на своей частоте (оптика).

А ещё эзернет может бегать в оптике, в xDSL будучи завёрнут в ATM, да хоть в IP/UDP его можно завернуть.

 

За вайфай не скажу.

 

PS: когда коллизии есть на старом хабе загорались индикаторы коллизий, а сетевые адаптеры затыкались на случайный промежуток времени и перепосылали. Но я те времена не застал - ничё не понимал :)

Share this post


Link to post
Share on other sites

Но я нигде не могу найти доказательств этого.

 

(потряхивает сединой) Когда-то, давным давно, когда свичи стоили сотни денег... слова "CSMA/CD" не были пустым звуком, и отдавались стремительным домкратом в сердце сетевиков. Только вот канули в лету те времена, слава богу. Ныне домен коллизий = в пределах одного порта на свиче, подобных ограничений нет.

 

P.S. Ради интереса погуглил "ethernet 30% нагрузка" -- тут же вылезла пачка результатов, в каждой из которых описано, почему так надо было.

Share this post


Link to post
Share on other sites

Geum-ja

Это глупости про 30%

 

У современных свитчей могут быть маленькие буферы, что приводит к output drop'ам и такое можно легко поймать и на 15% средней(!) загрузки

 

Универсальный рецепт примерно такой: низкоприоритеный сервис пусть дропается по буферу, а более ценные сервисы запихивают в другую очередь, в которой минизируем egress drops. Ну или покупается оборудование с жирными буферами, где дропается по минимуму

Share this post


Link to post
Share on other sites

У современных свитчей могут быть маленькие буферы, что приводит к output drop'ам и такое можно легко поймать и на 15% средней(!) загрузки

 

Ну раз уж мы тут про ужасы. Можно в свиче и переполнение mac-таблиц словить, с превращением его в хаб, с соответствующим эффектом. Там наверняка всплывут обратно эти 30% :)

Но тут надо причину лечить (хреновые свичи), а не симптомы (количество трафика, который этот недосвич броадкастит).

Share this post


Link to post
Share on other sites

Спасибо Вам огромное!!!

 

Получается, если нагрузка на канал составляет 800мбит/с, то с пропускной способностью канала в 1гбит/с кадры не потеряются? (Свич также не теряет пакеты).

 

И ещё скажите пожалуйста, вот когда, если нагрузка в 1100мбит/с, а пропускная способность канала 1гбит/с, то как трафик потеряться?

Share this post


Link to post
Share on other sites

Если Вы провайдер, то при отвале любого из аплинков Вы должны жить без дропов. И аплинков минимум два. Так что прикидывайте...

 

А в отдельных сегментах, да, можно и 10% запаса оставлять. Но ответственные магистрали имеет смысл тоже резервировать...

Share this post


Link to post
Share on other sites

Если Вы провайдер, то при отвале любого из аплинков Вы должны жить без дропов. И аплинков минимум два. Так что прикидывайте...

 

А в отдельных сегментах, да, можно и 10% запаса оставлять. Но ответственные магистрали имеет смысл тоже резервировать...

 

Скорее студент. Вопрос теоретический про древний Ethernet с коллизиями. А вы с какими то заумными вещами про аплинки лезете...

 

Тр фик по еря тся пр мер о так.

Отличный пример;)

Share this post


Link to post
Share on other sites

Ну раз уж мы тут про ужасы. Можно в свиче и переполнение mac-таблиц словить, с превращением его в хаб, с соответствующим эффектом. Там наверняка всплывут обратно эти 30% :)

чепуйхня

Share this post


Link to post
Share on other sites

Ну раз уж мы тут про ужасы. Можно в свиче и переполнение mac-таблиц словить, с превращением его в хаб, с соответствующим эффектом. Там наверняка всплывут обратно эти 30% :)

 

чепуйхня

 

Чой-та "чепуйхня"? Я механику процесса плохо понимаю? Положим, если 4 хоста, воткнуты они в 100-мегабитный свич, каждый с каждым обменивается 33 Мбит/сек трафика, т.е. даёт ~100 Мбит/сек исходящего на три хоста и ~100 Мбит/сек входящего от трёх других хостов получает. Т.о. утилизирует 100-FD. Потом свич ломается и начинает броадкастить. Ёмкости каналов на каждый хост не хватит, так что недосвич начинает дропать пакеты. Поскольку он в норме был загружен на 100-FD по всем портам, а теперь он ещё и мультиплицирует входящий трафик в три раза, вопрос: на сколько нужно понизить трафик от "канальной скорости" интерфейса, чтобы вся эта хрень шевелилась без дропов?

Share this post


Link to post
Share on other sites

Может и не начнёт, зависит от настроек флоуконтрол у участников процесса.

Share this post


Link to post
Share on other sites

то, что свич работает в full duplex, и даже 1 к 1000000 переподписка не приведет к коллизиям. а переполнение мак таблицы не делает из него хаб, он остается свичем с переполненой мак таблицей.

и если разговор про 30% емкости на хабе, то имеется ввиду сумма всего входящего трафика по всем портам, а в случае свича сотка и остается соткой

Share this post


Link to post
Share on other sites

а переполнение мак таблицы не делает из него хаб, он остается свичем с переполненой мак таблицей.

 

Ну хорошо, хорошо, это не будет хаб в L2-смысле, и домен коллизий не увеличится, но ёмкость сети упадёт в таком же разрезе.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this