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

andrewk
Поэтому принудительно переключать всех на одно ядро как-то не комильфо.

Переключается только один указанный процесс - т.к. никакие досовские программы в принципе не умеют работать с потоками, никаких преимуществ от многоядерности они никогда не получают. И проблемы с тем что этот антиквариат привязан строго к одному логическому ядру нет. Прочие процессы смогут использовать все ядра без ограничений.
Проблема ещё может быть с тем, что не все досовские программы адекватно отдают процессорное время системе... Вполне логично что для программ разработанных для работы "монопольно" на одном процессоре, при том процессоре не имеющем практически никаких систем "управления нагрузкой", никто и никогда не заморачивался на какой либо "разгрузке" CPU. Кстати, это касается и собственно "командной строки MSDOS" - например если установить в виртуалбокс ОС линейки Win9x, или собственно сам MSDOS - проблема возникнет даже если ничего не запускать, а просто глазеть на мигающий курсор на чёрном экране.
Это приводит к тому, что в некоторых эмуляторах эти программы начинают тупо забирать все 100% времени одного ядра, вызывая, помимо дикого расхода системных ресурсов, ещё и перегрев CPU. Не знаю, касается ли это конкретно FPD при работе под управлением ntvdm (хотя не удивлюсь если при использовании каких INKEY() и старина FPD ведёт себя безобразно), но и это нужно учитывать при запуске "антиквариата". Помнится для виртуалок где ещё использовались DOS программы я ставил какие-то специальные "разгрузочные" утилиты - типа idle.com или tamedos...

andrewk

Simple777

andrewk
если эта галочка установлена, с помощью NirCmd переключаю процесс ntvdm.exe на работу на одном ядре.

Есть известная проблема зависания FPD-приложений на многоядерных процессорах. Лечится путем запуска в bat-файле утилиты типа iceaffinity.exe (насчет точности указанного имени не уверен). После этого зависаний нет. Проверено многократно. На форуме тоже есть обсуждение этой темы.

Дак, возможно, когда-то чтение форума и толкнуло меня в эту сторону подумать насчёт ядер))

Но вариант с IceAffinity.exe мне не нравится тем, что он запускается перед стартом нашего процесса, то есть всегда. А (по моей статистике клиентов) такие зависы происходят процентах, наверное, на 10 компьютеров, не больше. Поэтому принудительно переключать всех на одно ядро как-то не комильфо. Лучше уж, раз есть возможность, это сделать только по необходимости.

Так была ж таки и тема как это одноразово делается.
Помнится я даже пару раз про это говорил. Может и чуть больше. Когда-то, когда заметил подвисания в FPD на только что появившихся тогда 2-х ядерниках, прежде всего например на командах BROWSE. Там, где у меня были самописные их аналоги через SAY-GET вроде бы нормально было. Но тем не менее, поискал, нашел патчер, причем непосредственно микрософтовский. Там в темах кажется даже его и пристегивал, он небольшой.
После патчения в защищенном режиме файла NTVDM.EXE - он начинает работать только на одном ядре. Т.е. без проблем.

Igor Korolyov

andrewk
Поэтому принудительно переключать всех на одно ядро как-то не комильфо.

Переключается только один указанный процесс

Да. С указанием на конкретное ядро. И если запустить 4 экземпляра программы, то все 4 процесса ntvdm будут работать на этом ядре.

Igor Korolyov
никакие досовские программы в принципе не умеют работать с потоками, никаких преимуществ от многоядерности они никогда не получают

Они не получают. Но если не принуждать ОС выполнять процессы на конкретном ядре, то существует вероятность, что разные процессы ntvdm будут работать на разных ядрах, что, возможно, способствует более равномерному распределению нагрузки.

Igor Korolyov
Не знаю, касается ли это конкретно FPD при работе под управлением ntvdm

