УКНЦ загрузка через стык С2

[Patron]

Мне видится следующее:

1. Проблемы с использованием сжатия вызваны тем, что драйвер распаковывает сжатые данные в момент поступления, поэтому при большом сжатии, большой скорости порта и медленном процессоре - "онлайновая" распаковка невозможна ( PDP-11/83 на скрости порта 9600 справляется без проблем ). Думаю, если разработать комбинированный "онлайн-офлайновый" алгоритм распаковки - максимальное сжатие в протоколе HX v2.0 можно будет увеличить с 256 до 65535.

2. Без использования сжатия - драйвер HX уже сейчас способен работать по двухпроводной линии без квитирования почти на любом процессоре и любой скорости порта. Максимальное количество байтов в секунду, которое может принимать драйвер зависит (конечно же) от скорости процессора и типа операционки ( при поддержке очереди таймера в ядре RT-11 - максимальная продолжительность критического цикла драйвера, выполняемого при получении каждого байта данных - увеличивается на добрую сотню команд ). Для точного определения максимальной скорости RAW-обмена в HX, в зависимости от используемого процессора и операционки - есть смысл написать тестовую программу HXTST.SAV.

3. Для начальной загрузки с HX0 можно сделать специализированную разновидность Boot-блока HX - BotHX0.bin, при передаче которого в УКНЦ - UKNCcomSender будет впечатывать в него дату и время сервера в формате RT-11 для установки в процессе загрузки.

4. Если научить UKNCcomSender реагировать на произвольно задаваемый промпт, то возможно его совместное использование с ODT_Loader для установки времени сервера в RT-11 при загрузке с HX0 ( при помощи BotHX0.bin ) на ДВК / PDP-11 ( и других компьютерах с Micro-ODT ).

5. В протоколе HX v1.1 не поддерживается формирование ( на стороне сервера ) и использование ( на стороне драйвера ) признака конца файла при операциях вблизи и за пределами границы образа. Исправить это можно и нужно в протоколе HX v2.0.

[Alex_K]

1. Проблемы с использованием сжатия вызваны тем, что драйвер распаковывает сжатые данные в момент поступления, поэтому при большом сжатии, большой скорости порта и медленном процессоре - "онлайновая" распаковка невозможна ( PDP-11/83 на скрости порта 9600 справляется без проблем ). Думаю, если разработать комбинированный "онлайн-офлайновый" алгоритм распаковки - максимальное сжатие в протоколе HX v2.0 можно будет увеличить с 256 до 65535.

Драйвер можно написать с использованием прерываний. Это правда невозможно, когда для HX используется порт терминала. В случае отдельного канала, как стык С2 на УКНЦ - это возможно. Правда придется вводить приемный буфер и усложнять драйвер. Другой вариант - при поступлении запакованных данных передачу со стороны сервера прекратить и возобновить после того, как HX-драйвер подтвердил, что данные распокавал и можно передавать дальше.

3. Для начальной загрузки с HX0 можно сделать специализированную разновидность Boot-блока HX - BotHX0.bin, при передаче которого в УКНЦ - UKNCcomSender будет впечатывать в него дату и время сервера в формате RT-11 для установки в процессе загрузки.

Здравая мысль. В этот блок еще надо добавить и номер загружаемого устройства.

4. Если научить UKNCcomSender реагировать на произвольно задаваемый промпт, то возможно его совместное использование с ODT_Loader для установки времени сервера в RT-11 при загрузке с HX0 ( при помощи BotHX0.bin ) на ДВК / PDP-11 ( и других компьютерах с Micro-ODT ).

Ну это будет работать только на ДВК и других PDP-11. На УКНЦ регистры терминала внутренние и никуда наружу не выводятся.

5. В протоколе HX v1.1 не поддерживается формирование ( на стороне сервера ) и использование ( на стороне драйвера ) признака конца файла при операциях вблизи и за пределами границы образа. Исправить это можно и нужно в протоколе HX v2.0.

Насколько я помню признак EOF$ монитором SJ не поддерживается. Так написано у меня в книге "Макроассемблер в среде ОС ДВК". Но эта книга еще про 4-ю версию системы, может в пятой и поддержали окончательно, надо читать документацию.

Кстати BINCOM запросил таки размер диска, но уже после того как получил ошибку о том, что невозможно считать блок 1621. Ну что делать, так BINCOM написан.

[Patron]

Драйвер можно написать с использованием прерываний.

Это не решит проблему, т.к. распаковка может занимать относительно много времени и никакого внутреннего буфера драйверу не хватит. Но я уже придумал как можно работать со сжатыми и несжатыми данными на одинаковой скорости и без использования большого дополнительного кода ( идея тянет на нобелевскую премию по программированию ).

признак EOF$ монитором SJ не поддерживается. Так написано у меня в книге "Макроассемблер в среде ОС ДВК"

Наичная с 5-й версии (насколько я понимаю) все драйвера выдают признак конца файла при попытке работы за пределами устройства.

Вот как, например, выглядит соответствующее место в драйвере псевдоустройства HD из "эмулятора ДВК":

