Jump to content

    

У правление потоком 100Base Full Duplex.

Допустим есть стандартный дешёвый фронтенд Ethernet 100Base Full Duplex. Выдаёт он по четырёхбитной шине с частотой 25 Мгц 100 мегабит, а я передать столько не могу. Можно ли как нибудь сказать трансиверу на другом конце Ethernet кабеля чтоб он заткнулся, через MII интерфейс этого фронтенда? Вообще как свичи простые стомегабитные поток уменьшают когда не могут его передать. Ведь это регулирование должно на низком уровне быть ещё до всяких там IP протоколов. Есть метод collision based backpressure для Ethernet 10BASE-T кторый NeoN использовал в своём устройстве. Но можно ли так делать в Ethernet 100Base Full Duplex(там же вроде коллизий нету?), и можно ли с помощью дешёвого фронтенда с обычным MII интерфейсом, и как?

Share this post


Link to post
Share on other sites

по моему такие проблемы решаются на более высоком уровне - на TCP. Ведь передача пакетов идёт с подтверждением - пока подтверждение на n -ный пакет не получено, n+ M -ный не отправится. Поставить в настройках M =1 и должно всё получиться.

Если я ошибаюсь - поправьте плиз.

Share this post


Link to post
Share on other sites

Для регулирования потока при full-duplex используется протокол IEEE 802.3x,

который состоит в обмене кадрами с адресом получателя 01-80-C2-00-00-01 и кодом протокола 00-01. После кода протокола следует двух-октетное количество

"квантов" запрашиваемой паузы или 0 для отмены требования паузы. Получатель такого пакета должен приостановать передачу на затребованное время. Короче, читайте стандарт. Протокол чем-то напоминает XON/XOFF в RS-232 ;)

 

P.S. Мож мне сам стандарт 802.3 на ftp выложить? Надо кому?

Share this post


Link to post
Share on other sites
по моему такие проблемы решаются на более высоком уровне - на TCP. Ведь передача пакетов идёт с подтверждением - пока подтверждение на n -ный пакет не получено, n+ M -ный не отправится. Поставить в настройках M =1 и должно всё получиться.

Если я ошибаюсь - поправьте плиз.

Это должно решаться и на более низком уровне. Для сети Ethernet вообще всёравно что в её пакет вкладывается. Например несколько машин подключённых к свичу могут на полной скорости захотеть заливать UDP пакеты соответственно вложенные в Ethernet кадры, и никто их не остановит в протоколе более высокого уровня. А свич не может например по внутренней шине прередать столько. У поминался выше метод collision based backpressure для Ethernet 10BASE-T, там приёмник постоянно генерит коллизии если не может передать пакет дальше, а передатчик соответственно снова через случайный интервал времени пытается передать пакет, таким образом скорости выравниваются, потерь не происходит. Информация о коллизии через сетевые карты, драйвера дойдут до протокола UDP и он притормозится.

Share this post


Link to post
Share on other sites
Для регулирования потока при full-duplex используется протокол IEEE 802.3x,

который состоит в обмене кадрами с адресом получателя 01-80-C2-00-00-01 и кодом протокола 00-01. После кода протокола следует двух-октетное количество

"квантов" запрашиваемой паузы или 0 для отмены требования паузы. Получатель такого пакета должен приостановать передачу на затребованное время. Короче, читайте стандарт. Протокол чем-то напоминает XON/XOFF в RS-232  ;)

 

P.S. Мож мне сам стандарт 802.3 на ftp выложить? Надо кому?

 

А у свича ведь должен быть мак адрес чтобы пакеты он мог отправлять?

Доступа нету к ftp :(

Share this post


Link to post
Share on other sites
Информация о коллизии через сетевые карты, драйвера дойдут до протокола UDP и он притормозится.

Кстати, фиг Вам ;) Если сетевому уровню не удалось передать пакет после 15 коллизий, последний отбрасывается. Вобщем, набери в линухе

ping -f -s6000 x.x.x.x - очень хорошая иллюстрация ;)