Конечно, касается, как и любой DOS-программы. Вообще, проблема стала проявляться на NT-системах. Под Win9x несколько одновременно запущенных DOS-программ вполне себе весёленько работали и не мешали, там всё зависело от объёма ОЗУ. А когда пересел с 98 на Win2000 сразу всплыли эти проблемы. По этой причине тогда же отказался от ДосНавигатора в пользу Far-а. Проявлялось в более медленной реакции на клавиатуру, в FPD возникли какие-то проблемы с ограничением памяти (не помню уже), отъём процессорного времени... Причины понятны и тыщу раз мусолились ещё в те времена.

Igor Korolyov
ставил какие-то специальные "разгрузочные" утилиты - типа idle.com или tamedos...

Я несколько раз пытался прикрутить Tame, но каждый раз бросал с психом - всё как-то криво там было. Все проблемы решаются запуском малюсенького ResFree.com из Autoexec.nt.

Crispy
поискал, нашел патчер, причем непосредственно микрософтовский. Там в темах кажется даже его и пристегивал, он небольшой.
После патчения в защищенном режиме файла NTVDM.EXE - он начинает работать только на одном ядре. Т.е. без проблем.

Ну когда 1-2-3 машине можно и патчить. Но в чужих конторах, где техникой занимаются другие люди, всё это проблемно. Или наоборот, у каких-нибудь "домашних" бухгалтеров. К тому ж поставится какое-нибудь очередное обновление и привет. Поэтому использовать SetProcessAffinity через какую-нибудь "свою" прогу, наверное, всё-таки разумнее, чем влазить в систему.

andrewk

Crispy
поискал, нашел патчер, причем непосредственно микрософтовский. Там в темах кажется даже его и пристегивал, он небольшой.
После патчения в защищенном режиме файла NTVDM.EXE - он начинает работать только на одном ядре. Т.е. без проблем.

Ну когда 1-2-3 машине можно и патчить. Но в чужих конторах, где техникой занимаются другие люди, всё это проблемно. Или наоборот, у каких-нибудь "домашних" бухгалтеров. К тому ж поставится какое-нибудь очередное обновление и привет. Поэтому использовать SetProcessAffinity через какую-нибудь "свою" прогу, наверное, всё-таки разумнее, чем влазить в систему.

Да какие проблемы-то. В принципе, если везде используется одна и та же версия, скажем ПРО-СП3 (хотя может данный файл и вообще одинаков везде на ХР, просто на проверял) - можно всего лишь раз пропатчить, а потом просто кидать пропатченный на нужный комп. При обновлениях - он точно не меняется. Тем более сто лет как ХР на помойке у МС, какие обновления. Т.е. на всякий случай элементарно сравнить файлы скажем у Хоум и Про. И если одно и то же (что скорее всего), то и действовать.
Ну или можно конечно так и гемороиться до упора. ;)
Кстати, что-то смутно припоминается (давно уж оно было, с тех пор уже лет 10, может больше, на паре компов оно все еще так и работает без проблем), что надо было файл заменять даже не в защищенном режиме, а с LiveCD. Просто делал патч обычно через FAR на самом харде, он как бы портабильный, т.е. ему все равно, откуда все грузится, вот и запомнилось.





Исправлено 1 раз(а). Последнее : Crispy, 07.02.18 06:44

andrewk
Да. С указанием на конкретное ядро. И если запустить 4 экземпляра программы, то все 4 процесса ntvdm будут работать на этом ядре.

Зачем бы понадобилось запускать 4 копии программы? Я понимаю РАЗНЫЕ программы - но одну...
Кроме того, как же вы раньше жили то на одноядерных процессорах, где таки все эти эмуляторы на одном единственном ядре и работали

andrewk
Они не получают. Но если не принуждать ОС выполнять процессы на конкретном ядре, то существует вероятность, что разные процессы ntvdm будут работать на разных ядрах, что, возможно, способствует более равномерному распределению нагрузки.

Говорить о "распределении нагрузки" для систем построенных в идеологии монопольного пользования всеми ресурсами компьютера несколько наивно... Но в любом случае фиксация одного ntvdm на ядре ну ОЧЕНЬ слабо повлияет на то как виндовый планировщик распределит оставшиеся полсотни, а в новых ОС и все полторы сотни остальных процессов. Гораздо больше ударит по CPU указанная склонность DOS программ пожирать все 100% выделяемого им процессорного времени. Впрочем, для какого-нить DosBox вполне можно ограничить и это. Если уж так всё плохо будет, то стоит просто поменять эмулятор на более настраиваемый.

