Re: Есть ли принципиальная разница в работе disk on chip и disk on module?

Кстати в контролере используем FRAM - так вот по ней указано 10 в 13 степене циклов т.е. вечная.
А собираемся перейти на nvSRAM там вообще храктеристики супер - говорят что за ней будущее.

кешированием не утомляет, скорее наоборот, по-моему... А вообще, кто мешает его отключить?

Главное, чтоб свопа она на флешке не устраивала...

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

FRAM тоже используем, и вечная, и шустрая... А привесили бы ишшо одну FRAMину IICшную для истории игр - и не парились бы уже :)

А nvSRAM это что? ??? Она без батарейки?

nvSRAM: http://www.premier-electric.com/briefs/ ... 2c707.html

по довеске eще FRAM впринципе так и собираемся сделать, но пока руки не дошли (необходимо много что переделать).

Андрей, вопрос: что ты понимаешь под кешированием и свопированием?

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

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

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

Ладно, Андрей, не вникая в подробности что такое кеширование и свопирование (понятно что это какая-то работа с памятью), как думаешь все действия стандартной ХР Винды сильно утомляют флешку?

И второе, запись истории одной игры можно оценивать как то что флешки осталось жить 1 000 000 - 1 записей?

1) В принципе - на мой взгляд - все же многовато она пишет: даже если отключить виртуалку (ну это-то обязательно надо) - еще лог-файлы, например... Реестр подправляет периодически (а его потеря - винде капут!). Наверное, embed в этом плане гораздо легче, если ее правильно сконфигурить (правда, я с ней практически незнаком).

2) А как ты их пишешь? В один большой файл? тогда наверное не всей флешке, а тем блокам, что занимает этот файл, осталось жить на запись меньше. Но вот что получается, допустим, файл с историей игр у тебя 100 КБ, а свободного места 5 МБ, тогда даже если умрут все блоки, использованные в этом файле, пусть, например, за 100000 записей (наихудший вариант) - для системы это фиолетово, она по мере их умирания будет использовать новые... И при таком раскладе оно проработает (опять же, при наихудшем прогнозе) 5 миллионов игр... Реальная цифра, наверное, раз в минимум 10 больше...

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

toweroff писал(а): Все проги можно писать под виндами, а потом просто компилить в линух...

Виндовский ехе в Linux?
Можешь подсказать как?

Используем DireсtХ.

Нуу... exe под линухом - это круто :)
Вообще я не программер под подобные оси, но мои ребята сразу писали код под обе платформы - Вин и Линукс. Потом все это дело компилилось. Естесственно, под виндами - для винды, под линухом - для линуха. Некоторые особенности писались отдельными кусками под линух, отдельными - под винду. При сборке компилятор определял операционку и вставлял нужный для этой оси кусок

А я уже было подумал, что нашлись умельцы виндовский ехе в линух обращать :o

Ну под мышевоза писать таки легче :)

Особливо графику...

Особливо тем, кто, как я, унихов не знает :D

А кстати есть оболочки (не помню названия) которые, позволяют виндовские игрухи запускать по линуксом. Умельцы запускали известные игрушки (Doom и прочее). Мы как то попробывали, но быстро не получилось и не стали заморачиваться тем более были опасения, что даже если получится то может коряво работать.

Есть такой вечно почти готовый Wine, эмуль винды для линуха... Еще чего-то есть... Работает все исключительно коряво :)

А дум, кстати, скомпилированный спецом для линкуса есть, и квейк, и еще чего-то...

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

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

А что касаемо библиотек графических под линух - вроде тот же чел говорил, что они гораздо лучше оптимизированы, чем виндовые.

Надо посмотреть, сколько он наконфигурил ядра под линух со всеми причудами, но вроде как было что-то мегов 50, т.е. все остальное можно отдавать под игру (мы использовали 256Мб CF). При этом все данные хранились в NV-SRAM, а разделы еще шифровались и были Read-Only.

Да, забыл сказать - платформа Heber AXIS

2 Yaleks:

С технической точки зрения на флешку может плохо влиять только swap Винды, хотя это не аксиома. Плохо влиять в данном случае - это укорачивать срок ее жизни.
Кэширование наоборот продлевает срок, т.к. все данные по открытым HANDLE'ам файлов в стандартном режиме физически записываются реже, накапливаясь в оперативке и сбрасываясь в запись только при плановом задании самой системы.
Другими словами, ты можешь вызвать уже 15 ф-ий записи, а Винда исполнит их общим скопом когда ей будет удобно, при этом перезаписанные тобой данные физически запишутся всего один раз.

НО здесь есть подводный камень. При внезапном сбое питания еще не записанные данные будут потеряны, т.к. плановая запись Винды может отложиться и на 5-10 сек (личный опыт), а то и более.
Есть 3 выхода из этой ситуации: Либо открывать файлы с флагом FILE_FLAG_NO_BUFFERING, либо после критически важной записи делать FlushFileBuffers(HANDLE HFile), или же получать прямой доступ к файлу, но тогда придется оперировать адресами и блоками данных строго кратными размеру сектора.

Что касается применения Винды в игровых решениях, то имхо - это только Win XPE. При грамотном сборе системы и не менее грамонтных настройках Винда вообще не будет сама ничего изменять: не будет ни своппинга, ни кэширования, ни правки реестра, ни логов, одним словом НИЧЕГО, пока ты сам этого не захочешь. При этом образ такой системы, достаточный для выполнения DirectX приложений, будет занимать места от 50 до 100 Мб (при правильном подходе разумеется).

По использованию DOM Flash могу сказать следующее: за все время эксплуатации не выявлено ни одного сбоя связанного с перезаписью. При тестировании записи истории игр в кольцевом режиме объемом 500 000 игр, 100 полных проходов кольца проходят без единой ошибки. Если перевести в твои абсолютные величины, то получается что история одной игры записалась 50 000 000 раз.

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

Спасибо за интересную информацию.

Очень заинтресовало вот это:

Microbyte писал(а): 2 Yaleks:

Что касается применения Винды в игровых решениях, то имхо - это только Win XPE. При грамотном сборе системы и не менее грамонтных настройках Винда вообще не будет сама ничего изменять: не будет ни своппинга, ни кэширования, ни правки реестра, ни логов, одним словом НИЧЕГО, пока ты сам этого не захочешь. При этом образ такой системы, достаточный для выполнения DirectX приложений, будет занимать места от 50 до 100 Мб (при правильном подходе разумеется).

Мне кажется с 50-100мБ ты загнул, потому как я был бы счастлив если бы со всеми достоинствами, которые ты описал (нет свопинга, кеширования и прочего) получить даже 500мБ.

Сейчас используем Ембедед и то получаем больше 500.

Если есть возможность и желание то поделись этими настройками и урезаниями по стандартному ХР (кстати вопрос Home или Prof разница для этого есть) - буду очень благодарен. Если есть какой-то подробный пошаговый шаблон-инструкция вышли мне: yaleks-23@yandex.ru. То, что я находил в и-нете, не особо урезают Винду и не дают тех настроек которые ты описал.

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

А насчет 500 мБ - это ж обычную pro так можно почистить, что она меньше займет ;D - есть же какие-то товарищи которые ее в 300 с чем-то запихивают... Причем вполне официально, они от майкрософта какой-то статус имеют...

Мне кажется, 100 мБ - близкая к реальности цифра

AR_Favorit писал(а): Если есть какая-то инфа по embed - то и меня она тож интересует, у меня есть толька триальный диск с ней от майкрософта, и времени особо на поиск инфы нету, а интересно было бы поэкспериментировать...

А насчет 500 мБ - это ж обычную pro так можно почистить, что она меньше займет ;D - есть же какие-то товарищи которые ее в 300 с чем-то запихивают... Причем вполне официально, они от майкрософта какой-то статус имеют...

Мне кажется, 100 мБ - близкая к реальности цифра

Сколько не чистили - не получается меньше 500 + еще и файл подкачки (мин.200) без которого прога через некоторое время начинает писать "не хватает виртуальной памяти" и необходимо перезагружать. Поэтому если есть спецы, готовые поделится правильными настройками и урезками, то буду благодарен.
На счет Ембедеда, дело достаточно геморойное.Есть сайт Кварта технологии там по Ембедеду все, включая он-лайн форум консультацию. Сами ковыряли полгода пока научились новый образ за неделю клепать. Но мы все-таки не смогли сделать его абсолютно правильно - все равно некоторые методы приходится до сих пор решать по своему, а не так как хотелось бы. Поэтому и возник вопрос, что если мы (пока во всяком случае) не смогли вытянуть его премущества, а стандартный ХР можно привести к нормальному объему и плюс с теми характеристиками, что описал Микробайт, то есть смысл не заморачиваться на Ембедеде.

Цифры реальные. У меня полностью рабочий развернутый образ занимает 94Мб, если же его делать в сжатом виде, то 68Мб. Плюс, если удалить еще заведомо не нужные компоненты, то приходим к 50, только вот при этом удалении Сборщик ругается, т.к. есть множество зависимостей. Однако, ими можно пренебречь, если уверен, что конкретные модули не понадобятся, и строить образ, игнорируя ошибки. Практика показала, что даже такой образ оказывается вполне рабочим, но от греха подальше мы build'им все таки без ошибок, да и 94Мб для нас вполне разумный результат. Если нет необходимости делать меньше, тогда зачем извращаться.

Не понял на счет Home и Prof: XPE - он один, нет разновидностей. Есть только триал и оригинал.

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

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

Общие рекомендации, наверное выглядят так:

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

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

2а. Можно вместо п.2 сгенерировать .pmq файл на целевой платформе, предварительно поставив там обычный XP. Но как показала моя практика, образ из этого файла не всегда получается полностью работоспособным, а также имеет бОльший размер.

3. Имея отправную точку в виде образа, полученного из п.2 (или 2а), можно приступать к операции урезания. Для начала это можно делать отдаленно понимая смысл тех или иных компонентов, руководствуясь методом тыка. Другими словами: удалили; проверили; работает - идем дальше, не работает - возвращаем назад и запоминаем, что этот компонент жизненно важен (лучше записывать, т.к. через некоторое время будет тяжело оперировать в мозгу сотнями компонентов). А вот для высшего пилотажа уже потребуется знание п.1, свободное чтение английского, а также умение обращаться с help'ом.

... Пока писал, появился еще один пост от Yaleksa.
Отступление:
а) Файл подкачки в любом случае надо отключать! Если у тебя он растет с течением деятельности твоего приложения (игры) - ищи утечки памяти в своих исходниках. Другой причины быть не может! Плюс ко всему, если ты оставишь файл подкачки, а от утечек не избавишься, то файл подкачки займет все отведенное ему место, а после этого вылезет та же ошибка. А теперь представь, если это произойдет через месяц/два/год непрерывной работы игры в зале, а ты продал уже несколько сотен/тысяч таких игр... Отзывать все назад - мало приятного, если не сказать больше.

б) Заморачиваться на XPE надо, т.к. некоторые из возможностей, которые я привел, невозможно реализовать в обычной XP.
Конец отступления.

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

2 Yaleks & AR_F: Без проблем подскажу/посоветую по данным вопросам, если это будет в моей компитенции.

Microbyte писал(а):
Не понял на счет Home и Prof: XPE - он один, нет разновидностей. Есть только триал и оригинал.

)))
Я почему то не обратил внимание на букву "Е" (ХРЕ) в твоем первом сообщении и поэтому посчитал, что ты говоришь о стандартном ХР. Оттуда все удивления и вопросы возникли. А с Ембедедом мы работаем. Очень много заморочек и пока основного результата (минимизация и защищенность) в полной мере не достигли поэтому и заинтересовало, то что кто-то этого достигает на стандартном ХР. )))

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

IMHO:Решения лучше, чем XPE, при использовании win32 приложения, на сегодняшний день не существует.

2 Yaleks:
И все таки обрати внимание на память. Нехватка виртуальной памяти - это опасное явление. Либо ты пытаешься подгрузить в память больше данных, чем объем физической оперативной памяти, что и заставляет Винду сбрасывать страницы в page-file (что не есть хорошо). Либо действительно есть утечки, а это Очень не хорошо.

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

Утечки - тоже весьма вероятное явление, причем в исходном коде их еще и не всегда увидишь. Среда разработки и компиляторы - тоже... далеко не идеальные... Можно попытаться вякими штуками типа Bounds Checker-а посмотреть, но и это не гарантирует победы...

Андрей, я немного не об этом.
Конечно Винде без разницы что сбрасывать в файл подкачки.
В данном случае речь идет о его необходимости. Т.е. у Yaleksa получается, что без включения файла подкачки программа Yaleksa (именно) вызывает нехватку памяти. И вот это может быть следствием нехватки физической памяти, т.к. при включенной "подкачке", когда Винде не хватает физической памяти, она принудительно отправляет данные в своп, а когда свопник запрещен - ей ничего не остается делать, как выдать exception: overflow.

А утечки есть практически везде, но критичные, как правило являются следствием недоработок программиста (тем более в случае с DirectX, там очень много подводных камней). А утечки компилятора не так велики, по сравнению с тем, что может быть, допустим, при пропуске программистом удаления временно подгружаемой картинки размером так с 600кб.

Кстати, а сколько оперативки-то в наличии?
Если 256 - то чтоб упираться в нехватку памяти при отсутствии свопа - не очень и громоздкая прога нужна (если не поотключать масу ненужных процесов) :)

Добрый день, коллеги.
Мы (Avnet Silica) являемся embedded-дистрибьютерами Microsoft в России/Беларуси/Украине. Работаем на этом рынке с 2001 года.
Как уже сказал Microbyte - заморачиваться с XP Embedded стоит.
Могу предоставить бесплатно демо-версии (полнофункциональные, ограничение 120 дней на время жизни образа) + MSDN курсы для разработчиков и прочую полезную информацию. Также до конца апреля у нас акция по средствам разработки для CE и XP Embedded - звоните.

Касательно flash SSD накопителей - Intel начал производство SSD Intel® Z-U130 Value Solid State Drive
http://www.intel.com/design/flash/nand/z-u130.htm
http://www.3dnews.ru/news/intel_vihodit ... ei-192156/
Вешаются на внутренний USB-разъем, уже доступны объемом 1/4 Гб
Цена на 1 Гб ~20-22$ в Москве. Неплохой вариант для XP Embedded и вообще для любого встраиваемого приложения.

Пишите в личку или на silica.russia@avnet.com
+7 (495) 937 21 65
+7 (495) 937 12 68

PS: просьба как спам не убивать и в куплю-продажу пока не переносить, полагаю это кого-либо заинтересует.