Здравствуйте!
Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.
Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:
- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;
- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.
Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.
Хотел бы обменяться мнениями с теми, кто сталкивался с данной проблемой.
Спасибо.

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться. Но выше этого уровня есть транспортный, в частности, протокол TCP. Глубоко не вникал в его работу, но этот протокол должен по количеству недошедших пакетов подстраивать скорость передачи пакетов, чтобы они не терялись и не образовывались задержки, связанные с повторной передачей пакетов.
Я пока начинаю работать над похожей задачей и надеюсь, что так и будет, как я выше описал.
А все перечисленные вами ранее методы бесполезны: если в каналах разная скорость, это обязательно когда-то приведёт к невозможности доставить очередной пакет. Например, метод шлюза работает, пока не переполнится буфер. А потом всё равно пакеты потеряются.
Метод обратного давления приводит к бесполеному "торможению по цепочке". Вообще, коллизии имеют место только в полудуплексном режиме (я работаю с полным дуплексом на гигабитном изернете). В полном дуплексе есть механизм управления потоком, описываемый стандартом IEEE 802.3х (см. тему http://electronix.ru/forum/index.php?showtopic=15533 К стати, я с этим механизмом до конца так и не разобрался, так что был бы благодарен за помощь с русскоязычными текстами, поясняющими его). Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"

Почему же "никуда не деться" ?
Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 10..20 (наверное ).


К сожалению, протокол TCP контролирует целостность только одного сеанса связи между двумя процессами (потребителями). А через узкое горло может быть организовано ничем не ограниченное множество независимых сеансов TCP.
Да и вообще, речь идет о передаче не IP пакетов, а пакетов Ethernet, в которые могут инкапсулироваться множество различных протоколов. Поэтому без управления потоком на MAC уровне не обойтись.
Я тоже только подступаюсь к этой проблеме. Посколько разбираться со всеми нюансами нет времени, я решил взять микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.
Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

Лучше бы работать по методу квитирования пакетов, но этот режим устанавливает сервер, а не мой конвертор.
По этому напрашивается такая мысль - модифицировать метод "скользящего окна", тем что на определенном протокольном этапе перехватывать размер допускаемого к приему окна, «вручную» изменять в нем число разрешенных к передаче в окне кадров, например, с M до 1-го и далее передавать в направлении сервера. Таким образом, мы возвращаемся к квитированию.

Вобщем-то этим и занимается протокол TCP

Почему именно такая цифра? С потолка? Вы знаете, что если скорости не совпадают, то любой буфер переполнится, какой большой бы он ни был. Зачем такой здоровый буфер? Это же надо сколько памяти? Железка будет очень дорогой. Обычно руководствуются правилом, что в буфере должно укладываться 2 пакета: чтобы протоколы TCP успели договориться на приёмной и передающей сторонах
Да и к чему я это всё пишу:
Под переполнением я, разумеется, имел в виду заполнение до определённого порога, при котором посылается команда приостановки передачи. Но самое главное: вы представляете, что каждый раз при переполнении всё оборудование канального уровня от узкого места до источника пакетов будет подвержено распространению по цепочке кадра приостановки передачи, а после опустошения буфера - кадра возобновления передачи? Кому нужен весь этот бесполезный трафик, если гораздо проще поручить на передающем конце протоколу TCP подстроить оптимальную скорость посылки пакетов в сеть? И тогда весь механизм контроля потоков не пригодится.
А если ещё учесть, что на пути от источника пакетов до узкого горлышка возможно хоть один свич не поддерживает механизм контроля потоков? Тогда все старания этого механизма, весь паразитный трафик из кадров приостановки и возобновления передачи напрасны. Этот свич, не поддерживающий механизм контроля потока будет слать пакеты, и следующее по пути их распространения оборудование будет заполнять свой приёмный буфер. И он заполнится. Лишние пакеты всё равно начнут убиваться.
Пусть уж лучше протокол TCP возьмётся за эту работу.

Каждый проткол задаёт скорость своего соединения, скорость делится пропорционально. Так что в целом скорость как раз благодаря действию всех протоколов TCP должна установиться на грани пропускной способности узкого горлышка.

Если протоколы работают через ненадёжную среду, а это любая среда без подтверждения доставки пакетов - тот же протокол UDP, то эти протоколы должны быть готовы к потере пакетов, поэтому для таких протоколов потеря пакетов не нештатная ситуация, а вполне привычное явление.

У меня лично Gigabit Ethernet, там со свичами с малым количеством портов пока проблема... я делаю вообще свич на ПЛИС.

Махровый идеализм :-)))).