andrewk
Под Win9x несколько одновременно запущенных DOS-программ вполне себе весёленько работали и не мешали, там всё зависело от объёма ОЗУ.

Не помню я таких "радостей и горестей", наверное очень мало DOS софта осталось у меня к 2000-му году NC и DN однозначно не были моим выбором - старинные архиваторы, возможно, но они запускались в фоне, без ожидания ввода/вывода, и потому пожирание ими cpu как-бы не было проблемой - они ж не "во время простоя в ожидании нажатий кнопок" грузили проц, а во время реальной работы...
Вот то что в общем Win9x была гораздо менее стабильной ОС по сравнению с NT линейкой - это я хорошо помню. И как только вышла Win2K Prof, я быстренько ушёл с 9x линейки. На NT вполне реально было работать неделями без перезагрузок, а 9x выключалась даже при уходе на обед, "во избежание" Конечно же в 2K были серьёзные проблемы с поддержкой DOS антиквариата - тамошний ntvdm был очень слаб и убог, и лишь к выходу XP его более-менее довели до ума.

Crispy
Да какие проблемы-то. В принципе, если везде используется одна и та же версия, скажем ПРО-СП3 (хотя может данный файл и вообще одинаков везде на ХР, просто на проверял) - можно всего лишь раз пропатчить, а потом просто кидать пропатченный на нужный комп.

Не понял, почему именно об XP речь.
Вот пример: есть файл-сервер, на нём лежит БД и сама программа. В конторе несколько юзеров работает с этой программой по сети. ОС от XP до 10, раньше и 98 попадались. Я там не бываю месяцами, если не годами. Компьютеры ломаются, системы переставляются. Ну о каком патчинге системных файлов может быть речь? Есть механизм, который работает очень давно, работает без всех этих дополнительных телодвижений.

Igor Korolyov
Зачем бы понадобилось запускать 4 копии программы? Я понимаю РАЗНЫЕ программы - но одну...

Программа одна, несколько БД (разные предприятия), которые ведут одни люди, соответственно несколько запущенных экземпляров. Другой вариант: терминальный "сервер" (обычный выделенный компьютер), на котором удалённо работают несколько человек.

Igor Korolyov
Кроме того, как же вы раньше жили то на одноядерных процессорах, где таки все эти эмуляторы на одном единственном ядре и работали

Да, конечно, сейчас это вообще не проблема. Дольше говорим об этом

andrewk
Не понял, почему именно об XP речь.

Да потому что подвисание идет на клиентских машинах. Как раз таки из-за конфликта ntvdm на ряде команд с видеодрайвером.
Что же касается 98 винды - то это была, как и заметил выше Игорь, "ужасная гадость заливная рыба", ненадежная, нестабильная и постоянно зависающая, причем зависание невозможно было снять без перезагрузки. В этом отношении поначалу ХР показалась чем-то нереально замечательным. Потом уже стали вылазить тоже подвисания и прочее, тем не менее подвисание того же FPD уже элементарно решалось прибиванием процесса.
Ну какие-то были и "потери" из-за нее - типа перестали работать знаменитые прерывания и пришлось отказаться от каких-то примочек.
Но в целом это все же улучшило, в том числе и работу с FPD.





Исправлено 1 раз(а). Последнее : Crispy, 08.02.18 08:37

Crispy

andrewk
Не понял, почему именно об XP речь.

Про сравнение 9x и NT-based, конечно, согласен.
Но я спрашивал «почему речь про XP» на предложение «раз пропатчить, а потом просто кидать пропатченный на нужный комп». Речь-то идёт об универсальном решении с наименьшим количеством трудозатрат. Не разовых, а потом, в сопровождении (лучше день потерять, потом за пять минут долететь). Что там у кого установлено - непредсказуемо, к тому же меняется.