COM port на 16c550 Uart

Цитата:

---

Сообщение от Alex

В мультиплексорах были ещё буфера

---

Не только в мультиплексорах. Кстати, ЕМНИП, то и для каких то DL были вроде FIFO. И кстати - ещё плюс мультиплексоров - можно было на прерывании проверить готовность по всем каналам, то есть там соотношение - готовность/прерывания будет больше единицы, что снижает накладные.

Цитата:

---

Сообщение от Alex

PDP2011 - скажем так, случай несколько особый

---

Это не особый случай, это случай ОЧЕНЬ быстрого PDP-11. А значит, ВМ3, F11 и даже J11 - ситуация будет ещё хуже.

Цитата:

---

Сообщение от Alex

Как мне представляется, при копировании - в SJ всё зависнет, но там всего лишь одна задача и на это плевать.

---

Не в этом дело. А в том, что если накладные расходы (обработка прерывания) становятся ощутимыми, то РЕАЛЬНАЯ скорость передачи - падает. И будь у тебя хоть 10 мбит/с скорости uart-а - как получал ты файл на фактической скорости 100 кбит/с, которая была и на 115200 - так и получаешь. То есть скорость канал увеличили, а скорость передачи не возросла. Числа для примера, это не реальные цифры :) Реальные - надо создавать стенд и тестировать :) Но будет что-то похожее :)

- - - Добавлено - - -

Цитата:

---

Сообщение от Alex

И ещё, если ввод-вывод идёт средствами системы через макросы, то число число прерываний, обрабатываемых системой, как минимум удваивается и-за выполнения EMT ...

---

И да и нет. .TTYOUT, скажем - там ещё больше может быть, .PRINT, .WRITE - в общем случае нет

- - - Добавлено - - -

В целом, подводя итог - пропорционального Щастья от увеличения скорости - не получить. Поэтому смысла делать высокоскоростные DL для процов типа ВМ1-ВМ2 и даже 1811 - я не вижу. 38400-57600 - за глаза.
И кстати, у мелкосхемы топикстартёра основной недостаток с точки зрения PDP-11 - вовсе не FIFO - с этим вполне можно жить. А то, что есть регистры и для работы их нужно запрграммировать, а система регистров на стандартные четыре регистра устройств а-ля-DL-11 - не ложится

PDP2011 - работа с шиной внушает некие сомнения...

По поводу реальной системы - 6 каналов по 57 600(-65 прошивка). Процессор на ДВК 1801ВМ3. Система SVD ВУЗ, разработанная в нашем институте. Одна ДВК с винчестером и с платой ИРПС-6 работала с 6 УКНЦ соединённые звездой.
ДВК с RT11FB - вполне тянула, на теперешние деньги как сервер :) . На УКНЦ вполне нормально можно было работать. Даже на самой ДВК можно было что-то делать, например, фортран запускать. Пытались заменить на RT11XM - пошли тормоза :(
При этом надо учесть, что драйвер DW без прямого доступа к памяти, чисто программный обмен.

- - - Добавлено - - -

Ой, ещё забыл, в ДВК ещё был КЦГД на той же скорости 57 600, итого 7 каналов по 57 600 на -65 прошивках :)
И ещё один канал на плате процессора был в резерве для подключения куда-то ещё. Но его не считаем, так как не использовали.
И ведь работало почему-то :)

Цитата:

---

Сообщение от Alex

PDP2011 - работа с шиной внушает некие сомнения

---

И она там быстрее. Есссвенно, я говорю про мой, а а не авторский вариант.

Цитата:

---

Сообщение от Alex

На УКНЦ вполне нормально можно было работать.

---

И что - все шесть каналов одновременно и непрерывно передавали файлы? В редакторе сидеть - так ещё больше можно было навтыкать.

- - - Добавлено - - -

