Блін, індустрія RC возик на колесах нормальний зробити не можуть, їздять зі швидкістю равлика, ну і десь така ж сама маневреність, через що запоребріком куча відео як їх вибивають дронами разом з вантажем, а ці про гуманоїдів марять. Ну а як їх не вибивати, коли воно плететься 5км на годину і ні вправо ні в ліво не може звернуть, не зупинившись? Навіть зліпити два електросамоката в одну раму, поставити серву на руль, трансмітер і китайську IP камеру це вже в індустрії коштує мінімум сотні тисяч гривень, які там гуманоїди.
market-brave1.delta.mil.gov.ua/lohistychni-kolisni
Мільйон за возики без підвіски...

Мета — зрівняти умови для локального й міжнародного бізнесу та збільшити бюджетні надходження

Влада так радіє, наче це вони не в карман до українців залізли, а країна заробила шляхом законодавчої стимуляції відкриття нових бізнесів з високою доданою вартістю та ефективністю праці, через що збільшилась податкова база.
Це як з оподаткуванням посилок з Аліекспрес- захист національного виробника пк, комплектуючих, смартфонів, планшетів, Raspberry pi та електронних компонентів. Бо бюджет «втрачає» скільки то там мільярдів. По факту торгашам, які нічого не виробляють і не збираються, важко перепродавати китайське з націнкою в 300-500%, через що на зеленому сайті не можна в коментарях обговорювати цінову політику. Як це ще влада не бідкається що бюджет недоотримує через дармове повітря.

Так його драйвер 99% там через ШИМ на виході, а не встановлення константного вихідного струму, і працює. Тим більш навряд чи на 1,5МГц. Фіг знає нащо виробники роблять мікросхеми імпульсних LED драйверів, а потім замість виходу компаратору для підстройки струму ліплять просто вихід для gate, який модулює вихід драйвера. Наче той компаратор там так багато місця на кристалі займає.

Ну нехай собі там залежить. Людське око взагалі нелінійно сприймає яскравість, того для ШІМ і роблять матрицю з логарифмічною функцією, щоб з % яскравості перевести. Яка різниця яка там буде залежність?

спектр люмінофору нелінійно залежить від струму

І від температури теж. Ті проценти от прямо дуже важливі для ліхтарика.

DC-DC перетворювачі нестабільно працюють

Працювати на low-load з двома PFM та PWM режимами його призначення, там 1.5МГц, ну і це все ще ліхтарик. В будь-якому випадку нічого там не свистить, навіть якщо з 400мА скидувати до ~0мА.

Навіть з дуже високою частотою, всеодно іноді може виникати мерехтіння.

І нафіга там взагалі ваша частота на світлодіоді? Просто buck DC-DC з керуванням вихідним струмом через опорну напругу, яку знімієш з інтегратора після ШІМ. Коли почались блекаути і бариги офігіли, я на колінці ламп таких наплодив, точніше прокачав китайські. З «вартості» там копійчаний mt3406, зате високий ККД, відносна стабілізованість світлового потоку, ніякого мерехтіння і «аналогове» керування яскравістю.

Ну і як там порахувати схожість того коду? Можна попереставляти умови, чи інвертовувати їх, записати іншими операторами, переіменувати змінні, композиція-декомпозиція по модулях та функціях. Де буде межа? А в рамках одного репозиторію взагалі неясно як там визначати немайнове право авторства між членами команди.

Ну мабуть те, що він стрибає то ж не зовсім те- так «потік» передачі один. Якщо попало на серйозну перешкоду, це втрата пакета, лаг. Якщо двостороння передача і корекція помилок не допомогла, то це повторна пересилка пакету, в залежності від правил QoS, якщо одностороння то дроп. Чогось я підозрюю, що розширювати умовно безкінечно спектр і стрибати по каналах не можна, як мінімум бо радіотракт, включаючи антену, не настільки широкосмуговий, та і мабуть мають підвищуватися вимоги до синхронізації і швидкості ADC/DAC. По логіці задається надійнішим мати декілька окремих трансмітерів, радіотракти яких заточені під певну смугу з каналами, які працюють паралельно через якийсь хаб, і вже самі там стрибають з розширенням спектру- хоч хтось та має успішно доставити окремо взятий пакет. Хіба це не ускладнило би ще глушіння і не підвищило вимоги до РЕБ?

