The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для ядра Linux предложена возможность отслеживания переохлаждения системы, opennews (??), 14-Дек-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


48. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +1 +/
Сообщение от Аноним (-), 15-Дек-23, 01:45 
> может, я чего-то не понимаю, но это разве не работа для BIOS?

Что такое "BIOS" на вот этом ARMовском одноплатнике? А вот линух там есть. И в device tree можно thresholds по вкусу заколотить. Попроще чем в твое долбаное ACPI кстати.

> зачем брать на себя ТАКУЮ работу?

Потому что линух используется много где. Например - в управляющих встраиваемых системах. И собссно если система стала подмерзать - почему бы ей и не апклокнуться? Если при перегреве даунклок делают - ну, окей, а почему инверсную логику нельзя для минуса?

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

55. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Бывалый смузихлёб (?), 15-Дек-23, 06:27 
Подобные задачи, мало того, что запросто решаются периодически просыпающимся процессом, проверяющим состояние и отправляющим соотв команды
Так и сам по себе холод процу едва ли вредит - вредить может таковому генератору, но это отдельная деталь
Вредить он может аккумулятору, но его не разогреешь кочегаркой проца
Да и с повышением напряжения на нём можно доиграться
Будто этого мало, подогрев нередко сделан на россыпухе и работает независимо, ведь ОСь может зависнуть и чего-то перегреть вплоть до пожара

В общем, идея толкать подобное в ядро ВСЕМ( даже не только встраиваемым ) линухам - очень сомнительна

Ответить | Правка | Наверх | Cообщить модератору

61. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Аноним (30), 15-Дек-23, 08:31 
Такое опасно разве что чипам с 3д кешем. А андервольт никуда не девается если это дело выключить.
В обычной работу турбобусты повышают напряжение. Если на проце баг замерзания - тогда это стоит включить. Если комп работает в морозильных условиях и может вжоривать - можно просто поставить кулер.
Ответить | Правка | Наверх | Cообщить модератору

111. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Аноним (-), 16-Дек-23, 19:18 
> Подобные задачи, мало того, что запросто решаются периодически просыпающимся процессом,
> проверяющим состояние и отправляющим соотв команды

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

Если очень критично, можно МК поставить, этот точно индустриальный диапазон выдюжит, и обвес простой, а он thermal и проч очень плотно, точно и реалтаймно разрулит. Но это отдельные деньги и усложнение системы.

> Так и сам по себе холод процу едва ли вредит - вредить
> может таковому генератору, но это отдельная деталь

Кроме проца в системе много чего еще есть. И корректное поведение проца и остальных чипов при каком -40 специфицировано не для всех чипов. Свойства кремниевых PN переходов при изменении температуры отъезжают (man "thermal diode", до кучи это готовый градусник).

Да даже емкости фильтрующих кондеров отъезжают. И если кто попробует с места в карьер с idle полный вперед системе дать а кондеры не удержат и вольтаж провалится - угадайте что дальше. В этом смысле идея учесть в софте такие вещи не так уж и бредова. Но более характерна для более мелких систем.

> Вредить он может аккумулятору, но его не разогреешь кочегаркой проца

Понимаешь, мистер эксперт, ты это рассказываешь электронщику, который знает как под "industrial" диапазон температур (-40..+85) фигачить. И акум - разный бывает. Акум авто всяко с таким жить умеет. При том свинцовый даже без thermal management. И уж пару одноплатников он удержит хоть там что. Я говорил что линь нравится автомотивщикам?

> Да и с повышением напряжения на нём можно доиграться

В случае лития основная проблема с ним - в том что при минусе его заряжать нельзя, а при перегреве он может уйти вразнос. Ну так его и не применяют там где это проблема, или решают эту траблу. И кстати вам не приходило в голову что FAN как логику тоже можно в принципе инверсно сделать - "heater" или "peltier" какой, с PWMом на нужный уровень. В случае пельтехи есть некие особенности, но кому это было надо - их знают.

