Загрузка RT-11 через порт системного терминала

[Patron]

Похоже, что это известная проблема (системы сбора статистики?) Windows, которая возникает практически во всех версиях ( Vista ещё глючит, остальные - не знаю ), когда хотя бы один из потоков процесса блокируется каким-то особым образом.

На быстродействие других процессов это не влияет, но все свободные тики (одного ядра?) убираются из System Idle и случайным (?) образом распределяются между процессами, имеющими заблокированный поток с блокировкой такого типа.

Возможно, это связано с тем, что при ожидании сигнала BREAK в COM-порту или VSYNC в видео-адаптере - Windows включает в ядре циклический опрос этих признаков.

Но т.к. это происходит в ядре - это не влияет на загруженность системы, а только на выдаваемую статистику.

В принципе, можно с этим побороться, добавив настройку, отключающую ожидание BREAK, но насколько это актуально.. Если эти 100% загрузки присутствуют только в статистике, а процессор не греется - надо ли с этим бороться..

[Advertiser]

[bigral]

Если эти 100% загрузки присутствуют только в статистике, а процессор не греется - надо ли с этим бороться..

у меня старый проц с 1-им ядром комп тормозит жутко и дергается эмулятор консоли, в process explorer показывает что 95% времени забирает процесс в kernel mode (красным) значит шото там в драйвере сходит с ума и он там "висит" вместо того чтоб в idle ждать прерывания от usb чипа

[Patron]

у меня старый проц с 1-им ядром комп тормозит жутко и дергается эмулятор консоли

У меня есть такой комп - я там запустил такой же "подвешиватель", но комп не тормозит - можно запустить ещё один эмулятор ДВК на любой скорости (вплоть до максимальной) и потери скорости нет.

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

Вероятно, на многоядерных процах Windows подвесит одно ядро на ожидание BREAK, а другое - на ожидание VSYNC ( если запросить ожидание VSYNC ).

Придётся добавить настройку IP-адаптера, позволяющую отключить ожидание BREAK в COM-порту.

[form]

Вероятно, на многоядерных процах Windows подвесит одно ядро на ожидание BREAK

Осталось понять почему тот же E11 не испытывает проблем с этим.
Если сделать в нем SET THROTTLE ON фактически с любыми параметрами - будет стабильная загрузка 0% процессора независимо от активности внутри эмулятора и прекрасная отработка BREAK

[Patron]

У плохого программиста всегда виновата операционка!
Косяк был мой - хорошо, что заметили.

[MiX]

В ситуации, когда есть работоспособная материнская плата ДВК/PDP-11 и нет ни дисков, чтобы загрузить RT-11, ни терминала для ввода/вывода, но есть возможность подключить порт системного терминала такой платы к COM-порту PC или интернет-адаптеру - предлагаемое решение позволяет использовать такое подключение для загрузки RT-11 через порт системного терминала.

Всё неплохо толь-ко вот схемы нет. Нашёл в инете вот такую: http://zx.pk.ru/attachment.php?attac...1&d=1388944891
пойдёт?

[Patron]

Всё неплохо только вот схемы нет.

Можно такой вариант попробовать: Простой адаптер RS-232 - "Токовая петля".

[bigral]

вот подключил лог:

@10000G«001»«375»      CR«000»«000»«000»«000»«000»«000»«002»«227»«000»
HX 2.0 - Cold boot..
«000»«001»«375»        Cr«000»«002»«000»«000»«000»«000»«010»«277»«000»«001»«375»       Cr«000»«006»«000»«000»«000»«000»«004»«277»«000»«001»«375»       Cr«000»{«001»«000»«000»«274»«000»«355»«001»«001»«375»   Cr«000»W«001»«000»«000»«000»«002»«017»«001»«001»«375»   Cr«000»W«001»«000»«000»^«005»p«001»
HX DSK/TTY multiplexer   v2.3  2013
«001»«375»     Cr«000»z«001»«000»«000»«256»«001»«337»«001»«001»«375»   Cr«000»~«001»«000»«000»«226»A«013»«002»«001»«375»       Cr«000»}«001»«000»«000»«006»«001»:«001»«001»«375»       Cr«000»|«001»«000»«000»«226»«000»«310»«001»«001»«375»   Cr«000»-«000»«000»«000»«000»«002»«344»«000»«001»«375»   Cr«000»/«000»«000»«000»«000»«002»«346»«000»

[Patron]

вот подключил лог

Это круто. Видно, что успешно выполнилось много запросов и к первичному, и к основному драйверу.

Но чтобы не расшифровывать "вручную" заголовки запросов - лучше сохранить лог консоли "HX Log":




Тогда ( имея под рукой загрузочный образ ) можно легко и точно определить, какой блок какого файла был прочитан последним.

...

Если консоли "HX Log" в используемой конфигурации нет - её можно добавить:

[objects]

HX_Log = Ядро:Console


[links]

HX [Log] > HX_Log

[bigral]

к сожалению не записал на каком блоке оно прекращало чтение, и пока тот конфиг недоступен, думаю немного позже вернусь к нему, вот попробовал пустить начальный загружчик на m8186 kdf11 + какая очень странная карта plessey 705965-100A (c одним разьемом непонятного назначения и двумя slu)

?
@10000/012706 12706
010002/010000 10000
010004/012746 12746
010006/000340 340
010010/012746 12746
010012/010016 10016
010014/000002 2
010016/004567 4567
010020/000032 14
010022/176401 105737
010024/041411 177560
010026/000122 100375
010030/000000 113703
010032/000000 177562
010034/001000 207
010036/000227 105737
010040/105737 177562
010042/177560 105737
010044/100375 177564
010046/113703 100375
010050/177562 112737
010052/000207 26
010054/012704 177566
010056/000016 12700
010060/105737 1000
010062/177564 5004
010064/100375 4715
010066/112537 110324
010070/177566 5300
010072/005304 1374
010074/001371 5007
@10000G
010000
@