Давно було цікаво, чи не використовують там ще передачу пакета по декількох передавачах на різних діапазонах одночасно, щоб хоч по одному та долітав?

Додайте краще зберігання тексту невідправленого коментаря на клієнті, а то таймаут і пиши свою простиню заново + кнопку виходу з режиму редагування. Esc взагалі нічого не робить.
А як піде п’янка, то і завантаження картинки drag&drop чи буфера, як це в фейсбуці і навіть у запорєбрікових років 15 як.

а ось тут вже вивільнення event loop та розбивка обробки на етапи, між якими, власне, буде вивільнятися event loop для інших задач — може не вписатися в мілісекундні обмеження.

Ну так ми ж це все одно не контролюємо, якщо в коді є асинхронний виклик, а все там наведене в того пана типу обробки зображень це вже мінімум IO до файлової системи, а сама обробка одного файлу навряд чи займає якийсь помітний час. Якщо мова про оверхед при розбитті синхронного коду на чанки і прокрутка лупу, то тут вже ми можемо практично самі контролювати скільки часу ми можемо приділити виконанню синхронної задачі «без розриву» щоб максимально швидко її закінчити в залежності на скільки допустима затримка опитування. Але ж і розбивати задачу в 1мс щоб прокрутився луп немає смислу. Все одно ж це вже фактично черга запитів- може ми в умовну 1мс вкладемося для поточного запиту, тільки наступний такий же важливий запит все одно вже чекає в черзі і для нього з точки зору запиту вже час пішов, а якщо там важливі затримки між операціями всередині запиту то ми ж втрачаємо контроль на як тільки з’являється асинхронна операція. Так що ці питання це до архітектури і балансирів, щоб сервіс не був перевантажений і латенсі не вилізав, хоча дива все одно не станеться.

оціни максимальну пропускну здатність одного інстансу для ноди і го

Божечки, вже Го приплили 😁 Ви зробили просте і таке ж помилкове твердження що cpu-heavy блокує івентлуп в Ноді, і це обходиться [тільки] скейлінгом процесів. Тепер намагаєтесь виїхати на питаннях порівняння продуктивності Go та Node. Здавалось би яке відношення має інша платформа до принципу роботи івентлупа і написання коду з cpu-heavy для ноди, але ні- давайте будемо порівнювати продуктивність та використання пам’яті в ГО та Ноді.

оціни максимальну пропускну здатність одного інстансу для ноди і го

Це геніально. Порівнювати один інстанс динамічно типізованої скриптової платформи з JIT компілятором з компільованою типізованою мультитредовою мовою, хоч і теж з GC але ж типізованим, це взагалі сильно. І головне, взагалі немає ніякого відношення до початкової теми.

Ще одна спроба з гачка зірватися 😁

очевидно в якому контексті сказано

А ну ж розкажіть в якому ще контексті було вами сказано, що так як нода однопоточна і cpu-heavy заблокує івентлуп, ноду скейлять через декілька процесів [як костиль] «але це ж не багатопоточність» ?

Давайте ще раз- ви стверджували що через cpu-heavy у вас блокувався би event-loop в ноді і це недолік платформи. Тобто в цьому контексті cpu-heavy це синхронна атомарна операція, через яку івенлуп не може дійти до стадії опитування, через що всі інші IO задачі фактично би блокувалися. Все що ви навели це не атомарна синхронна задача, а просто пакетна обробка.
Приклад синтетичної синхронної операції це розрахунок Фібоначі з десятків мільйонів «в лоб», яку все рівно можна написати асинхронно, тому блокування лупу не буде. Суть ноди в написанні алгоритмів асинхронно. Ви, як я відчуваю, пропонуєте наляпати синхронно алгоритм, щоб тоді казати, що мультитредова плафторма краще справиться з іншими конкурентними запитами, чим однотредова нода.

— обробка зображень

Це вся поверхня планети в одному зображенні з роздільною здатністю піксель на квадратний дециметр?

та відео

Ви те відео прямо в ноді декодуєте чи через IO і ffmpeg? А якби і в ноді, то теоретично воно б оброблялося стрімом, а не синхронним блокуючим алгоритмом, тобто івенлуп не блокувався.

RSA-підпис та масова генерація JWT

це RSA мільйонної біності? «Массова генерація», це знову не атомарна операція, а просто пакетна обробка, крім того сама криптографія використовує внутрішній пул потоків ноди.

та і загалом highload message processing, де на кожене повідомлення треба десеріалізація, валідація та маршрутизація

Це все в гіршому випадку десятки мікросекунд синхронного коду до виклику будь якої асинхронної операції з макротаскою в т.ч IO, тому блокування лупу знову не буде.

що це надто затягнеться)

Це точно, бо чули дзвін та не знали де він 😁

бувають різноманітні задачі і в тому числі CPU heavy.

Хотілося б приклад, що такого синхронного на JS ви там в процесі ноди ганяли

закинути її в чергу для обробки окремим сервісом, а клієнту просто одразу віддається згенерована айдішка задачі.

Це ви розповідаєте скоріше про long-running tasks, а не cpu-heavy. cpu-heavy в тому контексті, про який ви сказали на початку, це та синхронна задача, код якої блокує івентлуп процесу на час, який є неприйнятним, щоб вписуватись в максимально допустимий рівень затримки обслуговування інших запитів. Це не про довгі таски з IO.

на мою думку на співбесіді така відповідь виглядала б як ред флаг.

Скоріше ред флаг того, що людина не послідовна в своїх міркуваннях, бо ви почали з того, що однопоточність ноди це серйозне обмеження, бо

якщо закинути CPU-heavy задачу, просто заблокуєш event loop і все інше стане

Ну а я стверджую що не стане, бо в будь-якій синхронній задачі (якщо ви її таки знайдете) написаній на JS можна давати прокрутится івентлупу, що збереже відгук на інші IO. Тому тут навіть на рівні одного потоку цього обмеження фактично нема. Делегування ми тут не чіпаємо, бо це вже про архітектуру.

такий підхід має більший оверхед у порівнянні з thread pool в джаві чи .net

І в чому ж? Скільки тих процесів ноди на сервері щоб «копія ноди» в кожному була оверхедом? Нащо вам спільний heap, якщо нема ніякого смислу розмазувати обробку запиту по декількох тредах, бо в реальності немає вільних ядер, так як навантаження балансується зовні процесу, а переключення контексту і всілякі міжпотокові синхронізації для доступу до спільних даних — це вже оверхед, який не має смислу для виконання ізольованих запитів. Самий продуктивний варіант обробки запитів це по максимуму, на скільки можливо, його обробити в одному треді і ця концепція чудово кладеться на бекенд. Ну і один процес з мультитредами це безпекова неізольованість і ризик крашу всім процесом і різні підходи до скейлінгу на локальній машині і на кластері. Як би це був не бекенд, а скажімо якийсь відеокодек чи щось подібне, то так концепт багатопотоковості у ноді вже б був серйозною проблемою. Звичайно, там є API типу SharedArrayBuffer доступний для потоків, але це не буде те саме що в джаві з системними потоками і API синхронізації.

якщо закинути CPU-heavy задачу, просто заблокуєш event loop і все інше стане

Таких несинтетичних задач на беку немає, а якби щось знайшлося, то нічого не заважає час від часу явно давати івентлупу прокрутитися. Це якщо не делегувати задачу в інший процес, чи тред.

а не для того, щоб твій JS реально крутився паралельно

Ну і що значить паралельно? Код магічним чином не стає паралельним. Породити дофіга системних тредів та чекати синхронізації між ними на кожен чих? В ноді вже оптимальна модель багатопотоковості як для бека і їй та системна багатопоточність взагалі не потрібна і навіть шкідлива.

хоч наука несправжня, але клієнтські гроші цілком справжні.

Фіксувати це як стандарт дизайну мереж — ні

Це ж не про дизайн мереж, а про функціонал NAT — виставив в його налаштуваннях якийсь там «direct-dst» і нехай собі автоматично мапить на свою локалку з налаштувань мережі DHCP. Ні для кого нічого не змінюється.

Ось і виходить, що в загальному випадку на зовнішній стороні NAT має аллокувати по порту на кожне зʼєднання.

Там я вже нижче писав, що алокація вихідного порту ж не була б жорстко прив’язана до вхідного пулу, тобто 255 портів на локальний IP. В мережі активних хостів в кожен відрізок часу явно не 255, і взагалі їх там фізично може скільки не бути. DCHP бачить же активні хости і вільні пули портів. Але так, краще статично віддати половину під пул для мапінгу, а другу половину для вихідних і буде по 128 вхідних портів. Та навіть якби там було по 32 — все одно це краще, ніж 0, і коли заради того, щоб ззовні підключитися до своєї мережі, доводиться купувати виділений IP і використовувати там один чи два порти. Так що таке собі ущільнення мало б допомогти.

Не треба для цього ніякого оновлення NAT. Таким же чином, яким NAT зараз працює, він може працювати і далі. З тими же обмеженнями, які я пояснив трохи вище.

Тобто ніяк? Чи негри будуть руками прокидувати порти кожному абоненту?

В принципі неможлива функція, яка транслює множину з 65535*254 значень в 256 значень гарантовано без коллізій

Хм, ну наче ж там описав, що ніякого мапінгу аж на всі абонеські порти не було б, просто провайдерський NAT мапить умовні 255 зовнішніх портів на порт зі статичним зміщенням, наприклад, 5000- тобто ззовні можна було б достукатися тільки на порти з 5000-5255. Все. Нікуди більше. Ніякої складної трансляції. Далі якщо абонент хоче собі мапить на своєму роутері їх як хоче і куди хоче. Головне, що від провайдера прокинутий блок портів. А якщо це пк, то софт, наприклад, торрент, міг би перевірити ці порти на доступність ззовні і далі використовувати для обміну p2p.

А якщо треба прийняти щось на вебсервер на портах 80 чи 443?

Ззовні на 80 порт? Може купити виділений IP? А як на локальний 80 порт, то в абоненському роутері нема DST-NAT?

Визнайте, що ваші знання теми — нульові.

Я вже закінчував відповідь не для вас

Визнаю вашу безперечну і всеосяжну мудрість. Бути з вами на одному форумі велика честь, якої не достойний жодний смертний.

тобі дають цілі блоки які ти можеш в ідеалі використовувати для будьчого

Чудесно. Але мова була про те, що з IPv4 можна було досягти подібного «блоку» хоча б для домашніх користувачів і вивільнити адреси для корпоративних чи вибагливих користувачів. Куча провайдерських мереж і досі без підтримки IPv6, і куча грошей була витрачена на модернізацію. Та й сумнівний смисл цього блоку, якщо його треба буде зарізати на фаєрволі, щоб з КНДР не брутфорсили умовний смарт-унітаз з дирявою адмінкою.
Костиль вирішує дві основні взаємопов’язані проблеми — нестачу адрес і можливість вхідних підключень.

256 портів це критично мало