> Будто этого мало, подогрев нередко сделан на россыпухе и работает независимо, ведь
> ОСь может зависнуть и чего-то перегреть вплоть до пожара

Еще может быть на МК. А что до перегрева - в нормальных железках многоуровневые защиты. Даже в тупой как дрова микроволновке, вот, механический термостат-размыкатеь на 200 градусов, на случай если ее МК сделает что-то не так. А на случай когда что-то пошло вообще совсем не так - еще и термопредохранитель на 230 градусов (этот уже одноразовый, и если он сработает, хомячок пойдет в сервисцентр). Так что эта штука не даст процу вылезтис за 200 градусов в рабочей зоне, а если это обломалось - окончательный FAIL SAFE отправит хомяка в сервис (самому термопредохранитель поменять можно, но в хозяйственном ЭТО не продается, это "электроника").

> В общем, идея толкать подобное в ядро ВСЕМ( даже не только встраиваемым
> ) линухам - очень сомнительна

Вот лично мне - пригодится...

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

121. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Бывалый смузихлёб (?), 18-Дек-23, 13:51 
> Кернел и его инфраструктура в этом качестве - понадежнее будет. И даун
> кернела довольно быстро будет замечен хардварным вачдогом. В софте решаемо, особенно
> с системдшным апи вачдогования процессов, но в кернеле лучше.

Я бы подобное не рискнул делать, если бы мне была поставлена подобная задача с хотя бы минимальной но ответственностью
Скорее всего, сделал бы термодатчик или несколько +
ОУ / Компаратор +
Нагреватель +
Несколько последовательно включенных термореле( уже от перегрева и расставленных в разных точках )

> Кроме проца в системе много чего еще есть. И корректное поведение проца
> и остальных чипов при каком -40 специфицировано не для всех чипов.
> Свойства кремниевых PN переходов при изменении температуры отъезжают (man "thermal diode",
> до кучи это готовый градусник).

Ну в том и прикол, что "решение" из статьи позволяет прогревать лишь проц, а не в принципе решает проблему

> Понимаешь, мистер эксперт, ты это рассказываешь электронщику, который знает как под "industrial"
> диапазон температур (-40..+85) фигачить. И акум - разный бывает. Акум авто
> всяко с таким жить умеет. При том свинцовый даже без thermal
> management. И уж пару одноплатников он удержит хоть там что. Я
> говорил что линь нравится автомотивщикам?

Линь вообще на пушечный выстрел не подпускают к автоматике любые кому хоть что-то дорого( включая карму и лицензии в зависимости от страны )

Он( нередко с кутями ), по сути, служит лишь "мордой" к контроллеру, в котором зашита ОСРВ повышенной надёжности с кучей задач и которая корректно отработает даже если линь зависнет или упадёт

> И кстати вам не приходило в голову что
> FAN как логику тоже можно в принципе инверсно сделать - "heater"
> или "peltier" какой, с PWMом на нужный уровень. В случае пельтехи
> есть некие особенности, но кому это было надо - их знают.

Знают. Греет хорошо, но охлаждает - почти никак и с риском уже их перегреть
Ещё и классическая с полупроводниками штука - что параметры со временем плывут и сильно


Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/
Сообщение от Аноним (-), 18-Дек-23, 15:47 
Ответить | Правка | Наверх | Cообщить модератору

125. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Аноним (125), 18-Дек-23, 15:50 
> Я бы подобное не рискнул делать, если бы мне была поставлена подобная
> задача с хотя бы минимальной но ответственностью

Вообще - работает. Стабильно. Годами. Но если вопрос в том что кто-то умрет или пострадает, многоуровневые защиты - мастхэв, конечно.

> Скорее всего, сделал бы термодатчик или несколько + ОУ / Компаратор +

С этим всем тоже можно познать горя. Заметив что оно нестабильное, неточное, требует мануальную настройку (антитехнологично), нельзя изменить настройки в рантайме, нельзя автоматизировать калибровку "конкретного экземпляра".

