[Voloshchenko 0]

Добрый день!

Работа по моему конвертору Ethernet-ИКМ(Е1 или TDM) подошла к концу. Поэтому благодарность всем за советы и подсказки. Прилагаю фото платы конвертора. Напомню, что максимальная скорость передачи через конвертор N*64кбит/с, где N=1..32 число задействованных тайм слотов потока Е1. Удалось достичь средней скорости 85% от максимума при связи двух компьютеров посредством этих конверторов через SHDSL-модемы.

Что хочется отметить. Стек протоколов TCP/IP сложен для понимания, но продуман его создателями и легко адаптируется ко всем задержкам тракта передачи. Замечено, что он постоянно изменяет скорость передачи, «пытаясь» достичь ее максимума. Это часто приводит к пере ретрансляции потерянных по его инициативе пакетов (может и из-за этого не удается достичь максимума). В общем, каких либо специальных методов согласования скоростей применять не пришлось (хотя в начале думалось, что без этого не обойтись).

Вся работа по перекодировке в конверторе легла на процессор C8051F123 от Silabs (около 90 MIPS), пришлось много программировать на С51 и ассемблере в среде uVision2 от Keil версии v7.08. Для себя я решил, что имеет смысл использовать фирменные конверторы, в том числе те, что были предложены при обсуждении.

Всем спасибо и удачи. :)

[Harbour 0]

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

[Krys 2]

В общем, каких либо специальных методов согласования скоростей применять не пришлось (хотя в начале думалось, что без этого не обойтись).

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

[zltigo 2]

Протокол TCP сам всё сделает...

1.Есть еще и другие протоколы, которые тоже "хотят" ходить по Ethernet.

2.Сделать то он сделает все, что может. И протоколы над ним - сделают все, что могут.

Но количество дополнительно потраченной пропускной способности канала сильно завист от "качества"

такого шлюза.

[Voloshchenko 0]

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

Ответ Krys. Я сначала искренне сомневался, но потом действительно понял, протокол все делает за Вас. Так что советы были не зря.

Ответ zltigo. В данном случае достигнуто 85% от пропускной способности шлюза. Я слышал, что другие сделали 95%. Я упирал на низкую стоимость, хотя можно было бы увеличить за счет аппаратурных затрат этот процент.

[zltigo 2]

Ответ zltigo. В данном случае достигнуто 85% от пропускной способности шлюза.

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

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

[Voloshchenko 0]

Конверторы испытывались при связи удаленного компьютера с сервером (а также двух отдельно стоящих компьютеров) загрузкой больших файлов. Использовался сниффер Ethereal, а скорость оценивалась по показаниям FAR (или рассчитывалась вручную). Также был организован доступ в Internet, при обращении к нескольким сайтам, при одновременной загрузке с одного из них.

Этот конвертор как шлюз, не имеет большого буфера со стороны Ethernet, а только для двух пакетов. Так что сниффером были видны пере ретрансляции, когда протокол TCP/IP передавал плотные "окна" с большим количеством пакетов, но все накладки им регулировались.

Еще также включался/выключался механизм "отфильтровки" посторонних пакетов по МАС-адресу удаленного компьютера (имеется в CS8900A).

[TomaT 0]

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

[zltigo 2]

не имеет большого буфера со стороны Ethernet, а только для двух пакетов.

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

И вывод:

Для себя я решил, что имеет с мысл использовать фирменные конверторы, в том числе те, что были предложены при обсуждении.

Совершенно правилен.

P.S.

Могу сюда для коллекции выложить фото подобной самоделки :-)

И несколько позже на более специализированном чипе.

[Voloshchenko 0]

to zltigo:

Задача была конкретная: получить "дешево-сердитый" конвертор. Что смог...

"Могу сюда для коллекции выложить фото подобной самоделки :-)

И несколько позже на более специализированном чипе."

Приветствуется :cheers:

 

to TomaT

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

Изменено 4 августа, 2006 пользователем Волощенко

[zltigo 2]

Задача была конкретная: получить дешево-сердитый конвертор. Что смог...

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

простыми решениями.

А Ваши бойцовские качества проявленные в "безнадежном предриятии" только заслуживают уважения!

Приветствуется :cheers:

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

[Voloshchenko 0]

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

[iosifk 3]

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

 

Коллеги! У меня есть к Вам вот какое предложение.

У меня по плану статей для Элтеха должна быть статья о коммутаторах каналов для Eth. на примере чипов фирмы Микрел. Но писать голую рекламу не хочется.

Что я предлагаю:

1. Вы можете предоставить мне результаты испытаний. Тогда в статье будет написано: "результаты испытаний.... получены - ваше_имя_И_e-mail"

2. Вы можете написать главу о ... о железе, о методике испытаний, о питании по проводам...о дальнейших рекомендациях при разработке.... короче о чем хотите. Тогда в статье будет авторы: "....и ваше_имя_И_e-mail"

3. Возможны другие варианты... пока не придумал какие...

 

Для этого достаточно по почте на [email protected] кинуть письмо:

"Я хочу предложить..."

 

Удачи!

[dmivs 0]

Я пока начинаю работать над похожей задачей

Буду лепить похожую байду через месяц

 

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

 

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

 

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

 

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

Изменено 4 августа, 2006 пользователем dmivs

[TomaT 0]

...

to TomaT

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

 

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