Ну, то ж 255 для вхідних з’єднань, а як там NAT буде шукати вільні порти для вихідних з’єднань, це вже інше питання. Не може ж бути прямо всі 255 хостів онлайн, щоб вичерпати пул. Та і це ж просто концепт, а не реальні числа, бо як мінімум не враховано зарезервовані сервісні порти роутера, хоча умовний 192.168.1.1 і так сам роутер. Можливо, половину портів NAT зарезервувати під пул вихідних з’єднань, а другу — на пул, щоб прокидувати по 128 портів в локальну мережу за NAT. 128 — це все одно добіса для побутового користувача, якщо зараз по суті нуль, якщо без всіляких там STUN.

одна вкладка в браузері може давати 10 зʼєднань одночасно = портів.

Там ліміт 6 одночасних, і це менш актуально для HTTP/2 через мультиплексування в один тунель на оріджн.

Але... покажи мені підʼїзд, де у всіх білі айпішки?

Та не так давно було, але років з 8 як уже забрали. В будь-якому разі у когось є динамічні білі IP на абонента, стане на умовних 30 і при цьому можна вже давати статичну, вже економія адрес. Той, хто купляв статичний просто заради вхідних підключень, наприклад, до NVR поза хмарою, теж зможе обійтися. А кому дійсно треба окремий вже купить.

Ну добре, а чому 256, а не 64 чи 1024?

бо зазвичай маска локальної мережі /24, тобто один байт на хост. Тому так- бо зручно.

А якщо у одного абонента нормально, що створюється 500 зʼєднань, а у іншого ніколи не буває більше 10?

До чого тут кількість з’єднань до портів, доступних до з’єднання ззовні? Чи у приватного абонента 500 серверів та по одному вхідному з’єднанню на кожен? Чи ви рахуєте вихідні з’єднання від абонента? 256 умовних [софтових] серверів запущених в абонента — це вже анріл.

А якщо за NAT більше 256 машин?

Ну а зараз як? Головне, що від провайдера автоматично прокинуті порти, а куди їх мапить роутер злиденної організації, яка не може дозволити собі з таким парком купити білий IP, то вже інша справа.

Все, що ви кажете, _може_ бути зроблено і з поточним NAT

Мова про те, що воно могло б робитися автоматично без ручного вбивання чи скриптів, щоб була домовленість і свій RFC , ну і виробники роутерів трохи обновили ПО NAT. Через це звичайним побутовим користувачам не доводилося б виділяти білу адресу (чи купувати статичну), значить, вивільнолося б багато блоків IPV4.

, через ALG чи з боку сервера

Нащо він тут, якщо фактично статично прокинуті порти?

2) конфлікт портів

Які ще конфлікти?

ціна тримання мапи трансляцій

Ніякої мапи. Я ж кажу, що виділяємо один (потенційно) байт з номера порту, який напряму транслюється в локальну адресу хоста. Тобто при зовнішньому підключені на 1.2.3.4:1026 роутер просто бере локальну маску з адресою 192.168.1.0/24 і підставляє 4 з першого байту порту виходить що ззовні стукають до локального 192.168.1.4, а порт (2) з другого байту + домовлене в RFC зміщення, скажімо на 5000, от і виходить що ззовні 1.2.3.4:1024 транслюється в 192.168.1.4:5002, а що вже там робить абоненьский роутер з цим то його справа. Це вже дає софту абоненського ПК можливість приймати підключення з інтернету, і він міг би легко виявити доступність цих портів автоматично.
Білий IP дає можливість зовнішнього підключення, а так би могли шарити один IP між невибагливими абонентами, і вони б все одно мали можливість підключення без складних костилів для VoIP, Torrent, HomeAssistant, IoT, IP камери і т.д. Їм все одно який там зовні буде порт, та і редірект можна автоматизувати. А компанії будуть собі використовувати вивільнені блоки IP і пула IPV4 б вистачило з головою для населення землі.