TCP/IP over /dev/ser*

[wind_alex]

Olej пишет: ... На счёт "отказались", так это я совсем не уверен. На счёт предыдущих версий: dmi утверждал, что в 4.ХХ ЭТО работало. А в 6.ХХ ОНО было мёртвым отродясь, от 6.0! ....

Точно, точно сам проверял на 4.25 - все работает и даже очень не плохо.

P.S. 4.25 вообще была значительно более устойчивой(может быть это относится только к Photon )

[olej]

wind_alex пишет: P.S. 4.25 вообще была значительно более устойчивой(может быть это относится только к Photon )

Я вот, разглядывая всё это (вообще структуру системы) по документации, думаю, что "с чего бы это?"... При эволюции 4.ХХ в 6.ХХ у них есть ряд принципиально концептуальных изменений, но, вроде, нет таких, которые вели бы к потере устойчивости ...

Мне, пока, кажется, что это всё-таки "эффекты сырости" 6.ХХ ...

[ Это Сообщение было отредактировано: Olej в 2002-10-03 16:16 ]

[dmi]

Olej пишет: Я вот, разглядывая всё это (вообще структуру системы) по документации, думаю, что "с чего бы это?"... При эволюции 4.ХХ в 6.ХХ у них есть ряд принципиально концептуальных изменений, но, вроде, нет таких, которые вели бы к потере устойчивости ... Мне, пока, кажется, что это всё-таки "эффекты сырости" 6.ХХ ...

Добавились: треды, динамические библиотеки, менеджеры ресурсов. Этого более чем достаточно, чтобы обеспечить головной болью специалистов службы техподдержки, RnD и QnA
И если бы не десяток лет развития neutrino до выхода 6.0, картина была бы самая удручающая.
Несомненно, это эффекты сырости. Но такой четкости работы, как в 4.25 в 6.x мы уже не увидим. По крайней мере в десктопной инсталляции.
В целефой системе засчет этого все получается намного лучше и проще, чем в 4.2x. Хотя, опять же, от рук завсисит.

[olej]

dmi пишет: Добавились: треды, динамические библиотеки, менеджеры ресурсов. Этого более чем достаточно, чтобы обеспечить головной болью специалистов службы техподдержки, RnD и QnA

Я об этом и говорил:

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

- динамические библиотеки - это вопрос рационального использования ресурсов, но никак принципиально на систему не влияет;

- а менеджеры ресурсов ... они приняли просто законченную форму: идеология вот таких обработчиков сообщений - она была та-же и в 2.ХХ и в 4.ХХ, в 4.ХХ - уже всё необходимое было в рудиментарном виде. Т.е. это - классная, но эволюция.

[dmi]

Olej пишет: Я об этом и говорил: - самое главное, что радикально переменилось - это добавление потоков, и то, что все процедуры диспетчеризации и синхронизирующие примитивы - перенесли с уровня процессов на уровень потоков. Это пожалуй - самое главное принципиальное изменение, которое потянуло за собою многие и многие другие;

Это изначально было заложено в Neutrino, и нареканий никогда на это не слышал.  Серьезных по крайней мере. Про SMP молчу

- динамические библиотеки - это вопрос рационального использования ресурсов, но никак принципиально на систему не влияет;

Это может влиять на скорость и стабильность работы.

- а менеджеры ресурсов ... они приняли просто законченную форму: идеология вот таких обработчиков сообщений - она была та-же и в 2.ХХ и в 4.ХХ, в 4.ХХ - уже всё необходимое было в рудиментарном виде. Т.е. это - классная, но эволюция.

Как раз они изменились больше всего с Neutrino 2.0 (не путать с QNX RTOS 2.0 )

И, пожалуй, самое главное изменение - это Photon 2.0.x. В Neutrino поставлялся Photon 1.14.

[dmi]

devn-ser (замена devn-fd для /dev/serX) почти готов. Кто хочет потестировать - пишите dmi@qnx.org.ru

[Gregory]

Olej, а у вас нульмодемный шнурок трехпроводной или используются все сигналы RS232 ?

[olej]

Gregory пишет: Olej, а у вас нульмодемный шнурок трехпроводной или используются все сигналы RS232 ?

Я пробовал и то и другое (3-мя прость висящими проводами у меня соединены /dev/ser1 & /dev/ser2 на одном компе, а для соединения 2-х я "по-чесному" использовал "магазинный" нуль-модемный кабель, хотя кто его знает, какое: 3-х, 5-ти или 7-ми проводное там у них соединение...). Как я понимаю, если простая передача потоком через /dev/ser:
#cp xxx /dev/ser1
#cat /dev/ser2
- идёт, то соединение есть, и не должно ни на что влиять. По 3-х проводной линии - есть!

[Gregory]

У меня тоже 3х проводной. Но как мне кажется то что я наблюдаю не соответсвует скорости 57600 бпс.
Как вобще можно посмтореть скорость передачи информации?
cp -V кажет тока проценты..
А... Есть предположение попробовать time cp //1/xxx //2/yyy/
Пойду проверять.

[dmi]

Тут немного открывается "истина": devn-fd писался для то-ли автоответчиков, то-ли для факсов. Суть в том, что он не поддерживает пакетную передачу данных.
В 6.2.1 будет новая версия devn-fd.so с поддержкой передачи пакетных данных. Т.е., возможно, по нему будет работать даже qnet.
Используется вроде бы механизмы из PPP.

В QNX4 вы никогда не увидите ничего похожего на 56К - увидите либо больше, либо меньше. Во-первых используется HDLC для передачи пакетных данных ( как это то по-русски называется -bit/byte stuffing ? ). Во вторых используется компрессия при передаче данных.
Так что там-то как раз все более чем просто хорошо. И FLEET (qnet для QNX4) работает...

[Gregory]

Вот, проверил.
cp -V всетаки показывает скорость в kb/s. Эт я не туда смотрел.
А time показало, что файл размером 960кб копировался с узла1 на узел2
187 с. Итого 960*1024*8/127=42055. Плюс наверное расход на всякие CRC и заголовки пакетов. Вобщем зря я переживал.