Pāriet uz saturu

Placebo tests: vai smalkie reģistra iestatījumi nomāc fona aktivitāti

Šajā lapā

Nē. 17 “smalkie” reģistra parametri, ko optimizācijas ceļvežos apraksta kā fona aktivitātes slāpēšanu, nesamazināja kopējo fonu: reģistra un failu operācijas palika tīro stundu dabiskās izkliedes robežās. Punktveida efekts pierādīts tikai diviem mehānismiem: LLMNR atslēgšana nullēja attiecīgos tīkla pieprasījumus, un telemetrijas grupa apturēja periodisko DiagTrack konfigurācijas aptauju (−98–99.8%). Vēl trīs parametri tika nolasīti, bet novērojamo efektu nedeva.

Statuss: izmērīts vienā A/B ciklā ar četrām kontroles stundām uz Windows 11 26H2 virtuālajā mašīnā. Spriedums “nav efekta” attiecas uz novērojamo dīkstāves fonu; parametriem ar garu darbības periodu mērījumu logs bija par īsu.

Viens vispārīgs: zināma 17 reģistra parametru kopuma piemērošana ievērojami samazina dīkstošas Windows fona aktivitāti. Plus 17 atsevišķi: vai katrs parametrs maina novērojamo uzvedību.

  • Windows 11 Pro, build 26300.9457 (26H2), virtuālā mašīna, nostabilizējusies sistēma;
  • 17 reģistra parametri no bieži ieteiktajiem: telemetrija, diagnostika, tīkli, saderība un meklēšana;
  • logs ar parametriem: 9.2 minūtes pēc 3 minūšu stabilizācijas; kontroles tīrais logs ar tādu pašu ilgumu plus četras papildu kontroles stundas tajā pašā palaišanā;
  • metrikas: procesu un pavedienu palaišanas, reģistra, failu un tīkla operācijas pēc kodola trasēšanas;
  • visi parametri piemēroti vienlaikus un atjaunoti uzreiz pēc mērījuma.

Netika pārbaudīts: scenāriju slodze (instalēšana, atjauninājumi, lietotņu darbs), parametri ar darbības periodu garāku par logu, fiziskā aparatūra un citi buildi.

Stingrs A/B vienā ielādes ciklā: logs ar piemērotajiem parametriem pret tīru logu ar vienādu ilgumu, plus četras kontroles tīrās stundas dabiskās izkliedes novērtēšanai. Kodola trasēšanas notikumi sagrupēti pēc procesiem; pavadošais monitorēšanas troksnis izslēgts. Likmes normalizētas uz minūti; izturībai pret uzliesmojumiem salīdzinātas minūšu summu mediānas bez pirmās minūtes.

Metrika Ar parametriem Tīrais logs Tīrās stundas (izkliede) Spriedums
Procesu palaišanas/min 2549 2601 2601 paritāte
Reģistra operācijas/min 14235 14780 14394–18951 izkliedes robežās
Failu operācijas/min 3098 4472 3251–4472 izkliedes robežās

Fona stundu dabiskā mainība (līdz 28% pēc reģistra) ir lielāka par jebkuru kopuma efektu. Neapstrādātās deltas “−13% reģistra” un “−53% failu” izskaidrojamas ar novērojuma pirmās minūtes uzliesmojumu, nevis parametriem.

Mehānisms Rezultāts Pierādījums
LLMNR atslēgšana (multicast nosaukumu izšķiršana) LLMNR pieprasījumi: 17.8–20.7 uz 10 minūtēm visās tīrajās stundās → 0 nejaušības varbūtība zemāka par 1e-7; pāra mDNS pieprasījums turpināja nākt
Telemetrijas grupa (AllowTelemetry ×2 + DiagTrack izkraušanas aizliegums) telemetrijas resursdatora aktivitāte: 131–1950 reģistra operācijas/min → 3 periodiskā telemetrijas konfigurācijas aptauja apturēta nekavējoties

Telemetrijas grupa tika piemērota ar trim parametriem vienlaikus, tāpēc atdalīt katra no tiem ieguldījumu šajā eksperimentā nav iespējams.

Parametrs Tika gaidīts Faktiski
mDNS atslēgšana mDNS pieprasījumu pārtraukšana biežums nemainījās: 35.9 uz 10 minūtēm pret 29.6–35.6 tīrajās stundās; vērtību nolasa pakalpojums
NetBIOS over TCP/IP atslēgšana NetBT pieprasījumu pārtraukšana kadence identiska: 16.8 pret 16.1–16.7 uz 10 minūtēm
Auto-DoH atslēgšana DNS pieprasījumu samazināšanās bez izmaiņām; šajā sistēmā auto-DoH jau tā nebija aktīvs

Desmit parametri palika bez sprieduma: četri WDI diagnostikas netika nolasīti logā, to darbības intervāli ir garāki par 9 minūtēm vai izpaužas tikai pie scenāriju slodzes; meklēšanas trasēšanas ierobežotāji ietekmē pašu meklēšanas kanālu, kas neietilpa uztveršanā; saderības un USB parametriem dīkstāvē nebija aktivitātes pārbaudei.

Svarīgs blakus fakts: parametru piemērošana politikas zaros pati pamodināja grupas politikas atjaunināšanu un lietotņu pakalpojumu — vienreizēja “piemērošanas cena”, kas īsā logā izskatās kā aktivitātes pieaugums.

  • Izmērīts: kopēja fona operāciju samazināšanās nav; likmes ar parametriem atrodas tīro stundu izkliedes iekšienē.
  • Izmērīts: LLMNR atslēgšana pilnībā pārtrauc LLMNR pieprasījumus, neskartot mDNS un NetBIOS.
  • Izmērīts: telemetrijas grupa aptur periodisko DiagTrack konfigurācijas aptauju (−98–99.8% resursdatora aktivitātes).
  • Novērots: mDNS un NetBIOS parametrus pakalpojums nolasa, bet novērojamo efektu tie nedeva.
  • WDI, saderības, USB un meklēšanas ierobežotāju parametru efekti: logs vai novērošanas kanāli nederēja.
  • Katra telemetrijas parametra ieguldījums atsevišķi.
  • Uzvedība citos buildos un fiziskajā aparatūrā.
  • Jebkādi efekti zem slodzes: tika mērīta tikai dīkstāve.

Viens logs uz stāvokli bez secības randomizācijas. Windows fona mainība ir liela, tāpēc secinājums par paritāti balstās uz četrām kontroles stundām, nevis uz vienu logu pāri. Daļa plānotāja žurnālu pārstāja rakstīt notikumus parametru loga laikā; plānotie uzdevumi, kas nostrādāja šajā laikā, redzami pēc procesiem, bet ne pēc žurnāla. Punktveida spriedumi (LLMNR, telemetrija) ir noturīgi: efekts ir visās kontroles stundās un nullējas parametru logā.

Dalījums starp “parametrs tiek nolasīts” un “parametrs pārvalda uzvedību” — galvenais. No 17 pārbaudītajiem iestatījumiem tikai divas grupas patiešām maina novērojamo uzvedību, un abām ir savi štata vadības punkti: LLMNR BoosterX aizver iestatījums “Vietējo nosaukumu izšķiršana”, telemetriju — “Telemetrija datu vākšanas politikā” kopā ar “Fona ETW autologgeriem”. Pārējo dīkstošas Windows fonu rada Defender, WMI, licences pārbaudes un Store — to “smalkie” reģistra parametri šajā kopumā tos neslāpē.

Saistītie materiāli: pētījums “Klusā dīkstāve” parāda, kas patiešām samazina fonu; “Darbvirsma pret pieteikšanās ekrānu” izskaidro, no kā sastāv atlikušais troksnis.

Visi 17 lielumi atjaunoti uzreiz pēc mērījuma apturēšanas; veiksmīga atgriešanās fiksēta ar momentuzņēmumiem. Sistēma netika pārstartēta pirms atjaunošanas.

Mērījumus veica BoosterX Research aprakstītajā virtuālajā mašīnā. Pētījums pieder BoosterX izstrādātājam, tāpēc izstrādātājam ir tieša interese par rezultātu; metodika un robežas aprakstītas iepriekš, secinājumus var pārbaudīt pēc atklātās metodikas.

Pēdējā pārbaude: 2026-09-22.