А ещё есть такое, как - текущее восприятие. Мне, во времена, когда в качестве домашнего компа стоял Квант-4, работа на винчестера казалось ой какой быстрой. А потом, когда я его опять оживил - "нихера себе тормоза"

Самый напряжный момент была - начальная загрузка всего класса :)
И в редакторах и с прочими программами ...
И использование редактора в таких условиях обмен сильнее грузит. Это на многозадачной RSX-11 где идёт чисто обмен с терминалом(халява :) ). А на УКНЦ загружена полнокровная RT11.
Следовательно в большинстве случаев файл .SAV тащится по каналу, плюс сам редактируемый текст(ну хотя бы часть, от редактора зависит...). далее сохранение текста... Потом KMON...

На мой взгляд - загружая какую-то терминальную программу в УКНЦ и грузя на ДВК RSX-11, работать на УКНЦ было бы комфортнее, а уж если ещё и мегабайт памяти :) Ну во всяком случае мне.

Ну да, MFM скорость обмена 5 Мбит/сек... Ещё добавим время на позиционирование и поиск сектора...
А когда до этого работал на DX: и MX: то быстрой :)

Цитата:

---

Сообщение от Alex

Ну да, MFM скорость обмена 5 Мбит/сек

---

Это скорость обмена с поверхностью. Смею уверить, что 600 кб/с на выходе ты не получишь. Если будет 200 кб/с - это будет ОЧЕНЬ хорошо.

- - - Добавлено - - -

Цитата:

---

Сообщение от Alex

Самый напряжный момент была - начальная загрузка всего класса

---

Вот на это и ориентируйся. Да ещё если впараллель, а не последовательно. И 115200 вместо 57600 тебя бы не в два раза спасло.

Я полагаю, что скорость будет ещё менее :( Позиционирование однако...

Оно и так неплохо работало :)

Возможно, что подняв скорость ситуация стала бы чуток лучше. Ну может процентов на 20... И то хлеб был бы.
По моему мнению обмен тут мог упереться в MFM винчестер ...
Так что до затыка обмена по последовательному каналу не дошло бы...

Цитата:

---

Сообщение от Alex

Так что до затыка обмена по последовательному каналу не дошло бы..

---

Если поставить канал на мбит? Дошло бы. Хотя.. Чего сейчас спорить - ситуацию всё равно не воспроизвести.

- - - Добавлено - - -

Кстати, насчёт MFM - не думаю, что уперлись в него бы. Всё таки у него одно прерывание на 512 байт, а не на 1 байт

Сама система SVD ВУЗ канула в лету :(

Ну даже чуть более чем в два раза уменьшить накладные расходы на пересылку по каналу - если бы можно было бы в регистр писать/читать не байт, а 16-бит слово ...

- - - Добавлено - - -

Прерывание - прерыванием, но передача буфера контроллера происходит программно. Но именно словами, а не байтами.

Цитата:

---

Сообщение от Alex

но передача буфера контроллера происходит программно

---

И накладных расходов при этом ГОРАЗДО меньше, потому что не надо на каждом байте (слове) контекст сохранять, вопсстанавливать. У мультиплексоров, кстати, из за этого при массовой передаче-приёме (по всем каналам) накладных тоже будет меньше.

В принципе на FPGA можно малой кровью такой адаптер сделать с 16 битным регистром данных.
Ведь существовали 16 битные платы ИРПР для межмашинной связи(не видел лично, но хотя бы слышал :) ), для операционки на PDP-11 можно таковым прикинуться :)
На другой конец микроконтроллер или что душе угодно...

Да и на "старых" платах процессора ДВК параллельный интерфейс ИРПР был двунаправленный, но увы байтовый...
Причём видел плату даже МС1201.03 такую.
Потом "доработали" обозвав ИРПР-М и выкинув нормальную двунаправленность и контроллер DX, да поменяли разъём :( (точнее двунаправленность почти никуда не делась, но её можно было использовать только для диагностики)
Чисто принтер подключить :(