Решаемо, но прецизионные, термо и долговременно стабильные компоненты, их взаимодействия в широком диапазоне - это отдельный топик. Дорогой, сложный в покупке, в реализации, с более 9000 залетов. Как минимальный failsafe - почему нет? Как основной loop - блин, у него даже самодиагностики нету. И мы узнаем что FAIL - уже по факту. Круто, современно...

> Нагреватель +
> Несколько последовательно включенных термореле( уже от перегрева и расставленных в разных
> точках )

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

С другой стороны - МК около бакса. И LM75 (или его клоны) - цифровой, i2c/smbus, точность градус или лучше. И оно с фабы калиброваное. И может и цепь проверить, и датчики, и что система реагирует на ихменения ожидаемо, и хосту отрепортить статус, и вообще все в safe state уложить. При том кто сказал что safe state всегда решаем компаратором? Возможно для входа в safe state системы надо какое-то секвенсирование действий?

> Ну в том и прикол, что "решение" из статьи позволяет прогревать лишь
> проц, а не в принципе решает проблему

Это конечно зависит от конкретики реализации - но тепло проца чаще всего рассеивается в тот же объем и стало быть подогреет его.

> Линь вообще на пушечный выстрел не подпускают к автоматике любые кому хоть
> что-то дорого( включая карму и лицензии в зависимости от страны )

Поэтому он летает в космос, рулит поездами, промом, а вот это хотят - автомотивщики. Логично.

> Он( нередко с кутями ), по сути, служит лишь "мордой" к контроллеру,

У элонмасковского корабля он - таки - бортовой компьютер, вот. Конечно их несколько, и контроллеры подстраховывают, но...

> в котором зашита ОСРВ повышенной надёжности с кучей задач

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

> и которая корректно отработает даже если линь зависнет или упадёт

И тем не менее даже я заимплементил системы которые годами работают. Ничего там не виснет и не падает. Надо просто вынуть руки из... и научиться в валидацию системы ДО того как ее отдать другим.

> Знают. Греет хорошо, но охлаждает - почти никак и с риском уже их перегреть

У них есть свои лимиты применимости. Зато - мелкие и электрчиески управляемые. Там фэйл в лимитированом числе включений еще. Видимо от перепадов кучаконтактов PN junction может отвалиться уже там :). И если вы будете вот именно компаратором его рулить - он и помрет в момент, лимит на число включений даже в даташите бывает. Но если вместо тупого компаратора взять PWM, доделать до DCDC (например buck) и вместо on/off - рулить заполнением PWM, а катуха еще и фильтранет пульсации... все станет гораздо оптимистичнее. И придумал DCDC+Firmware не я. Но я тоже уже немнго умею.

> Ещё и классическая с полупроводниками штука - что параметры со временем плывут и сильно

А вот для цифровых штук это - вообще совсем не проблема. Можно автоматически это компенсировать. В отличие от аналогового дубья. В частности цифровые датчики, вот, делают с компенсацией и калибровками прям на фабе - и они довольно хорошо специфицированы по долговременной стабильности, точности и вообще. Если совсем уж левак не брать - будет как в даташите. И если эн датчиков говорят системе что температура вот такая - значит, крутим PWM вон туда. И оно самокомпенсирует уплыв параметров.

p.s. долбаный бот, чего ему в вон том сообщении не нравится?

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

105. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Аноним (105), 16-Дек-23, 05:17 
> Что такое "BIOS" на вот этом ARMовском одноплатнике?

Он там есть, только делаешь ты его сам ;) Называет uboot.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

114. "Для ядра Linux предложена возможность отслеживания переохлаж..."  +/
Сообщение от Аноним (-), 17-Дек-23, 23:10 
>> Что такое "BIOS" на вот этом ARMовском одноплатнике?
> Он там есть, только делаешь ты его сам ;) Называет uboot.

Он "boot loader" так то. А на минималках - его SPL на ...цать кило весом может вместо основной тушки uboot и сразу ядро линуха пнуть.

При этом резидентно в памяти он не остается, API в run time не предоставляет, setup нет, и в целом это куда более простая и предсказуемая штука.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру