Была у меня плата Abit с самым крутым аудиочипсетом на то время. И так совпало, что в это же время под какой то очередной сокет/процессор стали менять линейные стабилизаторы на импульсные. Через пару лет плата протекла, поскольку стабилизаторы поменяли, а конденсаторы оставили прежние, под линейный режим. И не один Abit так накосячил
Я видел реальную систему многоканальной обработки на 4ядерном процессоре, работающая с двумя eth интерфейсами, блоком разделяемой памяти и хост интерфейсом. По таймеру каждому каналу предоставлялось время на вызов последовательности функций обработки соотв буфера, в том числе из 3d party библиотеки. Управление через хост интерфейс и разделяемую память позволяло менять параметры обработки, обратно работал printf для логгирования. Модернизация сводилась к изменению -созданию функций, пока производительности хватало. Я там копался в паре мест -ни разу не сталкивался с проблемами в спланированных вычислениях, только табличку расширял для контроля загрузки Система была реального времени, так как гарантировала время обработки данных, реакции на команду и загрузку системы. Другое дело, что она была не как её, интерактивная) И была причина, почему там не было никакой ОС -лицензия стоила существенные деньги, существенно дороже, чем МонтаВиста, которая стояла на хосте, и где кроме rt_fifo ничего, вродебы, не использовалось. Я никоим образом не пытаюсь принизить достоинств осрв, особенно для систем с мышкой и юзером, или если там ещё и полноценные приложения, но while до сих пор имеет право на жизнь, имхо
Наверно всё таки не совсем так - while это же разновидность планировщика, только не в ос, а в приложении. Если подходить с этой позиции то можно обойтись и им, правда второй вопрос будет - зачем так, если есть ос.
То, что все сервера подвергаются тщательному сканироварию с китайсаих айпи с середины 90х факт. То, что операторов ломают чтобы получить доступ к международным звонкам по цене внутренних - тоже факт. Но факты не вяжутся, имхо)
Я не очень понял реальные юзкейсы, где может потребоваться использование циклических буферов такого типа. Буфер под ссылки с кешированием - тоже не очень буфер, имхо. Если есть короткая ссылка куда нибудь буду рад познакомиться
И зачем нужно, чтобы ссылки кешировались? Это будет влиять на производительность? Просто я видел использование кольцевых буферов в драйверах Ethernet и использовал из в драйверах АЦП, везде стат аллокация памяти и DMA. С boost не работал. Поэтому и не очень понимаю о чём речь, хотя идея и понятна
"Разумеется, это также означает, что, если вам приходится оперировать сравнительно крупными элементами, то вы особенно не выиграете от оптимизации кольцевого буфера"
на этом можно было бы и закончить с оптимизацией, имхо.
Во первых не все в пятницу отключают электричество, во вторых да, суббота у всех священна, зато в воскресенье вполне себе работают. Меня больше сентябрьские праздники удивляли - правильные их почти 2 недели "отмечали"
Всё через ПМ это не американские игры, а корпоративные. В стартапах это минимизировано, там и ПМов то может не быть), а по мере роста растут и прослойки, и им надо быть в курсе и руководить. В одной конторе мой начальник был СТО, в другой VP, но с CTO при необходимости я тоже мог легко пообщаться. Закончилось это структурой из CTO, старшего VP, моего прежнего VP и дев менеджера. При этом вокруг этой вертикали были продакт оунеры, релиз менеджмент, проджект менеджмент, комплианс и скорее всего кто то ещё. После какого нибудь тех митинга, на котором присутствовало только 3-4 инженера из 20 участников, некоторые подразделения проводили ещё митинг, на котором один инженер рассказывал своим начальникам на что они так позитивно и вежливо сказали great и ок)
Отличная статья и проект, насчёт аппетита - всё верно) Один из выводов -инженерка должна проектироваться с учётом совместимости с умным домом и особенно HA, поскольку интеграции через облака при отсутствии интернета будут отваливаться Странноватым показались следующие характеристики инженерки - котел на 36 кВт для дома менее 200 м - у меня на брикетах 28 кВт на 200 общей площади, топлю раз в сутки по 40-60 кг, отопление только тёплыми полами. Вентсистема на 15 кВт - она без рекуперации? Но это, конечно, к автоматизации не относится. Но автоматизацией, наверное, проблему этих 15 кВт можно решить - датчик CO2 в выхлопе и управление производительностью.
У нас на совсем другой платформе возникала проблема с tcp, причём на давно работавшем коде, на долгих запросах к бд. Неожиданно они стали зависать и отваливаться. Как всегда, никто ничего не делал) Проблема оказалась в изменении полиси роутеров, которые без трафика стали прихлопывать соединение через час, а дефолтный кипэлайв был 2 часа. И для сервера и для клиента сам разрыв соединения был незаметен. Вообще контроллировать доступность сервиса по таймаутам прикладного протокола конечно можно, но не достаточно, имхо
А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы? И как аналитик может эстимировать объём работы по задаче и подводные камни?
А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы? Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха))) Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
ПО следует разделять на архитектурные и конструктивные компоненты. Архитектурные имеют долговременную стабильность и переносимость между платформами, конструктивные предназначены для адаптации к платформам, вводу выводу и интерфейсам - забыл источник)
Была у меня плата Abit с самым крутым аудиочипсетом на то время. И так совпало, что в это же время под какой то очередной сокет/процессор стали менять линейные стабилизаторы на импульсные. Через пару лет плата протекла, поскольку стабилизаторы поменяли, а конденсаторы оставили прежние, под линейный режим. И не один Abit так накосячил
Я видел реальную систему многоканальной обработки на 4ядерном процессоре, работающая с двумя eth интерфейсами, блоком разделяемой памяти и хост интерфейсом. По таймеру каждому каналу предоставлялось время на вызов последовательности функций обработки соотв буфера, в том числе из 3d party библиотеки. Управление через хост интерфейс и разделяемую память позволяло менять параметры обработки, обратно работал printf для логгирования. Модернизация сводилась к изменению -созданию функций, пока производительности хватало. Я там копался в паре мест -ни разу не сталкивался с проблемами в спланированных вычислениях, только табличку расширял для контроля загрузки
Система была реального времени, так как гарантировала время обработки данных, реакции на команду и загрузку системы. Другое дело, что она была не как её, интерактивная)
И была причина, почему там не было никакой ОС -лицензия стоила существенные деньги, существенно дороже, чем МонтаВиста, которая стояла на хосте, и где кроме rt_fifo ничего, вродебы, не использовалось.
Я никоим образом не пытаюсь принизить достоинств осрв, особенно для систем с мышкой и юзером, или если там ещё и полноценные приложения, но while до сих пор имеет право на жизнь, имхо
Наверно всё таки не совсем так - while это же разновидность планировщика, только не в ос, а в приложении. Если подходить с этой позиции то можно обойтись и им, правда второй вопрос будет - зачем так, если есть ос.
То, что все сервера подвергаются тщательному сканироварию с китайсаих айпи с середины 90х факт. То, что операторов ломают чтобы получить доступ к международным звонкам по цене внутренних - тоже факт. Но факты не вяжутся, имхо)
Понял, спасибо, плюсы не ставятся)
Я не очень понял реальные юзкейсы, где может потребоваться использование циклических буферов такого типа. Буфер под ссылки с кешированием - тоже не очень буфер, имхо. Если есть короткая ссылка куда нибудь буду рад познакомиться
И зачем нужно, чтобы ссылки кешировались? Это будет влиять на производительность? Просто я видел использование кольцевых буферов в драйверах Ethernet и использовал из в драйверах АЦП, везде стат аллокация памяти и DMA. С boost не работал. Поэтому и не очень понимаю о чём речь, хотя идея и понятна
"Разумеется, это также означает, что, если вам приходится оперировать сравнительно крупными элементами, то вы особенно не выиграете от оптимизации кольцевого буфера"
на этом можно было бы и закончить с оптимизацией, имхо.
Во первых не все в пятницу отключают электричество, во вторых да, суббота у всех священна, зато в воскресенье вполне себе работают. Меня больше сентябрьские праздники удивляли - правильные их почти 2 недели "отмечали"
Всё через ПМ это не американские игры, а корпоративные. В стартапах это минимизировано, там и ПМов то может не быть), а по мере роста растут и прослойки, и им надо быть в курсе и руководить.
В одной конторе мой начальник был СТО, в другой VP, но с CTO при необходимости я тоже мог легко пообщаться. Закончилось это структурой из CTO, старшего VP, моего прежнего VP и дев менеджера. При этом вокруг этой вертикали были продакт оунеры, релиз менеджмент, проджект менеджмент, комплианс и скорее всего кто то ещё. После какого нибудь тех митинга, на котором присутствовало только 3-4 инженера из 20 участников, некоторые подразделения проводили ещё митинг, на котором один инженер рассказывал своим начальникам на что они так позитивно и вежливо сказали great и ок)
Полно проприентарщины с которой HA интегрируется только через сервис производителя, а не как с устройством
24 норм - быстрее прогрев, горячая вода, та же вентиляция, а вот 36 - подозрительно)
Отличная статья и проект, насчёт аппетита - всё верно) Один из выводов -инженерка должна проектироваться с учётом совместимости с умным домом и особенно HA, поскольку интеграции через облака при отсутствии интернета будут отваливаться
Странноватым показались следующие характеристики инженерки - котел на 36 кВт для дома менее 200 м - у меня на брикетах 28 кВт на 200 общей площади, топлю раз в сутки по 40-60 кг, отопление только тёплыми полами. Вентсистема на 15 кВт - она без рекуперации? Но это, конечно, к автоматизации не относится. Но автоматизацией, наверное, проблему этих 15 кВт можно решить - датчик CO2 в выхлопе и управление производительностью.
Ладно что без вирусов...)
У нас на совсем другой платформе возникала проблема с tcp, причём на давно работавшем коде, на долгих запросах к бд. Неожиданно они стали зависать и отваливаться. Как всегда, никто ничего не делал) Проблема оказалась в изменении полиси роутеров, которые без трафика стали прихлопывать соединение через час, а дефолтный кипэлайв был 2 часа. И для сервера и для клиента сам разрыв соединения был незаметен.
Вообще контроллировать доступность сервиса по таймаутам прикладного протокола конечно можно, но не достаточно, имхо
И манагеров так же перемешать - сегодня ты сто а завтра проджект менеджер))
А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы?
И как аналитик может эстимировать объём работы по задаче и подводные камни?
А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы?
Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха)))
Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
Не работает - как только Шахназаров попросил снять блокировки на десктопах, так сразу и стал подвисать на мобильном Мегафоне
ПО следует разделять на архитектурные и конструктивные компоненты. Архитектурные имеют долговременную стабильность и переносимость между платформами, конструктивные предназначены для адаптации к платформам, вводу выводу и интерфейсам - забыл источник)