в 2Т когда никакого ETEC у ротакса в проекте не было - эта схема была реализована в 2000-м году на той же априлии SR50 и пигаро "не помню что" (digitech).
DITECH если уж быть точнее. Но это не совсем ЕТЕК - на Aprilla SR50 впрыскивалась если не ошибаюсь уже готовая топливная смесь (воздух + топливо), причем воздух был сжат компрессором до 5 bar.
Настраивать на нюх собрались или методом тыка? Продувка без проблем учитывается.
Настройка двигателя по широкополосной лямбде это одно (тут уж проще действительно по нюху газоаналиатора настраивать). В готовых снегоходах с 2Т движками не видел лямбд (тем более ставить дорогие ШП лямбды туда никто не будет - мрут как мухи от масла) - датчики EGT там обычно ставят.
На двигателях с числом цилиндров меньше тактовости никакого основного управления по мапсенсору нет и быть не может!
В реальном мире 2.5mips хватает чтоб управлять двигателями 6 цилиндров, 1050 сил, на 9000 оборотах, если отсутствие быстродействия и мощности компенсировать отсутствием 3-х делений в атомарной функции линейной интерполяции в трехмерных картах - т.е. архитектурой ПО.
Для 2Т все сильно веселее, там диапазон времени работы инжектора сильно, меньше. 8000-9000 оборотов для 2Т (типичные обороты 2Т), с точки времени на впрыск, на "зарядки" свечи - сильно, сильно меньше. Ключевое слово здесь 2Т, и 9000 обортов двухтактного двигателя превращаются, с точки зрения времени в 18000 оборотов 4Т. На 9000 оборотах у 2Т двигателя один цикл проходит за 6 миллисекунд, и технически время впрыска не может быть больше полутакта. А 3ms это как то вообще уже не сильно много если учитывать что время полного открытия некоторых форсунок доходит до 1ms. Я уж не говорю о таких вещах как непосредственный впрыск в камеру сгорания на 2Т двигителях (Rotax ETEK) - там вообще все в микросекундах измеряется. И самым главным измерением - сюрприз - становится измерение напряжения в бортовой цепи питающей форсунки и катушки зажигания.
Даже в моменте точность определяется тем, как точно лямбда может померить смесь и как точно на стенде можно попасть в УОЗ. Так вот точность даже в 2 градуса по углу и 2% по смеси недостижима для любого доступного стенда и любой доступной лямбды соответственно.
В 2Т двигателях применение лямбды тупо бессмысленно. Основное управление идет по MAP сенсору и датчику детонации.
Я вот тоже слежу за работой ребят - на самом деле открытый ECU интересен в первую очередь совсем не для серийных автомобилей. Там уже полно умельцев которые поправят прошивку под авто. Другое дело - есть движки, в которых быстродействие и мощь проца в rusEFI может быть весьма полезным. Как вариант - это оффроад техника - квадроциклы и снегоходы. Особенно интересны снегоходы с двухтактными двигателями, это та область где сделать и отладить прошивку, крайне - крайне сложно и быстродействие системы и точность расчетов одни из важнейших факторов.
В начале это вообще был не DB2 — а SQL/DS — который работал на VSE и VM. потом уже появилась DB2 for MVS. А еще раньше был System R. Потом написали DB2 под полуось — в принципе ее можно считать за прародительницу DB2 LUW. В какой то момент было 4 кодовых базы DB2. А потом был проект StarBurst — это оптимизирующий компилятор SQL (по сути половина базы данных) — его впилили во все платформы и как мне помнится он был написан на С.
Чистый С. было очень заметно как имена функций были ограничены 8-ю символами в верхнем регистре и соответствовали именам в LOAD модулях от фреймовых библиотек
центральная часть МФ — db2/zOS, который не развивается, а лишь с опозданием адаптирует фишки из LUW редакции.
Как человек видевший DB2 LUW изнутри, я бы сказал что все несколько иначе :-) DB2 LUW — это наследие от DB2 z/OS — там большая часть кодовой базы от фрейма. тот же протокол DRDA для соединения с DB2 работает в кодировке EBCDIC (которая pure mainframe )
Про HADOOP спорить не буду — все это вкусовщина, но скажу что in memory DB — как то не очень верится что хорошо работают с базами данных с размерами в петабайты (а довелось видеть и такие)
Статья действительно сильно поверхностная, но и рассказывать про фреймы можно до ужаса долго. Но и с утверждением о том, что мейнфрейм догоняет современные технологии вообще не соглашусь — все как раз наоборот. К примеру технологии виртуализации сначала появились на нем, а потом уже "перетекли" на другие платформы (та же z/VM). Еще в начале нулевых под z/VM делал подобие докера — (когда технологий контейнеров еще даже в планах не было). Еще тогда можно было под z/VM загрузить и стартовать ядро Linux в разделяемый сегмент памяти, "заморозить" его и грузить еще +100500 линуксов с этого сегмента разделяемой памяти.
А фреймы по сути нужны там где ну очень сильные требования к ввод-выводу — тут их архитектура рулит ( у фреймов канальная архитектура, в отличии от условно шинной в x86).
В текущем поколении (z/14) bandwidth одного чипа с с центральными процессорами составляет 2.4TB/s — память 1.6ТB/s. Уровней кэша в фреймах 4 штуки. L1-128КB, L2-4MB, L3-128MB, L4-672MB. А отказоустойчивость достигается как в космических аппаратах — дублированием всего и всея. Например в каждом ядре каждая инструкция параллельно выполняется на 2-х блоках и результаты сравниваются — если есть различие процессор помечается сбойным и инструкция уезжает работать на "запасной" процессор (на одной подложке их несколько — и один как минимум всегда в резерве ).
Ну нее, в материнские платы включать мониторы, даже начальные так себе идея. Лучше купить внешнюю карту — достаточно не очень дорогую. У меня есть FireWire Solo (но уже не используется — спасибо M-Audio за то что загубили драйвера под MacOS) и текущая Scarlet Focusrite 2x4 — так те же KRK подключаются балансным входом к балансному выходу карты — разница в звуке есть очень ощутимая.
Что то больше похоже на обзор того что есть на складе магазина. А начальных мониторов есть вагон и маленькая тележка. Как минимум
M-Audio BX8 D3
KRK Rokit 5 G4. (8-ки уже подороже)
У самого были эти две модели — от BX8 пришлось отказаться из-за того что на столе не помещались. А вот KRK очень понравились за свои деньги, на них даже сводить вполне возможно.
Расслабьтесь, это вообще мировая тенденция, Россия здесь вообще не уникальна. Работая в большом международном корпе с распределенными командами, я вижу как это происходит в рамках всего мира. Как, например несколько сеньоров например из Европы, заменяются толпой индусов, а через несколько лет толпа индусов заменяется на еще большую толпу мексиканцев и качество дальше падает еще катастрофически (хотя для такой работы хватило бы и 2-х сеньоров). С моей точки зрения, я вижу множество факторов, которые приводят к этому. Высокая стоимость (и зачастую весьма обоснованная) действительно толковых специалистов и короткий цикл жизни софта и как следствие необходимость писать код быстро и быстро выкатывать в прод, что бы через полгода-год, сказать это что сделали все фигня и надо быстро запилить новую систему вместо старой (много ли сейчас приложений или систем с жизненным циклом лет в 10 хотя бы ?). Как следствие, с точки зрения бизнеса — толпа вайтишников выгоднее, чем команда профи в краткосрочной перспективе. Как минимум с точки зрения устойчивости проектов, тупо если из команды в 20 вайтишников уйдет 3-5 сотрудников, это даже не сильно заметно будет (да и заменить не сложно) — то из условно равноценной команды профи-сеньоров в 4 человека — потеря даже одного — уже критическая ситуация для проекта. С обратной стороны — текучка кадров вайтишников — это другая сторона попаболи менеджера проекта. У тех же индусов в среднем attrition rate (текучка кадров) в среднем идет от 15-20% в год (тупо из 5 пришедших — один уйдет в течении года), а у тех же мексиканцев доходит и до 50%? И как работать с такими вайтишникаим, если learning curve (время на обучение что бы понять все внутренности проекта) в твоем проекте порядка 18 месяцев и к моменту окончания числа обучения нужно начинать все по новой, поскольку первые пришедшие в проект уже ушли ?
Tiger Lake в Mac еще нет, я сравнивал с текущим доступным и это пока что максимум UHD 630 — и по сравнению с ними M1 GPU выглядит очень солидно. Ведь те машинки Air и Про 13" всегда шли на встроенной графике. Для старших же моделей — вероятно Apple выкатит что то иное в следующем году или подключит ту же дискретную графику.
Процессор получился довольно интересный, как по мне. Более того для тех машинок MB Air, MBPro 13 — получилось неплохое комбо со встроенной графикой — тут Интел отдыхает
В OpenCL результаты соответствуют больше дискретной графике, нежели встройке.
Apple Silicon выдает 18656 попугаев Apple M1 GPU
На моем MacBook Pro 16"
Это опять смотря что запущено из приложений и какой у вас Мас (со встроенной графикой только, или встройка + дискретная). Обычно 8 гиг это на модельках с интегрированной графикой, которая тоже потребляет обычную RAM под видеопамять (Intel UHD Graphics 630 — VRAM (динамическая, макс.): 1536 МБ). Так что кто то запустит Докер на 8гигах и оно будет работать, а кто то запустит Фотошоп с большим файлом и кучей слоев и ему не хватит памяти, поскольку память подъели как и сами приложения, так и видеодрайвер встроенной графики.
Sonoff у меня все прошиты Tasmota, это да. Но засовывать в них автоматизацию мне кажется не совсем корректно — всё-таки удобнее когда управление всей автоматизацией происходит из 1 места.
Тут на вкус и цвет — все фломастеры одинаковые. Но распределенная система более устойчива чем централизованная. Не будут же домашние ждать света в туалете, пока вы версию Domoticz обновлять будете? Для мелких автоматизаций — встроеные правила самое оно.
У меня вопрос, вы говорите о подсветке дорожек в саду — у вас сонофы стоят на улице? Как они работают зимой?
Прекрасно работают — когда упакованы IP65 защитные коробочки — уже несколько лет полет нормальный. Возможно у вас влажность была повышенная и контакты в реле подмерзли, может что другое. Чипу ESP в принципе -10 не страшны, вот влажность или конденсат не приветствуются — поэтому хорошие герметичные установочные коробки — must have.
Apple TV и Яндекс.Станцию мне подарили коллеги, за что им огромное спасибо. В принципе, у меня всё работает и без них, но станция добавила мне в дом возможность голосового управления, а Apple TV является удобным шлюзом для Apple Home.
В Home Assistant уже встроен Apple Homebridge, так что все выключатели, сенсоры и прочее видны в HomeKit автоматом. Большим плюсом — это возможность создавать виртуальные устройства которые также будут видны в Apple Home — например у меня создана виртуальная сигнализация с кейпадом которая отрабатывает все датчики (окон, дверей, PIR датчики присутствия и ONVIF камеры наблюдения).
Так же из ИМХО важного, что в принципе нужно любому умнодомостроителю (а мы говорим о доме, а не о квартире) — это все устройства типа Sonoff перевести на альтернативную прошивку (в моем случае Tasmota). Плюсов там миллион — можно подключать дополнительные датчики прям к простым реле (например ставить DS18B20 в простой модуль Sonoff Basic), а также использовать микроавтоматизацию на уровне самого устройства Sonoff (c Tasmota смотри раздел Rules) без необходимости дергать Domoticz или Home Assistant. Например у меня подсветка дорожек в саду включается от датчиков движения, только тогда когда село солнце.
Пример из Rule Cookbook
ON Time#Initialized DO Backlog event checksunrise=%time%; event checksunset=%time% ENDON
ON event#checksunset>%sunset% DO Power1 1 ENDON
ON event#checksunrise<%sunrise% DO Power1 1 ENDON
Датчики движения, открытия окон и дверей, задымления и пр. — все работают на стандартных 433Mhz — прекрасная и надежная система для частного дома (дальность работы до 100м). К ним покупается Sonoff RF шлюз — и все прекрасно заводится в Home Assistant. И таки да — проводов не надо — батарейки рулят — мне в среднем хватает батарейки в датчиках на 2 года.
Baxi более или менее в адеквате :-). Не без закидонов, конечно — там нужно волшебную последовательность команд давать что бы он переходил в режим управления (иначе он работает только в режиме монитора — смотреть можно, менять ни-ни). У Бошей свои приколы — регулирует температуру по ОТ только в пределах которые сначала ручками установил на котле и т.д. и т.п. Вообще есть табличка кто что может Табличка поддержки OT по котлам
Да, ECO-4s поддерживает opentherm, даже платы адаптера вроде как не требуется на котел (на мой Slim пришлось докупать). Если не охота махать паяльником — то есть вообще готовые решение типа ZONT от микролайна (но мне они не нравятся из-за невозможности работать локально — все API через сервера микролайн)
DITECH если уж быть точнее. Но это не совсем ЕТЕК - на Aprilla SR50 впрыскивалась если не ошибаюсь уже готовая топливная смесь (воздух + топливо), причем воздух был сжат компрессором до 5 bar.
Настройка двигателя по широкополосной лямбде это одно (тут уж проще действительно по нюху газоаналиатора настраивать). В готовых снегоходах с 2Т движками не видел лямбд (тем более ставить дорогие ШП лямбды туда никто не будет - мрут как мухи от масла) - датчики EGT там обычно ставят.
На снегоходах обычно идет минимум 2 цилиндра.
Для 2Т все сильно веселее, там диапазон времени работы инжектора сильно, меньше. 8000-9000 оборотов для 2Т (типичные обороты 2Т), с точки времени на впрыск, на "зарядки" свечи - сильно, сильно меньше. Ключевое слово здесь 2Т, и 9000 обортов двухтактного двигателя превращаются, с точки зрения времени в 18000 оборотов 4Т. На 9000 оборотах у 2Т двигателя один цикл проходит за 6 миллисекунд, и технически время впрыска не может быть больше полутакта. А 3ms это как то вообще уже не сильно много если учитывать что время полного открытия некоторых форсунок доходит до 1ms. Я уж не говорю о таких вещах как непосредственный впрыск в камеру сгорания на 2Т двигителях (Rotax ETEK) - там вообще все в микросекундах измеряется. И самым главным измерением - сюрприз - становится измерение напряжения в бортовой цепи питающей форсунки и катушки зажигания.
В 2Т двигателях применение лямбды тупо бессмысленно. Основное управление идет по MAP сенсору и датчику детонации.
Я вот тоже слежу за работой ребят - на самом деле открытый ECU интересен в первую очередь совсем не для серийных автомобилей. Там уже полно умельцев которые поправят прошивку под авто. Другое дело - есть движки, в которых быстродействие и мощь проца в rusEFI может быть весьма полезным. Как вариант - это оффроад техника - квадроциклы и снегоходы. Особенно интересны снегоходы с двухтактными двигателями, это та область где сделать и отладить прошивку, крайне - крайне сложно и быстродействие системы и точность расчетов одни из важнейших факторов.
Там смесь, и что было вперед а что после — уже не разобраться. Могу сказать, что части кода от MVS есть в LUW — тоже самый DRDA протокол.
В начале это вообще был не DB2 — а SQL/DS — который работал на VSE и VM. потом уже появилась DB2 for MVS. А еще раньше был System R. Потом написали DB2 под полуось — в принципе ее можно считать за прародительницу DB2 LUW. В какой то момент было 4 кодовых базы DB2. А потом был проект StarBurst — это оптимизирующий компилятор SQL (по сути половина базы данных) — его впилили во все платформы и как мне помнится он был написан на С.
Чистый С. было очень заметно как имена функций были ограничены 8-ю символами в верхнем регистре и соответствовали именам в LOAD модулях от фреймовых библиотек
Как человек видевший DB2 LUW изнутри, я бы сказал что все несколько иначе :-) DB2 LUW — это наследие от DB2 z/OS — там большая часть кодовой базы от фрейма. тот же протокол DRDA для соединения с DB2 работает в кодировке EBCDIC (которая pure mainframe )
Про HADOOP спорить не буду — все это вкусовщина, но скажу что in memory DB — как то не очень верится что хорошо работают с базами данных с размерами в петабайты (а довелось видеть и такие)
Статья действительно сильно поверхностная, но и рассказывать про фреймы можно до ужаса долго. Но и с утверждением о том, что мейнфрейм догоняет современные технологии вообще не соглашусь — все как раз наоборот. К примеру технологии виртуализации сначала появились на нем, а потом уже "перетекли" на другие платформы (та же z/VM). Еще в начале нулевых под z/VM делал подобие докера — (когда технологий контейнеров еще даже в планах не было). Еще тогда можно было под z/VM загрузить и стартовать ядро Linux в разделяемый сегмент памяти, "заморозить" его и грузить еще +100500 линуксов с этого сегмента разделяемой памяти.
А фреймы по сути нужны там где ну очень сильные требования к ввод-выводу — тут их архитектура рулит ( у фреймов канальная архитектура, в отличии от условно шинной в x86).
В текущем поколении (z/14) bandwidth одного чипа с с центральными процессорами составляет 2.4TB/s — память 1.6ТB/s. Уровней кэша в фреймах 4 штуки. L1-128КB, L2-4MB, L3-128MB, L4-672MB. А отказоустойчивость достигается как в космических аппаратах — дублированием всего и всея. Например в каждом ядре каждая инструкция параллельно выполняется на 2-х блоках и результаты сравниваются — если есть различие процессор помечается сбойным и инструкция уезжает работать на "запасной" процессор (на одной подложке их несколько — и один как минимум всегда в резерве ).
Ну нее, в материнские платы включать мониторы, даже начальные так себе идея. Лучше купить внешнюю карту — достаточно не очень дорогую. У меня есть FireWire Solo (но уже не используется — спасибо M-Audio за то что загубили драйвера под MacOS) и текущая Scarlet Focusrite 2x4 — так те же KRK подключаются балансным входом к балансному выходу карты — разница в звуке есть очень ощутимая.
Что то больше похоже на обзор того что есть на складе магазина. А начальных мониторов есть вагон и маленькая тележка. Как минимум
M-Audio BX8 D3
KRK Rokit 5 G4. (8-ки уже подороже)
У самого были эти две модели — от BX8 пришлось отказаться из-за того что на столе не помещались. А вот KRK очень понравились за свои деньги, на них даже сводить вполне возможно.
Расслабьтесь, это вообще мировая тенденция, Россия здесь вообще не уникальна. Работая в большом международном корпе с распределенными командами, я вижу как это происходит в рамках всего мира. Как, например несколько сеньоров например из Европы, заменяются толпой индусов, а через несколько лет толпа индусов заменяется на еще большую толпу мексиканцев и качество дальше падает еще катастрофически (хотя для такой работы хватило бы и 2-х сеньоров). С моей точки зрения, я вижу множество факторов, которые приводят к этому. Высокая стоимость (и зачастую весьма обоснованная) действительно толковых специалистов и короткий цикл жизни софта и как следствие необходимость писать код быстро и быстро выкатывать в прод, что бы через полгода-год, сказать это что сделали все фигня и надо быстро запилить новую систему вместо старой (много ли сейчас приложений или систем с жизненным циклом лет в 10 хотя бы ?). Как следствие, с точки зрения бизнеса — толпа вайтишников выгоднее, чем команда профи в краткосрочной перспективе. Как минимум с точки зрения устойчивости проектов, тупо если из команды в 20 вайтишников уйдет 3-5 сотрудников, это даже не сильно заметно будет (да и заменить не сложно) — то из условно равноценной команды профи-сеньоров в 4 человека — потеря даже одного — уже критическая ситуация для проекта. С обратной стороны — текучка кадров вайтишников — это другая сторона попаболи менеджера проекта. У тех же индусов в среднем attrition rate (текучка кадров) в среднем идет от 15-20% в год (тупо из 5 пришедших — один уйдет в течении года), а у тех же мексиканцев доходит и до 50%? И как работать с такими вайтишникаим, если learning curve (время на обучение что бы понять все внутренности проекта) в твоем проекте порядка 18 месяцев и к моменту окончания числа обучения нужно начинать все по новой, поскольку первые пришедшие в проект уже ушли ?
Tiger Lake в Mac еще нет, я сравнивал с текущим доступным и это пока что максимум UHD 630 — и по сравнению с ними M1 GPU выглядит очень солидно. Ведь те машинки Air и Про 13" всегда шли на встроенной графике. Для старших же моделей — вероятно Apple выкатит что то иное в следующем году или подключит ту же дискретную графику.
Процессор получился довольно интересный, как по мне. Более того для тех машинок MB Air, MBPro 13 — получилось неплохое комбо со встроенной графикой — тут Интел отдыхает
В OpenCL результаты соответствуют больше дискретной графике, нежели встройке.
Apple Silicon выдает 18656 попугаев Apple M1 GPU
На моем MacBook Pro 16"
Самая печаль это у Hackintosh пользователей, очевидно при полном переходе на ARM архитектуру, hackintosh будет — ой, все.
Это опять смотря что запущено из приложений и какой у вас Мас (со встроенной графикой только, или встройка + дискретная). Обычно 8 гиг это на модельках с интегрированной графикой, которая тоже потребляет обычную RAM под видеопамять (Intel UHD Graphics 630 — VRAM (динамическая, макс.): 1536 МБ). Так что кто то запустит Докер на 8гигах и оно будет работать, а кто то запустит Фотошоп с большим файлом и кучей слоев и ему не хватит памяти, поскольку память подъели как и сами приложения, так и видеодрайвер встроенной графики.
По ту сторону Темзы видимо жили наши люди. Twa vodka pozhaluista! :-)
Тут на вкус и цвет — все фломастеры одинаковые. Но распределенная система более устойчива чем централизованная. Не будут же домашние ждать света в туалете, пока вы версию Domoticz обновлять будете? Для мелких автоматизаций — встроеные правила самое оно.
Прекрасно работают — когда упакованы IP65 защитные коробочки — уже несколько лет полет нормальный. Возможно у вас влажность была повышенная и контакты в реле подмерзли, может что другое. Чипу ESP в принципе -10 не страшны, вот влажность или конденсат не приветствуются — поэтому хорошие герметичные установочные коробки — must have.
В Home Assistant уже встроен Apple Homebridge, так что все выключатели, сенсоры и прочее видны в HomeKit автоматом. Большим плюсом — это возможность создавать виртуальные устройства которые также будут видны в Apple Home — например у меня создана виртуальная сигнализация с кейпадом которая отрабатывает все датчики (окон, дверей, PIR датчики присутствия и ONVIF камеры наблюдения).
Так же из ИМХО важного, что в принципе нужно любому умнодомостроителю (а мы говорим о доме, а не о квартире) — это все устройства типа Sonoff перевести на альтернативную прошивку (в моем случае Tasmota). Плюсов там миллион — можно подключать дополнительные датчики прям к простым реле (например ставить DS18B20 в простой модуль Sonoff Basic), а также использовать микроавтоматизацию на уровне самого устройства Sonoff (c Tasmota смотри раздел Rules) без необходимости дергать Domoticz или Home Assistant. Например у меня подсветка дорожек в саду включается от датчиков движения, только тогда когда село солнце.
Пример из Rule Cookbook
Датчики движения, открытия окон и дверей, задымления и пр. — все работают на стандартных 433Mhz — прекрасная и надежная система для частного дома (дальность работы до 100м). К ним покупается Sonoff RF шлюз — и все прекрасно заводится в Home Assistant. И таки да — проводов не надо — батарейки рулят — мне в среднем хватает батарейки в датчиках на 2 года.
Baxi более или менее в адеквате :-). Не без закидонов, конечно — там нужно волшебную последовательность команд давать что бы он переходил в режим управления (иначе он работает только в режиме монитора — смотреть можно, менять ни-ни). У Бошей свои приколы — регулирует температуру по ОТ только в пределах которые сначала ручками установил на котле и т.д. и т.п. Вообще есть табличка кто что может
Табличка поддержки OT по котлам
Да, ECO-4s поддерживает opentherm, даже платы адаптера вроде как не требуется на котел (на мой Slim пришлось докупать). Если не охота махать паяльником — то есть вообще готовые решение типа ZONT от микролайна (но мне они не нравятся из-за невозможности работать локально — все API через сервера микролайн)