Linux-ваше мнение

[amito66]

Пообщайтесь с автором поста... Ему таки переписывали. Возможно - coreboot адаптированный, возможно - своя разработка, ибо военка.

coreboot не привязывается к серийнику винта и не ограничивает устройства загрузки единственным винтом. У тех военных, что я знаю, стоят либо обычные ПиСишки с обычной виндой, либо специализированные компьютеры, несовместимые с ПиСи-платформой. Более подробно не выяснял, но если надо уточнить, то могу не полениться и позвонить в Самару.

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

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

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

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

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

Вам извесно, что такое "фрагментация" памяти при страничной организации? Вы в курсе, как решается проблема фрагментации, если необходимо выделить непрерывный кусок, а свободного диапазона такого размера нет? Вы знаете, как работает своппинг в отношении страниц, которые запрошены процессом и загруженны им данными, но невостребованны несколько циклов планировщика задач? Ваша страничная адресация для нормальной работы потребует адаптации не только приложения, но и ядра, а именно планировщика, который не должен "старить" страницы с данными, принадлежащие критичному приложению, но не использованные им и своппера, который не должен такие страницы сбрасывать в своп освобождая их под аналогичные нужды другой задачи. Пока что ни одного такого работающего решения я не видел. А с приходом 64-разрядов, думаю, и не увижу.

А при том, что невозможно предсказать, как поведет себя ядро ЦП при сбое.

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

Полимерные конденсаторы и т.д. - да, долговечны, однако - вероятность аппаратного сбоя всегда есть, и она всегда ненулевая.

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

А кто мешает ядру(драйверу) управлять контроллером страничной памяти, и проверять, какому процессу какая страница принадлежит? Проблема тут надуманная.

Вот именно - надуманная. Тем более, что контроллер страничной памяти работает совершенно независимо от ядра - у него задача, обеспечить вновь "поднятому из сна" процессу память для размещения его кода и данных. Поэтому каждая страница имеет специальный флажок, который взводится аппаратно в сегменте списка страниц при каждом ссылочном обращении на страницу, а контроллер страничной памяти периодически сбрасывает эти флажки и освобождает (свопит на диск) те страницы, флажки которых не были взведены с момента последнего сброса. Ядро же считает, что в любой момент времени все страницы доступны и активны. Разработчики почему-то посчитали, что не ядерное это дело - страницами рулить.

Накладные расходы на переключение страниц не так и велики, максимум - десяток %. На своппирование - куда больше.
Почему никто не реализовал это - я пока не представляю... Возможно - в связи с тем, что АМД реализовала х64 до того, как реально потребовались такие объемы памяти... В 2001, как-никак, более 4 ГБ не требовалось...

В 2001 под такие задачи никому и в голову бы не пришло использовать Винтел-платформу - она изначально была десктопной. А сервера строили Саны, Ньюлет Паккард, ИБМ и иже с ними. Интел до нормальных серверов доросла только на 64-разрядах и то не благодаря интелу. И была бы возможность, я бы никогда интел и не поставил - ультраспарк уделает его по производительности и нагрузочной способности при равных скоростях и разрядности шины.

Речь ведь идет не только о ваших серверах. Или вы не можете представить задачи, где крутятся 2-3 ресурсоемких процесса?

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

Отнюдь. Берете однопоточное приложение, и запускаете его на дуалкоре или квадкоре. Видите 50% загрузку проца (для дуала), при этом - практически одинаковую загрузку ядер. Резонный вопрос - а нахрена???

Я вот беру фришный упаковщик 7z которому можно сказать на скольких ядрах (в сколько потоков) он должен работать. Говорю ему - один поток. и пакую им дамп базы в 40 Гб. Получаю одно из четырех ядер загруженным на 100% а три остальных - пустые. Говорю ему - два потока и получаю два ядра загруженными на 100%, а два других пустые. Никто никуда не скачет. Причем результаты абсолютно одинаковые и в виндовс 2003 и в линукс. Ну и?

[NiTr0]

coreboot не привязывается к серийнику винта и не ограничивает устройства загрузки единственным винтом. У тех военных, что я знаю, стоят либо обычные ПиСишки с обычной виндой, либо специализированные компьютеры, несовместимые с ПиСи-платформой. Более подробно не выяснял, но если надо уточнить, то могу не полениться и позвонить в Самару.

coreboot - open-source. Что это такое - вам известно. И, удмаю, вам несложно догадаться, что как раз привязку к винту заложить - потребуются минимальные усилия. Эдак строк 20-30 кода, чтение паспорта винта, и halt в случае, если серийник не совпадает. А точнее - даже просто проверка паспорта в процедуре инициализации IDE/SATA и поиска накопителей

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

Или разработчики защит. Но, суть не важно. Главное - обычный софт пользует только документированные ф-и. Следовательно, их можно эмулировать/переписать.

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

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

Вам извесно, что такое "фрагментация" памяти при страничной организации? Вы в курсе, как решается проблема фрагментации, если необходимо выделить непрерывный кусок, а свободного диапазона такого размера нет?

Фрагментация памяти была актуальна как раз при сегментной организации памяти. Для страничной организации - процессу глубоко все равно, как его страницы разбросаны в физическом адресном пространстве. Исключение - драйверы, работающие с DMA - но они себе блоки памяти заранее резервируют, да и не о них речь идет

Вы знаете, как работает своппинг в отношении страниц, которые запрошены процессом и загруженны им данными, но невостребованны несколько циклов планировщика задач?

Менеджер памяти помечает их в каталоге страниц как отсутствующие, и выгружает в своп. Что здесь такого секретного?

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

Ничего подобного быть и не должно кстати. Я что-то не слышл о попытках, к примеру, свопить видеопамять... А контроллер страничной памяти - ничем не хуже. И это - не говоря уже о возможности даже средствами оси выделить невыгружаемую память
Кстати, если же ось реализует страничный обмен через PAE - проблема со своппингом отпадает сама собой. Т.к. этим будет заниматься ядро.

А есть что-то, поведение чего можно предсказать при аппаратном сбое? Как вы себе это представляете в условиях, когда причины аппаратного сбоя неизвестны?

Есть. Всевозможные девайсы с избыточностью, начиная от банальной ECC заканчивая мажоритарными схемами.

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

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

Вот именно - надуманная. Тем более, что контроллер страничной памяти работает совершенно независимо от ядра - у него задача, обеспечить вновь "поднятому из сна" процессу память для размещения его кода и данных. Поэтому каждая страница имеет специальный флажок, который взводится аппаратно в сегменте списка страниц при каждом ссылочном обращении на страницу, а контроллер страничной памяти периодически сбрасывает эти флажки и освобождает (свопит на диск) те страницы, флажки которых не были взведены с момента последнего сброса. Ядро же считает, что в любой момент времени все страницы доступны и активны. Разработчики почему-то посчитали, что не ядерное это дело - страницами рулить.

"смешались в кучу кони, люди..."
Под контроллером страничной памяти я имел ввиду железку наподобие EMS, только несколько большего объема. Его в природе собссно не существует - амд досрочно 64бит х86-совместимую архитектуру сделала.
А то, что вы назвали "контроллером страничной памяти" - всего лишь программный менеджер памяти, неотъемлемая часть ядра оси. Поскольку за страничную адресацию отвечает только проц, и никто больше.
Если же вас так смущает данное решение - есть и другое, кстати, воплощенное в железе: накопитель на RAM-плашках. На который выносится своп, причем - абсолютно прозрачно для оси.

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

Да ну? Позабыли серверные мамки на дуал пнях 1? Вроде как и 4-процессорные были...

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

Примитивнейший пример - один сложный запрос к БД (к примеру, мускул сворачивается в трубочку, если сделать выборку с left join 3-4 таблиц, и указать несколько условий из разных таблиц).

Я вот беру фришный упаковщик 7z которому можно сказать на скольких ядрах (в сколько потоков) он должен работать. Говорю ему - один поток. и пакую им дамп базы в 40 Гб. Получаю одно из четырех ядер загруженным на 100% а три остальных - пустые. Говорю ему - два потока и получаю два ядра загруженными на 100%, а два других пустые. Никто никуда не скачет. Причем результаты абсолютно одинаковые и в виндовс 2003 и в линукс. Ну и?

Значит, майкрософт только десктопные версии кастрировал таким странным образом?

[Rhime]

як уто рукы з попы так воно мабуть и впало, а я вам скажу так мож винда и удобнее не спорю но вот Убунта стоит уже 2й год как и проблем не знаю. С бубном потанцевал два дня и вуаля вобщем мне нравится. С винды перегружаешся и отдыхаеш

[Rhime]

Хош работать в линукс? Так в чем проблема вперед ищи книжечки пошарься по форумах и хоть чтото будеш знать, а какую выбрать это уже сам ну например посмотри скрины рабочих столов и тд можешь выбрать более красивый. Но лучше выбрать тот дистрибутив который больше всего похож на виндовс-это для начала, так будет легче.

[amito66]

Хочу добавить...
Все цифровые микросхемы подвержены не частым, но регулярным сбоям.

Очередная попытка EagleStars ввести сообщество в заблуждение. Если электронная схема спроектирована и эксплуатируется в соответствии с техническими требованиями, то ни "частые", ни тем более "регулярные" сбои не могут возникнуть в принципе за все время эксплуатации. Такой техники более 95% от общего числа.

Вызвано это несколькими причинами:
1.) высокая тактовая частота, что делает микросхемы чувствительными к большому диапазону помех.

Тут вообще глупость сказана - тактовая частота вообще никакого отношения к помехам не имеет. К уровню помех имеют отношение пороги логических уровней.

2.) микросхемы для вычислительной техники в основном состоят из большого числа компонентов. Компоненты делают как можно меньше и следовательно:
а.) они работают на малых токах (по микроскопическим проводникам большой ток не пропустить, излишки выделятся в виде тепла, что приведёт к перегреву(в перегреве не последнюю роль играет и высокая частота работы)), что делает их чувствительными к слабым помехам.

Если соблюдены технические условия эксплуатации, то перегрева просто быть не может. Ну и к помехам перегрев, опять же, никакого отношения не имеет.

б.) такая миниатюризация ведет к большой вероятности брака, в том числе и скрытым дефектам (триггеры срабатывают через раз).

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

Источники помех для сбоев:
1.) радиочастотный шум.

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

2.) радиация; хватает даже естественного фона, чтобы изредка ловить свой протон или нейтрон.

"Сказки Венского леса" - естественный радиационный фон не может повлять на работу микросхем.

3.) электростатические разряды, какая не была бы защита, в силу своих свойств (огромное напряжение, эффект солитона), они пробивают любую защиту; тока для повреждений хватает редко, зато для сбоя часто.

Результат неправильно спроектированной и эксплуатирующейся системы. В правильных устройствах электростатика исключена как явление.

Методы борьбы:
...

Комментировать некомпетентные высказывания дальше не вижу смысла.

Подытожу...
Ни одно из цифровых устройств не застраховано от сбоев. Часто, не часто, но они происходят. Поэтому все ОС и не только, имеют системы защиты и восстановления в таких ситуациях. На данный момент наиболее устойчивыми де факто являются Unix подобные системы.

Чистой воды домыслы автора. Сбои в правильно спроектированных системах не возможны в принципе. Аппаратные неисправности могут возникать и могут быть причиной сбоя, но связанны они с естественными причинами - нарушением условий эксплуатации. ОС не имеет и не может иметь "систему защиты от сбоев", поскольку место и причина возникновения сбоя неизвестны. Файловые системы, как наиболее уязвимое место ОС при сбоях, имеют защиту, но не от сбоев, а от повреждения данных при аварийном прерывании операции записи. В основном такие системы построены на так называемой транзакционной модели операций, каждая из которых по завершении должна быть подтверждена как валидная. Только в этом случае данные этой операции тоже становятся валидными с отметкой об этом в журнале операций. Иначе при следующем запуске по инвалидным операциям в журнале будет произведен откат на предидущее состояние данных. Повторяю - к операционной системе это не имеет отношения и является свойством файловой системы.

[Shviric]

На правах оффтопа:

Брак отсеивается еще на заводе и в продажу не поступает.

Еще как поступает... Жалко, не сохранились у меня рентгеновские снимки микросхем усилителя мощности. Это были микросборки с BGA-шкой внутри и несколькими дискретными компонентами, залитые каким-то резинообразным изолятором. Долго мы думали - то ли диагностик ленится правильно дебажить, то ли у ремонтника руки кривые, но после замены микросхемы телефон все равно не работал. До тех пор, пока не поленились внимательно просмотреть микрухи рентгеном и увидели, что под BGA-шкой внутри микросборки замыкания. Потом взяли непаянные микросхемы из упаковки - там то же самое.
Так что практика показывает, что от недобросовестных производителей (и слишком экономных менеджеров) никто не защищен.

[amito66]

...
1) Пользуя унифицированные комманды ата-стандарта попросту невозможно добраться до служебки. Для этого есть вендор-комманды, которые для каждого производителя (а вернее - для каждой группы близких семейств от одного производителя) свои.

Добавлю еще, что в обычном режиме работы на PATA/SATA-интерфейсе вендор-команды недоступны - для этого надо подключаться к винту последовательным портом, консолью к его внутренней ТОС (Technical Operating System). Делается это обычно через контакты перемычек выбора режима работы Master/Slave/CS

4) Винда при форматировании, если не ошибаюсь, проверяет только читабельность секторов, писать в них она не пробует. Остальные утилиты - тоже скорее всего.

Если не выбран режим быстрого форматирования, то каждый сектор проверяется на чтение-запись. В быстром режиме - только чтение и то выборочно, только место под журнал и корневой каталог.

ПЛМ сейчас используются только в прототипах или мелкосерийных девайсах. Это во-первых.

Не совсем так. Сейчас большинство чипов построено на базе БМК - базовых матричных кристаллов. Это своего рода ПЛМ, содержащая набор типовых узлов, соединения между которыми выполняется в процессе производства кристалла на специально выделенных для этого слоях-коммутаторах. Такой подход позволяет в разы сократить время и стоимость разработки СБИС.

Во-вторых - коррекция на аппаратном уровне есть далеко не везде. Скорее - ее практически нигде нет. Во всем вашем ПК коррекция будет только в кеше процессора.

И в кэше ее нет. Связанно это в первую очередь с тем, что любая аппаратная или программная коррекция ошибок (обычно говорят об исправлении одиночных и обнаружении двойных ошибок) может быть выполнена только на базе некоторого количества избыточной информации. Для памяти, например, это дополнительные биты, формирующиеся и затем проверяемые этой самой схемой коррекции ошибок. Наиболее серьезная такая система на основе кода Рида-Соломона применяется на CD/DVD-носителях и позволяет исправлять одиночные и обнаруживать двойные ошибки в байте. В старых стандартах на оперативную память использовалась более простая система - контроль четности. Она могла обнаруживать только одиночные ошибки, но не могла исправлять. В винчестерах применяют методы контрольных сумм. Для этого сектор винчестера делают больше 512 байт (обычно 640-648 байт) и в дополнительное место сектора записывается контрольная сумма по одному из алгоритмов хэширования типа CRC32/MD5 и т.д.. Эта контрольная сумма автоматически формируется контроллером винчестера (стоит на самом винчестере) при любом изменении данных в секторе. При чтении она считывается вместе с данными и позволяет обнаружывать практически все виды ошибок, но не исправлять их. Служебная часть сектора свыше 512 байт не доступна через пользовательский интерфейс.

+ ко всему - как вы представляете коррекцию ошибок, к примеру, при делении 2 чисел с плавающей запятой? Ставить 2 идентичных блока, и сравнивать результат? Не сильно ли жирно для ширпотреба?

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

[amito66]

coreboot - open-source. Что это такое - вам известно. И, удмаю, вам несложно догадаться, что как раз привязку к винту заложить - потребуются минимальные усилия. Эдак строк 20-30 кода, чтение паспорта винта, и halt в случае, если серийник не совпадает. А точнее - даже просто проверка паспорта в процедуре инициализации IDE/SATA и поиска накопителей

Сделать то можно все, что угодно, только вот наши военные не такие идиоты, чтобы такое делать. Информацию на винте это никак не защитит, а именно это самая большая головная боль.

Главное - обычный софт пользует только документированные ф-и. Следовательно, их можно эмулировать/переписать.

Все эти функции обычно сидят в таких DLL, как user32 или rundll. И как вы их будуте запускать в линуксе - совершенно непонятно. Именно интерфейс этих библиотек с ядром виндовс описан плохо и не полностью.

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

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

Фрагментация памяти была актуальна как раз при сегментной организации памяти. Для страничной организации - процессу глубоко все равно, как его страницы разбросаны в физическом адресном пространстве. Исключение - драйверы, работающие с DMA - но они себе блоки памяти заранее резервируют, да и не о них речь идет

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

Менеджер памяти помечает их в каталоге страниц как отсутствующие, и выгружает в своп. Что здесь такого секретного?

Ничего секретного нет. Только свопится начинает большая часть индексов с размерами в гигабайты. Отсуда и тормоза.

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

Потому что она принадлежит ядру и всегда актуальна.

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

Каким образом? У вас есть работающие способы, не требующие модернизации ядра?

Кстати, если же ось реализует страничный обмен через PAE - проблема со своппингом отпадает сама собой. Т.к. этим будет заниматься ядро.

А мне как раз не надо, чтобы ядро занималось свопингом.

Есть. Всевозможные девайсы с избыточностью, начиная от банальной ECC заканчивая мажоритарными схемами.

Это как же они так хитро сделаны, что относясь к железу, которое с ваших слов "любое может сбоить", не сбоят и более того им можно верить? Получается, что железо, которое может сбоить, защищает от сбоев железа, которое может сбоить. Полная чушь получается. Да?

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

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

Под контроллером страничной памяти я имел ввиду железку наподобие EMS, только несколько большего объема. Его в природе собссно не существует - амд досрочно 64бит х86-совместимую архитектуру сделала.

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

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

А потомучто я ни про какие другие "контроллеры страничной памяти" никогда не слышал.

Если же вас так смущает данное решение - есть и другое, кстати, воплощенное в железе: накопитель на RAM-плашках. На который выносится своп, причем - абсолютно прозрачно для оси.

Хорошее решение, согласен, но полное отсутствие свопа - еще лучше со всех сторон. Вот собственно на лучшем варианте мы и остановились.

Да ну? Позабыли серверные мамки на дуал пнях 1? Вроде как и 4-процессорные были...

В лучшем случае это были сервера для рабочих групп и они даже рядом не стояли с теми же санами серии Enterprise.

Примитивнейший пример - один сложный запрос к БД (к примеру, мускул сворачивается в трубочку, если сделать выборку с left join 3-4 таблиц, и указать несколько условий из разных таблиц).

А разве он однопоточный? Какой версии?

Значит, майкрософт только десктопные версии кастрировал таким странным образом?

Тоже не угадал. У меня рабочая машинка - XP на двух ядрах. 7Z ведет себя так же, как на сервере - сколько скажешь, столько ядер и использует. Причем грузит на 100%, если выполняется не в фоне.

[amito66]

На правах оффтопа:
Еще как поступает...
...
Так что практика показывает, что от недобросовестных производителей (и слишком экономных менеджеров) никто не защищен.

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

[Shviric]

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

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