По поводу ВРУ и управляющей компании — все разговоры идут только об индивидуальных устройствах учета: realty.ria.ru/20190805/1557176788.html
Ну и УКРМ для несимметричной нагрузки с большой долей ВЧ-гармоник это не просто тройка дешевых вечных конденсаторов; также сомневаюсь что УК захочет (и кто-то сможет ее заставить) выделять на это деньги.
Всего-то нужно прекратить цепляться за наследние царского режима^W Эдисона и использовать LED-панели с импульсным БП с коррекцией коэффициента мощности. И вот внезапно оказывается что все уже давно решено и придумано.
А вы точно понимаете как работает трехфазная система переменного тока и то, какую роль там выполняет нулевой провод и ожидаемые значения тока через него?
Как я уже писал выше, штрафной тариф за пониженный коэффициент мощности дело времени, и (думается) совсем небольшого. И внезапно «дешевые» лампы могут стать не такими уж и дешевыми.
Основная проблема в том, что это несимметричная реактивная нагрузка с большой долей высокочастотных гармоник, которые из-за небольшой разницы в частоте ШИМ никогда не взаимоуничтожат друг друга. Да, среднеквадратичный ток возрастет всего в 1,4 раза, но пики будут огромные.
Насчет счетчиков я бы тоже не был столь уверен — в следующем году энергетики начнут ставить свои «умные» счетчики в том числе и с непрерывным подсчетом коэффициента мощности и непрерывной подачей показаний в сбытовую компанию. Потому вопрос «когда начнут брать штрафы за низкий коэффициент мощности» становится чисто делом принятия подзаконного акта.
В 2020 за коэффициент мощности ниже 0,8 нужно по-хорошему снижать баллы.
Иначе по мере распространения таких ламп все чаще и чаще будет отгорать ноль в многоэтажках.
OpenVPN торомоз.
IPsec полностью реализован в ядре, потому трафик при cipher и auth == NULL будет только получать заголовок туннельного режима и UDP от NAT-T. То есть все как у вас, только стандартное и работает со всем оборудованием и ПО, что умеет IPsec в туннельном режиме, а не только со свежим Linux.
Насчет неприязни — это за счет сложности устройства этого стека протоколов, зато после понимаешь что он позволяет делать очень гибкие вещи. Ну да и ладно, я просто рассказал, что уже давно есть 1-в-1 альтернатива, которая стандартна и работает.
Почему бы не взять IPsec с NAT-T с cipher и auth == NULL? И не нужно костылей, а если тяготит IKE, то можно через setkey из racoon статикой все забить, а то и вообще через ip xfrm.
Любой фрагментированный ICMP echo, и получаем kernel panic или перезапись памяти ядра.
Не помешает изучить зачем нужны и как работают skb_header_pointer(), skb_copy_bits() и skb_may_pull().
Déjà Vu: lwn.net/Articles/225946
Это несомненно. Причем даже несмотря на путающиеся показания участников событий, во всех также явно прослеживается огромная доля случая.
Могу привести цитату из Радио 2@2004, страница 10 (Мемуары о битве систем цветового вещания):
"… А кто «виноват» в том, что у нас была принята система SECAM? Года два наза бывший главный инженер МНИТИ Лев Гаврилович Семенов (умер в 2002 г.) сказал автору этих строк: — «Ты знаешь, ведь это я принял систему SECAM:» — «Как это?» — «А очень просто. Позвонили из министерства и сказали: — »Что-то там затянули с принятием цветового стандарта. Отправляйся в Париж и разберись". — Я полетел туда и подписал какую-то бумагу". Так у нас и появилась система SECAM".
Кстати с точки зрения сегодняшнего дня очень любопытно на все это смотреть еще и в том плане, какую позицию занимала официальная печать (скажем, журнал Радио и МРБ) в те года по поводу систем передачи цвета.
Если в конце 1950-х/начале 1960-х были рассказы только о NTSC и ее технических достоинствах, аккуратно и вскользь упоминая про требования к точности фазы (ну хотя бы МРБ 358@1960 или Радио за 1959), то после середины 1960-х резко пошли выпуски с критикой NTSC и пропагандой SECAM (как яркий пример МРБ 646@1967) :)
Тысяча телеков при вещании только в Мск — ну это явно тестовая установочная база для «своих», причем я почти уверен, что и телепередач в цвете тогда был как кот наплакал и в основном они показывали монохромный сигнал. :)
Там же еще недавно был переход от 441 линии развертки (опытное вещание было аж с середины 1930-х) к 625, но при этом эпоху с 441 линией тем более сейчас никто не вспоминает всерьез.
А еще была опытная станция с утроенной частотой полей и вращающимся диском-цветоделителем, и она тоже вещала заметное время.
Так что да, формально NTSC был, но у early adopters есть карт бланш на любые пробы — они как правило или приживаются, или о них кроме историков техники никто не помнит.
Ну и УКРМ для несимметричной нагрузки с большой долей ВЧ-гармоник это не просто тройка дешевых вечных конденсаторов; также сомневаюсь что УК захочет (и кто-то сможет ее заставить) выделять на это деньги.
царского режима^W Эдисона и использовать LED-панели с импульсным БП с коррекцией коэффициента мощности. И вот внезапно оказывается что все уже давно решено и придумано.Насчет счетчиков я бы тоже не был столь уверен — в следующем году энергетики начнут ставить свои «умные» счетчики в том числе и с непрерывным подсчетом коэффициента мощности и непрерывной подачей показаний в сбытовую компанию. Потому вопрос «когда начнут брать штрафы за низкий коэффициент мощности» становится чисто делом принятия подзаконного акта.
Иначе по мере распространения таких ламп все чаще и чаще будет отгорать ноль в многоэтажках.
Model Family: Seagate Barracuda 7200.11
Device Model: ST3640323AS
Firmware Version: SD1B
...
4 Start_Stop_Count 0x0032 099 099 020 Old_age Always - 1534
...
9 Power_On_Hours 0x0032 012 012 000 Old_age Always - 77223
IPsec полностью реализован в ядре, потому трафик при cipher и auth == NULL будет только получать заголовок туннельного режима и UDP от NAT-T. То есть все как у вас, только стандартное и работает со всем оборудованием и ПО, что умеет IPsec в туннельном режиме, а не только со свежим Linux.
Насчет неприязни — это за счет сложности устройства этого стека протоколов, зато после понимаешь что он позволяет делать очень гибкие вещи. Ну да и ладно, я просто рассказал, что уже давно есть 1-в-1 альтернатива, которая стандартна и работает.
git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200911&id=e3037485c68ec1a299ff41160d8fedbd4abc29b9
Если 8822b — это он, то вам тогде проще поставить mainline kernel kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.9 посвежее, чем поддерживать непонятного свойства OOT-модуль.
Не помешает изучить зачем нужны и как работают skb_header_pointer(), skb_copy_bits() и skb_may_pull().
Déjà Vu: lwn.net/Articles/225946
Могу привести цитату из Радио 2@2004, страница 10 (Мемуары о битве систем цветового вещания):
"… А кто «виноват» в том, что у нас была принята система SECAM? Года два наза бывший главный инженер МНИТИ Лев Гаврилович Семенов (умер в 2002 г.) сказал автору этих строк: — «Ты знаешь, ведь это я принял систему SECAM:» — «Как это?» — «А очень просто. Позвонили из министерства и сказали: — »Что-то там затянули с принятием цветового стандарта. Отправляйся в Париж и разберись". — Я полетел туда и подписал какую-то бумагу". Так у нас и появилась система SECAM".
Если в конце 1950-х/начале 1960-х были рассказы только о NTSC и ее технических достоинствах, аккуратно и вскользь упоминая про требования к точности фазы (ну хотя бы МРБ 358@1960 или Радио за 1959), то после середины 1960-х резко пошли выпуски с критикой NTSC и пропагандой SECAM (как яркий пример МРБ 646@1967) :)
Там же еще недавно был переход от 441 линии развертки (опытное вещание было аж с середины 1930-х) к 625, но при этом эпоху с 441 линией тем более сейчас никто не вспоминает всерьез.
А еще была опытная станция с утроенной частотой полей и вращающимся диском-цветоделителем, и она тоже вещала заметное время.
Так что да, формально NTSC был, но у early adopters есть карт бланш на любые пробы — они как правило или приживаются, или о них кроме историков техники никто не помнит.