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

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

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

Сообщение отредактировал Волощенко - May 26 2006, 09:14

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

В полнодуплексном режиме работает механизм контроля потоков 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.
Информации по протоколам вроде бы много, но объять ее тяжело. А так как нет тематического руководства, то работа напоминает хождение по темному лабиринту без фонарика. Поэтому и вопросы.

Сообщение отредактировал Волощенко - May 31 2006, 14:23

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 настраивается я понятия не имею.