HDREAD:
	Mov	R1,	@#HD$CSR+2	;
	Mov	#SetWCn, @#HD$CSR	; Set word count
	Tst	@#HD$CSR			; Valid?
	BPl	5$			;   Yes - OK
	Mov	HDCQE,	R4		;
	BiS	#EOF$,	@-(R4)		;   Else - set EOF bit
5$:
	Mov	#CmdRea, @#HD$CSR	; Make Read from HD

[Patron]

Программа TSTHX.SAV крутит в цикле ядро драйвера HX.SYS, считая "обороты" и позволяя таким образом определить ту максимальную битовую скорость порта ( в BPS ), на которой драйвер HX.SYS сможет рботать в данной системе по двухпроводной линии без потери байтов.

Для эмулируемой ДВК-1 результаты следующие:

.SH CON
 
RT-11SJ (Y) V05.04 G
Booted from HD0:RT11SJ
 
USR   is set SWAP
EXIT  is set SWAP
KMON  is set NOIND
TT    is set NOQUIET
ERROR is set ERROR
SL    is set ON
EDIT  is set KED
KMON nesting depth is 3
 
LSI 11 or PDP 11/03 Processor
56KB of memory
Extended Instruction Set (EIS)
Floating Instruction Set (FIS)
50 Cycle System Clock
 
No SYSGEN options enabled
 
.RU HXTST
 
HXTST - Check HX port READ speed v1.0
 
Max HX Port BPS for this OS & CPU: 59'994
 
Program completed.

RT-11SB (S) V05.07
Booted from HD1:RT11SB
 
USR     is set SWAP
EXIT    is set SWAP
KMON    is set NOIND
MODE    is set NOSJ
TT      is set NOQUIET
ERROR   is set ERROR
SL      is set ON
EDIT    is set K52
FORTRAN is set FORTRA
KMON nesting depth is 3
Global .SCCA flag is disabled
 
CLI is set DCL, CCL, UCL, NO UCF
 
LSI 11 or PDP 11/03 Processor
56KB of memory
Extended Instruction Set (EIS)
Floating Instruction Set (FIS)
50 Hertz System Clock
 
SB timer support
Global .SCCA support

.RU HXTST
 
HXTST - Check HX port READ speed v1.0
 
Max HX Port BPS for this OS & CPU: 24'610
 
Program completed.

Понятно, что даже на самых медленных машинах HX.SYS (без использования сжатия) может работать без потери байтов.

Как и предполагалось - в системах с поддержкой очереди таймера быстродействие падает многократно.

...

[Alex_K]

У меня на УКНЦ скорость в пределах 12400-12500. Скорость порта 9600, 8N2.

[Patron]

У меня на УКНЦ скорость в пределах 12400-12500. Скорость порта 9600, 8N2.

1200 циклов чтения порта в секунду ( значение BPS тест получает, умножив на 2 число циклов чтения порта за 5 сек ) - что-то маловато. Может, тест врёт.. ( Там, кстати, ошибка есть, правда не принципиальная - вместо тестируемого порта идёт обращение к ячейке ОЗУ с адресом этого порта - но вряд ли это может снизить скорость тестируемого кода ).

Такое впечатление, будто на векторе таймера куча всего сидит.

А монитор при этом как сгенерён, есть там SJ timer support или SB timer support, что по SH CON пишет ?

[Advertiser]

[Alex_K]

А монитор при этом как сгенерён, есть там SJ timer support или SB timer support, что по SH CON пишет ?

Используется образ HXsys54.DSK, который идет в комплекте с HX-сервером. Перекопировал туда HXTST, там и запускаю. По SHOW CONF пишет, что "No SYSGEN options enabled". Да и п/п обработки прерывания таймера состоит из двух команд ADC и одной RTI.

[Patron]

Попробуем начать с малого - без учёта негативного влияния прерываний на процесс чтения порта драйвером HX.SYS.

В приложении - HXUCPS.SAV - тест числа чтений порта 176570 драйвером HX.SYS в секунду ( т.е. измеряется CPS ).

На эмулируемой ДВК-1 результат во всех мониторах такой:

.RU HXUCPS
 
HXUCPS - Check HX port 176570 READ speed v1.0
 
Max HX Port CPS for this OS & CPU: 13'063
 
Program completed.

...

[Alex_K]

Попробуем начать с малого - без учёта негативного влияния прерываний на процесс чтения порта драйвером HX.SYS.

В приложении - HXUCPS.SAV - тест числа чтений порта 176570 драйвером HX.SYS в секунду ( т.е. измеряется CPS ).

Результат - от 16630 до 16660.

[Patron]

Результат - от 16630 до 16660.

Когда УКНЦ обгоняет ДВК-1 - это больше похоже на правду.

Но где же происходит такое резкое падение быстродействия ( если это был не глюк ).

Попробуем добавить в цикл подготовку вызова обработчика прерывания таймера - см. HXUCPS.SAV v1.1

На эмулируемой ДВК-1 результат такой:

.RU HXUCPS
 
HXUCPS - Check HX port 176570 READ speed v1.1
 
Max HX Port CPS for this OS & CPU: 9'822
 
Program completed.