Чем, собственно, велик и могуч TCP - он позволяет поддерживать максимальный поток через сеть ориентируясь по задержке передачи пакетов, т.е. если выключить управление потоком в ethernet вообще - десяток TCP-соединений будут работать на таком канале не приводя к его перегрузке и потере пакетов. А вот большее кол-во + UDP + LCP + broadcast = и вот уже требуется управление потоком на уровне сети, и здесь ethernet крайне ущербен.

 

А у свича ведь должен быть мак адрес чтобы пакеты он мог отправлять?

Доступа нету к ftp :(

А зачем? В качестве SA можно писать все что угодно, на работу протокола это не влияет...

Share this post


Link to post
Share on other sites

В фулл дуплекс если такие пакеты отправлять с требованиями пыузы ущербность пропадает? Или потерь не избежать если TCP не используется? А как сохранить совместимость с не фулл дуплекс? Как коллизии генерить? Или этот хитрый пакет с паузами любой древний Ethernet понимает?

Share this post


Link to post
Share on other sites
В фулл дуплекс если такие пакеты отправлять с требованиями пыузы ущербность пропадает? Или потерь не избежать если TCP не используется? А как сохранить совместимость с не фулл дуплекс? Как коллизии генерить? Или этот хитрый пакет с паузами любой древний Ethernet понимает?

1. Если все сделано на FD и flow-control реально работает, то проблема останется только с "Buffer overflow" в ОС. Насколько я знаю, пока эта проблема не решена.

Ну а потерь в UDP не избежать полюбому - "сосед варит электродом" еще никто не отменял ;)

 

2. Трудно. Если нужно универсальный интерфейс, прийдется реализовывать и 802.3х, и CBB. Переключатся между ними, в зависимости от того, как установилось соединение. Да плюс еще не все оборудование понимает/генерирует соответствующих бит в FLP.

 

3. Коллизия возникает при встречной передаче данных при полудуплексе - т.е. чтобы "отбить" входящий пакет - посылай навстречу преамбулу и жди завершения входящего. Ну... грубо. Точнее - опять же в стандарте.

 

4. Не понимает. Да и новый не всегда. Особенно проблемно с сетевыми карточками писюков - да же если драйвер нормально обрабатывает 802.3х, бит в FLP чаще всего не поднимается, след. switсh думает что flow-control нет и не использует его...

Share this post


Link to post
Share on other sites

2 NeoN - а положите 802.3, может, кто когда почитает. Глядишь, и появится в xUSSR свой Nortel или 3COM :)

Share this post


Link to post
Share on other sites
Залил в /upload/DOC/Standards/IEEE Standards/802.3-2000.rar

 

спасибо -вы телепат просто

только хотел попросить об этом :)

Share this post


Link to post
Share on other sites
В фулл дуплекс если такие пакеты отправлять с требованиями пыузы ущербность пропадает? Или потерь не избежать если TCP не используется? А как сохранить совместимость с не фулл дуплекс? Как коллизии генерить? Или этот хитрый пакет с паузами любой древний Ethernet понимает?

1. Если все сделано на FD и flow-control реально работает, то проблема останется только с "Buffer overflow" в ОС. Насколько я знаю, пока эта проблема не решена.

Ну а потерь в UDP не избежать полюбому - "сосед варит электродом" еще никто не отменял ;)

 

2. Трудно. Если нужно универсальный интерфейс, прийдется реализовывать и 802.3х, и CBB. Переключатся между ними, в зависимости от того, как установилось соединение. Да плюс еще не все оборудование понимает/генерирует соответствующих бит в FLP.

 

3. Коллизия возникает при встречной передаче данных при полудуплексе - т.е. чтобы "отбить" входящий пакет - посылай навстречу преамбулу и жди завершения входящего. Ну... грубо. Точнее - опять же в стандарте.

 

4. Не понимает. Да и новый не всегда. Особенно проблемно с сетевыми карточками писюков - да же если драйвер нормально обрабатывает 802.3х, бит в FLP чаще всего не поднимается, след. switсh думает что flow-control нет и не использует его...

 

Спасибо. Очень помогли.

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