В конце 90х читал статью про АШП для Боинга или типа того на TMS320
В моей машине есть АШП, гасящая низкочастотные шумы двигателя и шин)
Насчёт задержек - 1мс это 30 см расстояния в воздухе, можно отодвинуть микрофон от динамика. Правда это требует коррекции модели подавления и алгоритма. Ну и да - микрофонов и динамиков должно быть больше, значит процессор дб другой
Я никогда не был сетевиком) W3.11 работала либо с ipx/spx, либр с tcp/ip, если на драйвер карты навешивали и то и другое, при каких то условиях тачка вешалась наглухо. W95 тогда был только на одной машине и тоже вешался при двух стеках. Поэтому перешли только на tcp/ip, а новеловский сервер на 386 с 4 мб оперативки переделали в маршрутизатор под slackware на 2 внутренних локалки и интернет. Ну и плюс ввв, качалка на wget, прокси, самба контроллер. В итого это оказалось перспективней чем возня с нелицерзионным новелом)
Сначала появилась производительность, как количественная метрика, потом динамика производительности.. много я всяких передовых идей в аджайле повидал, но с таким не сталкивался.
Задумайтесь, какой физический смысл имеют абстрактные сторипойнты, делённые на инфляционные рубли при такой кредитной ставке и так ли стоит на подобном шатком фундаменте строить какие то выкладки)
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная
SP для задач проставляет команда. Никакой системы оценивания единой для двух команд быть не может, тем более если стоимость у них настолько различается.
Всё, что даёт SP это велосити, на основании которого старшие "товарищи" могут прикидывать, за сколько спринтов конкретная команда будет разгребать то, что уже наэстимировала в свой беклог.
Вот честно не помню ядер или процессоров. Может это было в предверии P Pro, может для альфы, но этот параметр меня в то время сильно удивил, поэтому и запомнился. Я пытался тогда объединить дисплей класс на W3.11 с сервером Novel Netware под ipx с рабочими машинами и подключить всё к интернету, с Warp это почти удалось, но ipx с tcp/ip под виндус так и не заработал, пришлось выкинуть новел и перевести всё на tcp/ip с маршрутизацией через линукс сервер. И снести Warp)
Ну, код целиком, конечно, не очень правильно оставлять, но у меня был случай, когда от меня с интервалом в два-три года два раза требовали поменять поведение, которым я и не управлял) Первый раз я достаточно быстро нашёл флажок в ui, код, который из нескольких флажков выбирал режим работы и через несколько компонент спускал ко мне. В комменте к и вправду странному коду был указан номер тикета и фамилия коллеги, который это написал. Почитал тикет, посмотрели его с этим коллегой и отписались, что это поведение решение маркетинга. А вот через несколько лет, хотя смутно помнил, что что то такое исследовал уже, этот код искал дольше, нашёл тот коммент - трекер сменили, старый архив закрыли, коллега уволился, перфорс сменили гитом, маркетинг и саппорт весь поменялся, если бы не архив почты, где этот тикет мелькал раз в 3 года, пришлось бы ещё месяц со всеми переписываться. Не, можно конечно было поправить эти флажки чтобы клиент стал счастливым, только тогда прилетела бы сотня запросов от других клиентов почемв стало по другому..
Поэтому я за комменты в странных или критических местах
А если в api к чему нибудь есть несколько методов, которые могут требовать повторов, логику ретрая надо имплементировать в каждом? Или правильней параллельный апи свести к последовательному типа command-parameters и один раз окружить это ретраями, таймаутами и анализом ошибок?
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
У меня была такая же проблема, когда учился - не чувствовал хода стопы на сцеплении и газе. Помогли 2 упражнения - дома резинка, которой тянул носок каждой ступни и медленно в противофазе нажимал и отпускал воображаемые педали. Второе -когда гулял с дочкой в песочнице, делал такую горку и мял её ступнями, имитируя нажатия.
Интересны абсолютные цифры объёма и скорости достигнутого логгирования. Допустим, на один сервер 12 ГБ в час, 50 серверов в одном датацентре. Просто общался с kibana, и не очень она была полезна именно для изучения логов, всё равно приходилось идти к тексту
Хорошая статья и проект, да и к Технониколь по опыту строительства дома отношение норм. При прочтении комментов возникли мысли - да, некоторые вещи типа выбор комплектующих, протоколов и стеков, можно бы было сделать эффективней, но как? Технологии тензоизмерений не очень связаны с мех технологиями объединения датчиков, а те не очень заточены на что то типа msp430 vs esp32. Зато оптимизировать работающее изделие уже можно в каждой отдельной сфере, в том числе после публикации проекта на хабр) ОпенПроджект?)
То есть загрузка каждого ядра 80%? Мне просто такая метрика не знакома - загрузка в ядрах
А насколько эти cpu нагружены?)
В конце 90х читал статью про АШП для Боинга или типа того на TMS320
В моей машине есть АШП, гасящая низкочастотные шумы двигателя и шин)
Насчёт задержек - 1мс это 30 см расстояния в воздухе, можно отодвинуть микрофон от динамика. Правда это требует коррекции модели подавления и алгоритма. Ну и да - микрофонов и динамиков должно быть больше, значит процессор дб другой
Я никогда не был сетевиком) W3.11 работала либо с ipx/spx, либр с tcp/ip, если на драйвер карты навешивали и то и другое, при каких то условиях тачка вешалась наглухо. W95 тогда был только на одной машине и тоже вешался при двух стеках. Поэтому перешли только на tcp/ip, а новеловский сервер на 386 с 4 мб оперативки переделали в маршрутизатор под slackware на 2 внутренних локалки и интернет. Ну и плюс ввв, качалка на wget, прокси, самба контроллер. В итого это оказалось перспективней чем возня с нелицерзионным новелом)
Наступает время голубей и ястребов)
Сначала появилась производительность, как количественная метрика, потом динамика производительности.. много я всяких передовых идей в аджайле повидал, но с таким не сталкивался.
Задумайтесь, какой физический смысл имеют абстрактные сторипойнты, делённые на инфляционные рубли при такой кредитной ставке и так ли стоит на подобном шатком фундаменте строить какие то выкладки)
SP для задач проставляет команда. Никакой системы оценивания единой для двух команд быть не может, тем более если стоимость у них настолько различается.
Всё, что даёт SP это велосити, на основании которого старшие "товарищи" могут прикидывать, за сколько спринтов конкретная команда будет разгребать то, что уже наэстимировала в свой беклог.
Вот честно не помню ядер или процессоров. Может это было в предверии P Pro, может для альфы, но этот параметр меня в то время сильно удивил, поэтому и запомнился. Я пытался тогда объединить дисплей класс на W3.11 с сервером Novel Netware под ipx с рабочими машинами и подключить всё к интернету, с Warp это почти удалось, но ipx с tcp/ip под виндус так и не заработал, пришлось выкинуть новел и перевести всё на tcp/ip с маршрутизацией через линукс сервер. И снести Warp)
Как до Мартина программировали и системы строили - загадка)))
Там менюшка с фильтрами была и прочими инструментами, возможно для распараллеливания
Помню в warp 3 был графический редактор типа paint, но помощнее, у него в настройках можно было установить использование до 64 ядер
Зачем ехать в оффис в 8:00, если технологически даже романтизм вполне удовлетворяет виртуально?))))
Ну, код целиком, конечно, не очень правильно оставлять, но у меня был случай, когда от меня с интервалом в два-три года два раза требовали поменять поведение, которым я и не управлял) Первый раз я достаточно быстро нашёл флажок в ui, код, который из нескольких флажков выбирал режим работы и через несколько компонент спускал ко мне. В комменте к и вправду странному коду был указан номер тикета и фамилия коллеги, который это написал. Почитал тикет, посмотрели его с этим коллегой и отписались, что это поведение решение маркетинга. А вот через несколько лет, хотя смутно помнил, что что то такое исследовал уже, этот код искал дольше, нашёл тот коммент - трекер сменили, старый архив закрыли, коллега уволился, перфорс сменили гитом, маркетинг и саппорт весь поменялся, если бы не архив почты, где этот тикет мелькал раз в 3 года, пришлось бы ещё месяц со всеми переписываться. Не, можно конечно было поправить эти флажки чтобы клиент стал счастливым, только тогда прилетела бы сотня запросов от других клиентов почемв стало по другому..
Поэтому я за комменты в странных или критических местах
Это если через 10 лет не поменяют систему контроля версий или репозиторий криво смигрируют) да ещё и трекер не сменят на другой
А если в api к чему нибудь есть несколько методов, которые могут требовать повторов, логику ретрая надо имплементировать в каждом? Или правильней параллельный апи свести к последовательному типа command-parameters и один раз окружить это ретраями, таймаутами и анализом ошибок?
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
У меня была такая же проблема, когда учился - не чувствовал хода стопы на сцеплении и газе. Помогли 2 упражнения - дома резинка, которой тянул носок каждой ступни и медленно в противофазе нажимал и отпускал воображаемые педали. Второе -когда гулял с дочкой в песочнице, делал такую горку и мял её ступнями, имитируя нажатия.
Интересны абсолютные цифры объёма и скорости достигнутого логгирования. Допустим, на один сервер 12 ГБ в час, 50 серверов в одном датацентре. Просто общался с kibana, и не очень она была полезна именно для изучения логов, всё равно приходилось идти к тексту
Хорошая статья и проект, да и к Технониколь по опыту строительства дома отношение норм. При прочтении комментов возникли мысли - да, некоторые вещи типа выбор комплектующих, протоколов и стеков, можно бы было сделать эффективней, но как? Технологии тензоизмерений не очень связаны с мех технологиями объединения датчиков, а те не очень заточены на что то типа msp430 vs esp32. Зато оптимизировать работающее изделие уже можно в каждой отдельной сфере, в том числе после публикации проекта на хабр) ОпенПроджект?)
Аа, понял - я просто решил, что xdma это именно dma)