From 2733251c00a2d48097f01ab85ab69e00cd8d9bd2 Mon Sep 17 00:00:00 2001 From: Marius Date: Thu, 27 Aug 2026 16:29:54 +0300 Subject: [PATCH] docs(ups): rezultatele testului de autonomie de 15 minute Al doilea test cu scoaterea din priza (16:08:03 -> 16:23:04, 15,0 min). Autonomia tot nu e masurata - gauge-ul a coborat doar 90% -> 80% - dar testul raspunde la intrebarea "pe ce criteriu se opreste serverul". Trei constatari, toate cu date in document: (a) Procentul nu are panta pe care sa se poata extrapola: imobil la 90% timp de patru minute, apoi 0,8, apoi 2 puncte/minut. Extrapolarea de la minutul 8 dadea 220 de minute pana la pragul de 35%, cea de la minutul 14 dadea 22. (b) Saltul de la revenirea curentului se reproduce la aceeasi valoare (65%) in ambele teste, dar NU poate opri serverul: blocul de decizie e inauntrul ramurii if ($r.OnBattery), iar saltul se produce dupa revenire. Corectez aici ce scrisesem in commit-ul anterior - riscul nu e oprirea inutila, ci opusul: gauge-ul ramane optimist cat timp bateria chiar se descarca. (c) BatteryLifeTime e numaratoare inversa, nu masuratoare: 901 secunde scurse, 872 scazute din estimare (raport 0,97, verificat la trei puncte). Nu aduce nimic peste cronometrul propriu al scriptului, deci shutdownAtRuntimeSeconds ramane dezactivat - contrar directiei propuse dupa primul test. Concluzie: timpul pe baterie ramane criteriul principal, procentul ramane plasa secundara grosiera. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS --- docs/ups-server36-monitorizare.md | 80 ++++++++++++++++++++----------- 1 file changed, 51 insertions(+), 29 deletions(-) diff --git a/docs/ups-server36-monitorizare.md b/docs/ups-server36-monitorizare.md index b8da34b..74bea8f 100644 --- a/docs/ups-server36-monitorizare.md +++ b/docs/ups-server36-monitorizare.md @@ -175,11 +175,12 @@ powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\ups-monitor.ps1 | `-Mode TestShutdown` (dry-run) | secvența parcursă integral; Oracle a rămas `Running` | | Pierderea comunicației (`test-comms-loss.ps1`) | dispozitiv oprit 15:24:44 → alertă **15:26:44** (exact 8 cicluri × 15 s) + email; reactivare → „comunicația a revenit" + email; `Win32_Battery` înapoi la 1 instanță | | Taskul rulează ca SYSTEM | proces `ups-monitor.ps1 -Mode Run`, `state.json` actualizat la fiecare ciclu | -| **Trecerea reală pe baterie** (scos din priză, 15:47:45 → 15:50:46) | tranziția s-a văzut instantaneu în ambele sensuri; email de pană la 15:47:55, email de revenire la 15:50:56 | +| **Trecerea reală pe baterie**, de două ori (3 min de la 15:47:45, apoi 15 min de la 16:08:03) | tranziția s-a văzut instantaneu în ambele sensuri, la ambele teste; emailuri de pană și de revenire la fiecare | -Toate cele patru ramuri de alertare au emis email. Testul cu scoaterea din priză a durat doar -trei minute — prea puțin pentru autonomie, dar suficient cât să valideze semnalul de sursă și -să descopere problema gauge-ului (secțiunea 6, punctul 1). +Toate cele patru ramuri de alertare au emis email. Cele două scoateri din priză n-au măsurat +autonomia — în cincisprezece minute gauge-ul a coborât doar 90 % → 80 % — dar au validat +semnalul de sursă și au arătat de ce pragul pe procent nu poate fi criteriul principal +(secțiunea 6, punctul 1). ### Testul „pe baterie", fără scoaterea din priză @@ -338,39 +339,60 @@ nu are constrângerea asta. Pragul corect e „autonomia măsurată minus durata opririi, cu marjă". Până când ambele sunt măsurate, pragurile rămân o presupunere rezonabilă, nu o garanție. - **Ce s-a aflat pe 27.08.2026, dintr-o scoatere din priză de trei minute:** autonomia n-a - fost măsurată — trei minute sunt prea puține, iar singura cifră existentă rămâne estimarea - proprie a UPS-ului, ~70 de minute, nevalidată. S-a aflat însă altceva, mai important. + **Ce s-a aflat pe 27.08.2026, din două scoateri din priză** (3 minute, apoi 15 minute): + autonomia tot **nu e măsurată** — în cincisprezece minute gauge-ul a coborât doar de la + 90 % la 80 %, deci punctul de oprire nici nu s-a apropiat. Singura cifră existentă rămâne + estimarea proprie a UPS-ului, ~70 de minute, nevalidată. S-au aflat însă trei lucruri care + schimbă alegerea criteriului. - **Gauge-ul de procent al acestui UPS nu e de încredere.** Pe baterie a scăzut lent și - monoton (100 % → 96 % în trei minute), dar la revenirea curentului a sărit haotic: + **(a) Gauge-ul de procent nu are o pantă pe care să se poată extrapola.** În testul de 15 + minute a stat blocat pe loc patru minute, apoi a accelerat de aproape zece ori: + + | Interval | Pantă | + |---|---| + | 16:08 → 16:12 (4 min) | **0** puncte/min — imobil la 90 % | + | 16:12 → 16:17 | 0,8 puncte/min | + | 16:20 → 16:23 | **2** puncte/min | + + Extrapolarea făcută la minutul 8 dădea „pragul de 35 % vine peste 220 de minute"; cea de la + minutul 14 dădea 22 de minute. Aceeași baterie, aceeași sarcină, zece minute distanță. + + **(b) La revenirea curentului sare haotic — reproductibil, la aceeași valoare.** Ambele + teste, independent: ``` - 15:50:26 baterie 96% - 15:50:46 rețea 65% <- revine curentul - 15:51:06 rețea 75% - 15:51:46 rețea 90% + test 1: 96 % -> 65 % -> 75 % -> 90 % în ~100 s + test 2: 78 % -> 65 % -> 70 % -> 75 % în ~45 s ``` - 96 → 65 → 90 în 100 de secunde. Nicio baterie nu se încarcă 25 de puncte în 80 de secunde, - deci nu e încărcare — e recalibrare, sau zgomot în jurul tranziției. (La 12 minute după test - gauge-ul era tot la 90 %.) + Nicio baterie nu se încarcă 25 de puncte în 80 de secunde; e recalibrare, nu încărcare. + **Acest zgomot nu poate opri însă serverul**: tot blocul de decizie a opririi e înăuntrul + ramurii `if ($r.OnBattery)` (`ups-monitor.ps1`), iar saltul se produce după revenirea + curentului, când ramura nu se mai execută. Pericolul real e opus și e demonstrat de punctul + (a): gauge-ul **rămâne optimist** cât timp bateria chiar se descarcă — opt minute și + jumătate blocat la 90 % — deci un prag pe procent reacționează prea târziu, nu prea devreme. - **Consecința pentru configurația actuală:** pragul de **35 %** se sprijină exact pe numărul - ăsta nesigur, iar garda de confirmare (`confirmPolls = 3`, adică 45 s) e **mai scurtă decât - fereastra de zgomot observată (~80–100 s)**. Riscul e în ambele sensuri: o citire aberantă - sub 35 % ar putea opri inutil baza de producție, iar una optimistă ar putea întârzia - oprirea. + **(c) `BatteryLifeTime` nu e o măsurătoare, e o numărătoare inversă.** În testul de 15 + minute au trecut 901 secunde, iar estimarea a scăzut cu 872 — raport 0,97, verificat și la + două puncte intermediare (240/240 s și 871/872 s). UPS-ul fixează o valoare la începutul + penei și scade timpul scurs din ea. Nu aduce nicio informație peste cronometrul propriu al + scriptului, iar dacă estimarea inițială e greșită, numărătoarea e greșită cu exact aceeași + eroare până în secunda în care se stinge. - Semnalul de **sursă** (`ACLineStatus`) a fost, în schimb, impecabil — tranzițiile s-au văzut - instantaneu în ambele sensuri. De aici, direcția pentru pragurile definitive: + Semnalul de **sursă** (`ACLineStatus`) a fost, în schimb, impecabil în ambele teste — + tranzițiile s-au văzut instantaneu în ambele sensuri, iar emailurile au plecat la fiecare. + De aici, direcția pentru pragurile definitive: - - **timpul pe baterie devine criteriul principal**, fiindcă se sprijină pe `ACLineStatus`; - - procentul rămâne doar plasă secundară, cu valoare mai mică și cu `confirmPolls` crescut - peste fereastra de zgomot (≥ 8 cicluri = 2 min); - - de evaluat `BatteryLifeTime` ca al treilea criteriu — în acest test a scăzut lin și - monoton, spre deosebire de procent. Există deja `shutdownAtRuntimeSeconds` în - `config.json`, momentan `0` = dezactivat. + - **timpul pe baterie rămâne criteriul principal**, fiindcă se sprijină pe `ACLineStatus`, + singurul semnal care s-a purtat impecabil; + - **`shutdownAtRuntimeSeconds` rămâne `0` (dezactivat)** — punctul (c) arată că ar fi doar + al doilea nume al aceluiași cronometru; + - procentul rămâne plasă secundară grosieră. Nu are rost coborât mult sub 35 %: fiind + optimist, nu aberant, el oricum nu declanșează primul. + + Ce ar schimba concluzia: o măsurătoare dusă până la o descărcare adâncă, unde s-ar vedea + dacă gauge-ul se prăbușește brusc spre final. Pe o bază de producție asta nu se face fără + fereastră de mentenanță. 2. **Vârsta acumulatorilor.** Necunoscută. Pe cluster există deja criteriul de vârstă în testul lunar (`proxmox/cluster/ups/`); aici nu există nimic echivalent. 3. **BIOS: *Restore on AC power loss*.** De verificat la prima intervenție fizică — altfel