Тогда это вообще не Ваша "проблема".

Позволю себе не согласиться: идеальным выглядит решение с механизмом контроля потоков. И вот оно, как раз, и разбивается о суровую правду жизни, которую я описывал ранее. Что не все устройства это поддерживают, что гоняется лишний трафик и т.д. С моим мнением коррелируют утверждения авторов книги [Компьютерные сети: Принципы, технологии, протоколы: Учебник для вузов/ Виктор Григорьевич Олифер, Наталия Алексеевна Олифер. - СПб.: Питер, 2002. - 669[3] с.: ил. - (Учебник для вузов)], если не ошибаюсь.
А вот протокол TCP, как раз должен выполнять требуемые действия по подстройке скорости. Я детально в нём не разбирался, но определённые понятия имею.

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

Конретные реализации стеков конкретно на это и на обработку (только фиксация для статистики)
аппаратных ошибок любезно доставляемых Вашим switch плюют :-( Это я имел ввиду под
идеализмом :-(. Собственно этот бардак начался с распространения интернета, когда что-либо кто-либо перестал гарантировать, ну а на локальные сети "автоматически" распространилось :-(

Можете сделать бридж, у которого медленный интерфейс будет с более мелким mtu, ну и буфер поболе. Буду лепить похожую байду через месяц - и в мыслях нету так все усложнять - похерил пакет и делов-то.

дело вот в чём...
сам разговор об абстрактном Ethernet конечно же занимательная весчь, но мягко говоря бесполезная... При реализации стэка протоколов Вы будете реализовывать все нижележащие протоколы. Если идёт речь о TCP/IP то Вам придётся покопаться с MAC уровнем, с IP уровнем, протоколами ARP (скорее всего захотите поддержать), протокол ICMP (скорее всего захотите поддержать), рядом лежащий UDP...
Дык вот, если речь идёт об "узком" горлышке IP уровня, который может ДЕФРАГМЕНТИРОВАТЬ пакеты кде то там и у Вас должным образом должна производиться сборка - то тогда "первый удар" будет принимать именно он. Данный уровень не содержит механизма регулирования пропускной способности канала. И тут нужен кэш. И решение таких проблем как время жизни разрозненных пакетов при сборке. В принцепе, чтоб не быть голословным - вот ссылки, возможно кому нить они помогут...

русско язычная ссылка
ссылка на -гнездо- протоколов

с уважением
(круглый)

Спасибо за ответы и ссылки на документацию.
Есть мнение, что согласование высокой скорости Ethernet и медленной E1 (TDM,PCM30) достаточно сделать методом «обратного давления», создавая коллизии на аппаратном МАС-уровне. В этом случае, когда низкоскоростной канал все еще находится в режиме передачи предыдущего пакета, нужно на ранних этапах распознать поступление нового пакета Ethernet и, пока он продолжает поступать, сгенерировать свой встречный. Тогда встречное устройства на МАС-уровне распознает коллизию, прекратит передачу и попробует с некоторой задержкой ее повторить (что может выполняться несколько раз), и это в итоге даст нужную нам задержку, а значит и согласование скорости.
1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?
2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал?

Ошибочное. Подробности были в личном письме.

А не проще решить проблему применением готового моста? Видел реализацию на MB86976 (Fujitsu Ethernet Bridge Controller см. рисунок). У него с одной стороны подключается LIU Ethernet а с другой - WAN-interface. Еще правда к нему надо DRAM подцепить. Скорость в WAN-части - до 8 Мбит/с. Придется, конечно, повозится с "N*64" и синхронизацией в ИКМ-части, но зато проблема с "запихиванием слона в запорожец" решиться однозначно.

Нажмите для просмотра прикрепленного файла

Здесь говорилось о:

микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.


Вот кусок перевода даташита для KS8995, просто для справки:

Поддержка ограничения объема обмена информацией
KS8995MA поддерживает аппаратное ограничение объема обмена информацией, как на стороне приема, так и на стороне передачи независимо для каждого порта. Это также поддерживает ограничение объема обмена информацией для приоритетной или неприоритетной среды. Предел объема обмена информацией начинается от 0 Кб/сек и подходит к частоте работы линии с шагом в 32Кб/сек.
KS8995MA использует одну секунду как временной интервал для паузы. В начале каждого интервала, счетчик обнуляется, и механизм, определяющий объем обмена информацией начинает считать число байтов, переданных/полученных в течение этого интервала.
На стороне приема, если число принятых байтов превышает запрограммированный предел, то коммутатор прекратит получать пакеты для этого порта, пока интервал, длительностью в одну секунду не истечет. Есть опция, предусматривающая управление потоком данных, используемая для того, чтобы предотвратить потери пакетов. Если предел на ограничение объема обмена информацией запрограммирован на скорости большие или равные 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 8 КБ ниже уровня предела, то будет вызвано управление потоком данных. Если предел на ограничение объема обмена информацией запрограммирован на скорости ниже чем 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 2 КБ ниже предела, то в этом случае также будет вызвано управление потоком данных.
На стороне передачи, если число байтов превышает запрограммированный предел, коммутатор прекратит передавать пакеты через этот порт, пока интервал длительностью в одну секунду не истечет.
Если допускается обслуживание с приоритетами, то KS8995MA может поддержать различный уровень объема обмена информацией как для высоко-приоритетных и для низко-приоритетных пакетов. Такой режим обслуживания может быть запрограммирован в соответствующих регистрах управления режимами работы микросхемы.


Удачи!

Спасибо за информацию.
Удачное сравнение проблемы – «с запихиванием слона в запорожец».
Здесь у меня есть личный аспект – эта тема в работе, аппаратура изготовлена в малой партии, сейчас мною настраивается и нужно получить результат (сроки уже затянулись). Все ссылки на другие устройства очень интересны (думаю, всем и мне тоже), но принять я их сейчас не могу. Возможно, позже, так что вопрос о методе по прежнему актуален - надо закончить разработку. Вот такая ситуация.

Соболезнования :-(.

Привет Всем!!!
Заработали мои конверторы - это первая ласточка! Пишу это письмо через них. Скорость пока 4*64кбит/с, низковатая, как у черепахи, но по Интернету уже походил. Приятно то как
Подробности потом, вопросов и работы еще много...
Даже изменение прошло.

Вай, зачем в личное письмо? Напишите, пожалуйста, сюда. Ведь это всем может быть интересно и полезно!

В полнодуплексном режиме работает механизм контроля потоков http://electronix.ru/forum/index.php?showtopic=15533

Конвертор построен на CS8900A-CQ3, C8051F123 и XC9572XL. Его задача преобразовать полный или частичный поток Е1 в Ethernet (10Base-T) и обратно для передачи информации в SHDSL-трактах. Проблемы при выходе в Internet через сервер предприятия, похоже, уже нет, видимо, все неувязки решает TCP/IP. Результаты работы в полудуплексном режиме достаточно удовлетворительные. Проблемы остались при работе с подобными компьютерами в локальной сети через сетевое окружение, с ними просто нет связи (ни через Explorer, ни через Total Commander). Также были проблемы при организации видеоконференций. Видимо не хватает быстродействия и накопительного буфера со стороны Ethernet , а может там другие протоколы. Над эти сейчас тружусь, вооружившись Ethereal.
Информации по протоколам вроде бы много, но объять ее тяжело. А так как нет тематического руководства, то работа напоминает хождение по темному лабиринту без фонарика. Поэтому и вопросы.

256 kbit/s, даже с учетом возможного наличия дополнительного протокола при паковке в E1 это
для "хождения по интернету" не совсем то, что можно охарактеризовать "как черепаха", ибо
скорость доступа ко многим ресурсам сети на уровне 10-20Kbytes/s я вляется обыденным и _привычным_ делом :-(. Где-то у Вас 'черепаха' в другом месте покопаласть....

Схема организации связи такая: Я отключаю свой компьютер от локальной сети, и ставлю два конвертора, так, чтобы между собой они были связаны по Е1, а каналами Ethernet подключались один к сети, а другой к моему компьютеру. При использовании 4 канальных интервалов (КИ) - пиковая скорость 256 kbit/s, с большим числом КИ в Е1 я пока еще не успел поработать. Экспериментировал с DounLoadMaster, загружая с Интернета pdf-файлы размером по 1Мбайт (используя при этом 4 КИ). DounloadMaster показал здесь пиковую скорость 8кбайт/с (т.е. 64 kbit/s), и загружал этот файл за время около 4 мин (здесь сетевая скорость 10Мбит/с). Таким образом, средняя скорость была около 30 kbit/s, в восемь раз ниже пиковой для 4-х КИ. Конечно, были потери, так как при детальном просмотре через sniffer, были видны сообщения типа:"TCP Previous segment lost", "TCP Retransmission". Так что черепашка действительно еще где-то зарыта.
Для справки этот же файл загружался напрямую, через сеть за 4 сек (без моего конвертора, при скорости в сети 100Мбит/с и с пиковой скорость до 500кбайт/с ).
Вопросы остались: Почему не удается связаться через конверторы с соседними компьютерами локальной сети предприятия? На ping они отвечаю без проблем, а вот просмотреть содержимое с помощью Windows Commander – не удается (хотя без конверторов это получается). Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

Задержка - нет, а потери смертельны.

Я так понял что лишние пакеты Вы просто херите ?

TCP/IP специально предназначен для работы по каналам с возможными "узкими местами", где будт происходить отброс пакетов, превышающих лимит скорости. Поэтому через конверторы он у Вас и работает. Снижение скорости может происходит из-за наличия паразитного траффика в сети (broadcustы и прочее), который вполне может забить часть и так небольшой полосы.
Для Windowсовского NETBIOSа потери смертельны.

У нас есть Cronyxовский ковертер, который работает со скоростью 64 Кбит через SDH сеть на расстояние примерно 50 км. Соединены 2 компьютера с Linux, скорость 64 кбита достигается спокойно.

Помимо работы в Internet (на устойчивых к потерям протоколов TCP/IP), мои конверторы должны обеспечить связь двух удаленных компьютеров, или удаленного компьютера и сети (через DSL-тракт).
Здесь как я понимаю из Ваших ответов, при между-компьютерных обменах включаются уже другие протоколы, а именно Windows NETBIOS. Для них потери пакетов смертельны (в силу того, что нет механизма восстановления как у TCP/IP). В тоже время задержка в доставке пакетов не так страшна, как возможные их потери (может здесь решение!). Уменьшить загрузку конверторов можно, отсекая с помощью внутреннего адресного фильтра CS8900A посторонние пакеты (широковещательные и чужие).
Тогда возникают вопросы:
1. Возможна ли полноценная связь, если через конверторы, в направлении удаленного компьютера, пропускать только адресованные ему пакеты (по индивидуальному адресу на уровне Ethernet адресации с помощью адресного фильтра CS8900A)?
2. Как «подружится» с протоколами Windows NETBIOS, учитывая «заторможенность» конверторов и ограниченность буфера очереди для поступающих пакетов?

Broadcustы пропускать обязательно, иначе не будет ничего работать. Через них определяется соотвествие IP адреса физическому, а NETBIOS использует их местами и для передачи команд.

Соединить две сети с Windows компьютерами узким каналом, чтоюы сохранилась работоспособность вряд ли получиться. Уж больно много каждый компьютер broadcustoв рожает. Соединяйте через машины - маршрутизаторы (или через D-linkи дешевые), так чтобы соединение было точка-точка.

Windows можно настроить для работы полностью через TCP/IP, но я в этом не спец.

Да, тут Вы правы, надо включать "NetBIOS over TCP/IP", тогда всё должно работать надёжно. Но без броадкастов не получить полный список компьютеров в "сетевом окружении". Хотя даже без этого списка мы должны "заходить" на компьютер и "видеть" его "расшаренные" папки, выполнив "поиск компьютера" и введя его IP-адрес (только при включенном NetBIOS over TCP/IP)

В Netbios over TCP/IP есть возможность организовать name server на одной из машин, который позволяет работать NETBIOSу из разных IP сетей. Тогда не будут лезть broadcustы через узкий канал. Но как это все в Windows настраивается я понятия не имею.

Добрый день!
Работа по моему конвертору Ethernet-ИКМ(Е1 или TDM) подошла к концу. Поэтому благодарность всем за советы и подсказки. Прилагаю фото платы конвертора. Напомню, что максимальная скорость передачи через конвертор N*64кбит/с, где N=1..32 число задействованных тайм слотов потока Е1. Удалось достичь средней скорости 85% от максимума при связи двух компьютеров посредством этих конверторов через SHDSL-модемы.
Что хочется отметить. Стек протоколов TCP/IP сложен для понимания, но продуман его создателями и легко адаптируется ко всем задержкам тракта передачи. Замечено, что он постоянно изменяет скорость передачи, «пытаясь» достичь ее максимума. Это часто приводит к пере ретрансляции потерянных по его инициативе пакетов (может и из-за этого не удается достичь максимума). В общем, каких либо специальных методов согласования скоростей применять не пришлось (хотя в начале думалось, что без этого не обойтись).
Вся работа по перекодировке в конверторе легла на процессор C8051F123 от Silabs (около 90 MIPS), пришлось много программировать на С51 и ассемблере в среде uVision2 от Keil версии v7.08. Для себя я решил, что имеет смысл использовать фирменные конверторы, в том числе те, что были предложены при обсуждении.
Всем спасибо и удачи.

SHDSL сами делали ? Если да на каком чипсете ?

Вобщем-то, как я и говорил где-то в этой теме... Протокол TCP сам всё сделает...

1.Есть еще и другие протоколы, которые тоже "хотят" ходить по Ethernet.
2.Сделать то он сделает все, что может. И протоколы над ним - сделают все, что могут.
Но количество дополнительно потраченной пропускной способности канала сильно завист от "качества"
такого шлюза.

Ответ Harbour. Я лично разработал и программировал регенератор SHDSL (SHDSL-модем с возможностью дистанционного питания до 3 регенераторов с каждой стороны, делал мой напарник). Все уже работает почти год в полевых условиях. В обоих случаях использовались чипы SOCRATES (PEF22622) от Infineon. Впечатления о чипе - очень удачная немецкая разработка.
Ответ Krys. Я сначала искренне сомневался, но потом действительно понял, протокол все делает за Вас. Так что советы были не зря.
Ответ zltigo. В данном случае достигнуто 85% от пропускной способности шлюза. Я слышал, что другие сделали 95%. Я упирал на низкую стоимость, хотя можно было бы увеличить за счет аппаратурных затрат этот процент.

Я не об этом. Когда через этот шлюз пойдут несколько (или несколько десятков) даже TCP/IP
соединений что будет? Если шлюз не сможет забуферировать пик нагрузки и потеряет часть пакетов, то тут уже не 85% пропускной способности физического канала речь пойдет :-(.

Конверторы испытывались при связи удаленного компьютера с сервером (а также двух отдельно стоящих компьютеров) загрузкой больших файлов. Использовался сниффер Ethereal, а скорость оценивалась по показаниям FAR (или рассчитывалась вручную). Также был организован доступ в Internet, при обращении к нескольким сайтам, при одновременной загрузке с одного из них.
Этот конвертор как шлюз, не имеет большого буфера со стороны Ethernet, а только для двух пакетов. Так что сниффером были видны пере ретрансляции, когда протокол TCP/IP передавал плотные "окна" с большим количеством пакетов, но все накладки им регулировались.
Еще также включался/выключался механизм "отфильтровки" посторонних пакетов по МАС-адресу удаленного компьютера (имеется в CS8900A).

У нас для примерно тех же целей (радиорелейка 4Е1+Ether) используется свитчик RTL8305+XC2S100.

Для подключения одного host компьютера и при условии большой загрузки в каждый момент времени только по одному TCP/IP соединению "на вскику" два буфера должны дать вполне работоспособную систему, что и подтверждено экспериментом. Для для условий отличающихся от описанных число буферированных пакетов должно быть много больше, да и аппаратная фильтрация по один_свой+broadcast MAC не сможет помогать :-(.
И вывод:

Совершенно правилен.
P.S.
Могу сюда для коллекции выложить фото подобной самоделки :-)
И несколько позже на более специализированном чипе.

to zltigo:
Задача была конкретная: получить "дешево-сердитый" конвертор. Что смог...
"Могу сюда для коллекции выложить фото подобной самоделки :-)
И несколько позже на более специализированном чипе."
Приветствуется

to TomaT
А как Вы решали аналогичные проблемы? В частности, накопление пакетов в очереди шлюза (задачу выравнивание скоростей)?

Я ведь не в порядке "распальцовки", тем более, что история появления уже была четко изложена ранее. Просто для ориентации потенциальных последователей в ограничениях :-( накладываемыми
простыми решениями.
А Ваши бойцовские качества проявленные в "безнадежном предриятии" только заслуживают уважения!

Пошел за фотоаппаратом....

Спасибо! Я тоже за то, что с виду якобы "простые" решения могут круто вылиться боком. Будущее за готовыми чипами от известных фирм, это я не оспариваю. Хотя тема сама по себе интересная.

Коллеги! У меня есть к Вам вот какое предложение.
У меня по плану статей для Элтеха должна быть статья о коммутаторах каналов для Eth. на примере чипов фирмы Микрел. Но писать голую рекламу не хочется.
Что я предлагаю:
1. Вы можете предоставить мне результаты испытаний. Тогда в статье будет написано: "результаты испытаний.... получены - ваше_имя_И_e-mail"
2. Вы можете написать главу о ... о железе, о методике испытаний, о питании по проводам...о дальнейших рекомендациях при разработке.... короче о чем хотите. Тогда в статье будет авторы: "....и ваше_имя_И_e-mail"
3. Возможны другие варианты... пока не придумал какие...

Для этого достаточно по почте на iosifk@eltech.spb.ru кинуть письмо:
"Я хочу предложить..."

Удачи!

Похоже вопрос "использовать спец. чипы vs ваять самому" того-же плана что и "C#/Java vs C/Assembler для встроенных систем" в соседнем топике.

Проект типа "впихнул и забыл" - надо быстренько "слепить байду" из чего попало и сдать проект.

Оборудование, которое надо будет потом поддерживать (не забываем про баги, которые в современных СБИС есть всегда), дорабатывать к новым требованиям и протоколам (та-же книга [Компьютерные сети: Принципы, технологии, протоколы] - "учтите, что через год половина информации из этой книги устареет") и т.д. - тут ИМХО такой поверхностный подход уже не годится...

Не зря же для решения вроде стандартной задачи "Ethernet чезер синхронный поток" вполне серьезные фирмы без конца новые "велосипеды" изобретают...

А никак, это у свитча голова по этому поводу болит, а FPGA только собирает/разбирает фреймы и заботится о их синхронизации; т.е. например для Е3 тактовая 34368кГц вот она и подается на RXC для данных которые со свитча идут, а на TXC подается синхра выделяемая E3-трансивером из HDB3 для данных с другой стороны релейки.

to TomaT
Может мне еще придется разрабатывать что-то подобное... По этому еще б небольшую структурную схему Вашего устройства: состав, что с чем связывается, и куда и на каких скоростях идут потоки, какие, где интерфейсы... Как сконфигурирован свитч, что подключается к радиорелейке.
Из сообщения все же не понятно как происходит согласование скоростей - опять все ложится на протокол TCP/IP? Какая связь между синхронными потоками Е1 и асинхронными Ethernet (где буферы пакетов)?
Если не секрет...

Частью секрет, частью нет
4E1+Eth->Radio не очень удачный пример, я там сам еще не разобрался. Оно мне досталось AsIs.
Попробую описать Eth->E3. На самом деле не совсем E3, там у нас фрейм по другому собирается.

Буферы пакетов в свитче, он и согласует, так же как и в случае когда к 100Мб свитчу 10-и Мб сетевуха вешается.

Было такое предложение-пожелание:

Результаты есть, я их прилагаю. Здесь удаленный компьютер соединялся со свичем и далее с сервером. Между ними были два конвертора Ethernet-TDM (т.е. то, для чего все это и разрабатывалось). Канал связи - это TDM (он же PCM-30, или SHDSL). Максимальная скорость канала Vmax равна N*64 кбит/с (или N*8 кбайт/с), где N - число задействованных канальных интервалов (тайм-слотов). Относительно Vmax оценивается коэффициент заполнения Кз, как отношенеи реальной скорости пересылки файлов к максимальной. Думаю, что Кз - это интегральная характеристика эффективности получаемого канала.
Испытания выполнены без применения "обратного давления" (back pressure - по натовской терминологии). Я испытал эту технологию в двух ее возможных модификациях (формирование коллизий при отсутствии свободного пространства в буферах), но она ухудшила результаты на процентов 20, поэтому от нее отказались. Вопросы есть по скорости туда и обратно, они отличаются при работе в локальной сети (в обратном направлении она низковата). Но при загрузке с интернетовских сайтов (а у нас предприятии достаточно мощный канал), коэффициент заполнения приближался к максимальному значению (в направлении от РС к серверу).
Так что вопросы плодятся и без нас...

[quote name='Волощенко' date='Sep 25 2006, 19:08' post='157931']
Было такое предложение-пожелание:
[quote name='iosifk' post='141414' date='Aug 4 2006, 12:18']
... Вы можете предоставить мне результаты испытаний.....
[/quote]

Спасибо за информацию, буду переваривать.
Думаю, что эти результаты будут интересны не только мне...

Здравствуйте!
Посмотрите на это:
http://products.zarlink.com/product_profiles/ZL50120.htm