На тему «utilizing cache coloring for cache partitioning» вроде нет ничего в вики? То, что есть в BSD и Виндах — это средство улучшения общей производительности работы с кэшем.
Отчего же, правильная критика. Единственно, насчет англицизмов — сложно поддержать баланс между НГМД и FDD :). Возможно, я считаю неправильно, что Last Level Cache звучит привычнее, чем «кэш последнего уровня»?
Который язык? Английский задолго до переезда в НЗ выучил, немецкий до сих пор практически не знаю. Про германию хочу написать топик на неделе в «я мигрирую»
В НЗ было хорошо. Но я переехал оттуда в Германию. 2 года, пока не жалею. С турками проблем не видел. Наоборот, за хорошей бараниной или быстро, дешево и вкусно пообедать в выходные еду в турецкий район.
Насчет «interrupt latency — вовсе не всегда самый важный, параметр.»
Мы смотрим с разных сторон — для меня это часто самый важный параметр, т.к. если есть проблема, клиент может выбрать не Intel железо. Поэтому если вдруг кто-то жалуется, что на платформе, которую я поддерживаю, возможно в каких-то условиях непредсказуемое увеличение interrupt latency, то моя самая срочная задача — найти причину и фикс.
Согласен с Вашим комментом: 1. определение realtime не имеет ничего общего с latency прерывания.
Специально в самом начале написал, что realtime — это «удовлетворение многим критериям». Если брать готовое приложение — то это в трех словах «гарантия времени реакции». 2. Есть много систем, где задержка прерывания в 100 микросекунд допустима.
Но пост о железе E-линейки Атомов, поэтому я взял самую первую latency, которая, если может иногда быть больше некоторого предела, гарантирует бесполезность платформы, вне зависимости от ОС и приложения. Пост был о том, как это измерять, и немного коснулся того, как с этим бороться.
В том-то и дело что _такой_ риалтайм себе для дома делать абсолютно незачем. Так что статья в чистом виде о бесполезном знании.
Если область любопытна, можно, например, скачать по ссылке из поста Twincat и сделать 2 вещи.
1. Измерить, можно ли использовать текущее железо, если вдруг найдется доступ к станкам. Если все ок, можно гордиться.
2. Попробовать написать и запустить какую-нибудь PLC программу, которая правда все равно ничего полезного делать не может, т.к. комп ни к чему не подключен.
Согласен с критикой, действительно очень редко пишу по-русски. Отсюда ошибки (что-то не так с пунктуацией? орфографию вроде-бы редактор проверил), и печатаю медленно. Единственный способ не разучиться — писать такие топики, наверное.
Было любопытно, интересно ли вообще кому-то читать про то, на сколько микросекунд может задержаться прерывание, чтобы станок не сломался, и как это измерить. Кто этим занимается — и так все знают, а большинству разработчиков, которые занимаются Веб, базами данных, эта информация бесполезна.
На каком таком уровне работает LSE? Я очень хорошо знаком с ребятами из той банды консультантов, что им настраивали Linux, чтобы пакетики быстрее двигались. Когда-то в одной команде работали.
Мои коллеги из МСФТ — хорошие спецы по своему софту, знают, как применять все документированные и большую часть недокументированных настроек. Но дело-то не в настройках. Они не могут сделать специальный билд виндов для LSE.
Главное в выборе ОС — ядро и ключевые драйверы можно переписывать. Специально нанятые консультанты и свои специалисты занимались этим больше года. Нанять linux kernel hacker несложно. А МС, даже если отдала бы им исходинки, где им найти специалистов по ядру Виндов? Хантить из Редмонда?
Консультанты по оптимизации и измерению network latency тоже есть. Я участвовал в паре таких проектов в Лондоне как раз 3 года назад. Не представляю, что бы я мог порекомендовать тогда заказчику, если использовалась бы windows? «Извините, пакетик проводит 8 микросекунд где-то в недрах Виндов, но почему и что с этим делать никто кроме МСФТ понять не в состоянии.»
Я полтора года измерял с микросекундометром подобные системы. Там часто более 1 компа, и обычный ethernet, tcp/ip. (хотя бывает и infiniband, и ip offload).
Если в этом конкретном случае там ethernet/ip, то 5-10 микросекунд пакетик проведет в ОС, на каждой из машин, его обрабатывающих. * кол-во машин (например, 4) — получится уже до 40 мсек из 90 пакетик обрабатывается потрохами линукса. Остальное время легко съедят очереди в user mode.
Если еще подробнее о технической части (в маркетинговоя я не эксперт, просто рядом стою), то мы помогаем партнерам — производителям ПО быстрее начинать использовать в своих продуктах новые возможности новых платформ — типа новой платформы CE4100 или новых инструкций AES-NI, AVX, и много менее известных технологий.
Я знаю больше 3 людей, работавших и в Интел, и в Мере и в Тельме. Еще больше знакомых работало в Тельме или Мере и в Интел. Я сам работал в Мере и потом в Нижегородском Интел до 2004 года.
Действительно, сотрудники Интел редко рассказывают о том, как все устроено внутри компании. И еще реже делают это онлайн. Но если Вы Нижегородец, то должны же быть общие знакомые с хотя бы одним программистом из Интел, или хотя бы бывшим сотрудником? Например, у меня только из потока на РФ человек 10 есть.
Вот я занимаюсь этим самым развитием экосистемы. (Раньше — в России, теперь в зап Европе). Если перевести на нормальный язык — это техн. и маркетинговое сотрудничество с основными производителями ПО. Ничего общего с «нафига попу баян».
Мы смотрим с разных сторон — для меня это часто самый важный параметр, т.к. если есть проблема, клиент может выбрать не Intel железо. Поэтому если вдруг кто-то жалуется, что на платформе, которую я поддерживаю, возможно в каких-то условиях непредсказуемое увеличение interrupt latency, то моя самая срочная задача — найти причину и фикс.
Согласен с Вашим комментом: 1. определение realtime не имеет ничего общего с latency прерывания.
Специально в самом начале написал, что realtime — это «удовлетворение многим критериям». Если брать готовое приложение — то это в трех словах «гарантия времени реакции». 2. Есть много систем, где задержка прерывания в 100 микросекунд допустима.
Но пост о железе E-линейки Атомов, поэтому я взял самую первую latency, которая, если может иногда быть больше некоторого предела, гарантирует бесполезность платформы, вне зависимости от ОС и приложения. Пост был о том, как это измерять, и немного коснулся того, как с этим бороться.
Если область любопытна, можно, например, скачать по ссылке из поста Twincat и сделать 2 вещи.
1. Измерить, можно ли использовать текущее железо, если вдруг найдется доступ к станкам. Если все ок, можно гордиться.
2. Попробовать написать и запустить какую-нибудь PLC программу, которая правда все равно ничего полезного делать не может, т.к. комп ни к чему не подключен.
Было любопытно, интересно ли вообще кому-то читать про то, на сколько микросекунд может задержаться прерывание, чтобы станок не сломался, и как это измерить. Кто этим занимается — и так все знают, а большинству разработчиков, которые занимаются Веб, базами данных, эта информация бесполезна.
Мои коллеги из МСФТ — хорошие спецы по своему софту, знают, как применять все документированные и большую часть недокументированных настроек. Но дело-то не в настройках. Они не могут сделать специальный билд виндов для LSE.
Консультанты по оптимизации и измерению network latency тоже есть. Я участвовал в паре таких проектов в Лондоне как раз 3 года назад. Не представляю, что бы я мог порекомендовать тогда заказчику, если использовалась бы windows? «Извините, пакетик проводит 8 микросекунд где-то в недрах Виндов, но почему и что с этим делать никто кроме МСФТ понять не в состоянии.»
Если в этом конкретном случае там ethernet/ip, то 5-10 микросекунд пакетик проведет в ОС, на каждой из машин, его обрабатывающих. * кол-во машин (например, 4) — получится уже до 40 мсек из 90 пакетик обрабатывается потрохами линукса. Остальное время легко съедят очереди в user mode.
Действительно, сотрудники Интел редко рассказывают о том, как все устроено внутри компании. И еще реже делают это онлайн. Но если Вы Нижегородец, то должны же быть общие знакомые с хотя бы одним программистом из Интел, или хотя бы бывшим сотрудником? Например, у меня только из потока на РФ человек 10 есть.