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

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

Для регулирования потока при full-duplex используется протокол IEEE 802.3x,
который состоит в обмене кадрами с адресом получателя 01-80-C2-00-00-01 и кодом протокола 00-01. После кода протокола следует двух-октетное количество
"квантов" запрашиваемой паузы или 0 для отмены требования паузы. Получатель такого пакета должен приостановать передачу на затребованное время. Короче, читайте стандарт. Протокол чем-то напоминает XON/XOFF в RS-232

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

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

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

Кстати, фиг Вам Если сетевому уровню не удалось передать пакет после 15 коллизий, последний отбрасывается. Вобщем, набери в линухе
ping -f -s6000 x.x.x.x - очень хорошая иллюстрация
Чем, собственно, велик и могуч TCP - он позволяет поддерживать максимальный поток через сеть ориентируясь по задержке передачи пакетов, т.е. если выключить управление потоком в ethernet вообще - десяток TCP-соединений будут работать на таком канале не приводя к его перегрузке и потере пакетов. А вот большее кол-во + UDP + LCP + broadcast = и вот уже требуется управление потоком на уровне сети, и здесь ethernet крайне ущербен.


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

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

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

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

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

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

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

Залил в /upload/DOC/Standards/IEEE Standards/802.3-2000.rar

спасибо -вы телепат просто
только хотел попросить об этом

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