aktuálně se staví na 9. generaci. Poslední xeony E jsou 9. generace (coffee lake refresh) :-)
Vlastně mají pravdu, od haswell tedy 4. generace bývali problémy. Haswell/Broadwell přinesl spoustu věcí a mimo jiné i brutálnější úsporný stavy. Jsou to první klasický procesory co umějí idle kolem nebo pod 0,1W resp. umí se přepínat za chodu když nemají co dělat až tak nízko že kolem toho vznikla aféra s horšími zdroji který s tak nízkou spotřebou nepočítaly a vypnuly se když neměly adekvátní odběr na P4 konektoru a naopak se zase dokázaly tak rychle probouzet z nízkýho stavu na maximálku že to některý zdroje nestihly kompenzovat a vypnuly se. Zároveň s tím vznikl problém v linux kernelu a musela se do kernelu přidat podpora haswellu aby ho kernel dokázal správně používat.
Na mikrotiku se stávalo to, že třeba za 2 hodiny provozu se rozblikal ethernety jako když se znovu inicializuje eth karta a konkrétně testovaná SGP-i4 blikala jak vánoční stromeček furt dokola. Asi se to nedokázalo samo zinicializovat nebo znova nahodit komunikace, netuším. Jenom vím že to dělal haswell a novější a taky to dělal například i ten Atom avoton ty první 8core atomy. Stejný problém. Stejné blikání eth karty. Aha, stejný nový stav CPU :-) Bohužel jsem nikdy nestihnul připojit IPMI nebo mít tam monitor, vždy to bylo na živý síti bez možnosti experimentování.
Abych to upřesnil, naše hlavní GW jede stále na starším xeonu a konkrétně na xeonu na haswellu :-D
Já sem totiž našel způsob jak je udržet v chodu a to na supermicro deskách jednoduchým způsobem. Vím že to mají i nějaký desktopy ale konkrétně u supermicro desek je v biosu položka "Package C-state limit" tedy omezení C stavů pro procesor. A to konkrétně na "základní" stavy C0 a C1. Základní stavy který nevypínají části procesoru ale pouze vkládají "nic nedělající" "chladící" smyčky do kódu fungující už z dob 486. Intel samozřejmě přidává podtaktování, podvoltování CPU ale to si dělá sám automaticky i bez OS a dalších stavů atd.. ale nemělo by to to vypínat části CPU až do totálního vypnutí nebo části cpu posílat do hlubších stavů "idle" jak to dělají další C stavy.
Ono to má vliv i na ostatní věci kolem CPU včetně třeba APIC kterému se snižuje výkon nebo dokonce i uspává. Což asi bude ten problém.
A najednou vše chodí jak má. Na všech routerech co mi projdou pod rukama omezuji c-state na C0-C1. Podle testů konkrétně na mikrotiku jsem v idle (kdy je jenom naběhlej mikrotik) naměřil minimální rozdíl ve spotřebě proti "full enable C state" což je asi tím že ty nový stavy použít neumí protože ve windows má stejný železo menší spotřebu a windows nový stavy umí. Nicméně to pro router není překážka, není žádoucí aby router musel při nízký zátěži "uspávat" a "probouzet" části cpu protože to samozřejmě zvyšuje latenci systému. C0/1 je tak ideální stav pro router. Skylake, 6. generace, to zvyšuje na další úroveň a přesto že mám stále omezený stavy na C0/1 tak se přibližně o další polovinu zlepšila spotřeba v idle a v nízký zátěži takže žádnej problém.
Po republice běží spousta routeru 4. 5. 6. 7. 8. 9. generace, všechny s omezením na max C1 stav a není problém. Možná by to mohlo být povoleno až do C6 ale to nehodlám riskovat. Je to router, maká pořád a má makat pořád, většina z těch routerů beztak má průměrnou spotřebu menší než CCR1036 takže pohodička :-)
Takže za mě zkus i na 10. generaci omezit cpu na c0/c1. i ten screen napovídá že by to mohlo být ono.
Je trochu divný že x86 už není x86, že? Ale tak jasně, proto tu je bios kde se to dá dostat do určitých mantinelů starších dob. Mikrotik nejspíš taky ví, že od haswellu dál mikrotik v nabídce pci prakticky nepozná skoro žádný zařízení, u všech je unknown. Kernel je prostě nezná. Ale ničemu to evidentně nevadí a maká to což je hlavní.
sorry za nudný článek :-) nejsem člověk co se spokojí s tím že tak něco prostě je a nevědět detaily kolem toho.