Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: [1] 2 3 ... 76
1
A mám pocit, že Intelovo TDP cca od 10. generace CPU je taková virtuální hodnota. Ve skutečnosti když dáte aktuálnímu 10nm Intelu za uši, tak si cucne výrazně víc než TDP. Některé modely o 50-100%.
Bylo by krásné kdyby Intel kecal jen on 50-100%.
Např. úsporný 35W Core i7-13700T si vezme až 106W, 65W modely si berou až 219W a tak podobně.
pěkná tabulka např. na https://diit.cz/clanek/v-tichosti-zacaly-prodeje-35w-core-13000t-raptor-lake

To mi cosi vysvětluje :-)
Možná už jsem to tady zmiňoval... na pracovišti, kde zahořujeme malé průmyslové počítače (pasivní žebrované cihličky a all-in-one paneláčky) máme centrální rozvod 24V DC. V každém odbočném kabelu je tavná autopojistka 3A. Kromě vyložených omylů nebo vadných počítačů nám ty pojistky nehoří. Asi protože počítač s běžným plnotučným "Core i5 moble" starších generací (typický pro tento mechanický formát) žere možná 50W když dostane za uši, spíš ale pod 30W.

No a přišla první vlaštovka s novým procesorem... což kluci v montáži ani moc nezkoumali. Po vybalení byl počítač normálně funkční, dalo se pohrabat v BIOSu, boot testovacího Linuxu po síti klapnul, kliknout na start stress-test a PRSK a tma.
Co to? Novou 3A pojistku, zopakovat postup... PRSK a tma. Až 5A pojistka na těch 24V vydržela. Kolik ten procík mohl mít TDP? Něco jako 25W ?

Jako než řešit analogii tohoto na procesoru Intel, který má nominální TDP = 65 W, se starým 300W zdrojem... o důvod víc, sáhnout spíš po AMD, u kterého pokud vím je na "obálku spotřeby" stále ještě relativní spoleh.

2
Ohledne VT-d, se prave jeste rozhoduji zda nejit spise do Intelu i3, ve stejne cenove relaci.
Protoze do ted jsem s tim procesorem nemel problem.

Heh :-)   - i3 bejvalo tradičně tak dvoujádro bez HT a bez turba. Koukám, že aktuální Alder Lake i3 je čtyřjádro bez HT s turbem. Máte pravdu, že to není marný procesor.
@Jimmyx tu zmiňoval dokonce osmijádro Ryzen 7 5700G.
Koukám na nějaký benchmark... i3-12300 vychází rychlejší ještě na čtyřech jádrech (i3-12100 nastejno jako R7 5700G), při osmijádrovém provozu vítězí R5700G o dvouciferná procenta. A to nevím, zda v tom benchmarku nějak zohlednili HT, což se hodí při velkém počtu vláken.

Na virtualizaci většího počtu instancí je vyšší počet jader jedině ku prospěchu.
A mám pocit, že Intelovo TDP cca od 10. generace CPU je taková virtuální hodnota. Ve skutečnosti když dáte aktuálnímu 10nm Intelu za uši, tak si cucne výrazně víc než TDP. Některé modely o 50-100%.
= já bych to AMDčko nezavrhoval :-)

Pokud se týče VT-d, tak závěr zmíněné debaty byl cca ten, že u Intelu právě v jednopaticové desktopové řadě jsou "IOMMU groups" v čipsetu hodně velké = granularita hodně hrubá, takže přidělovat jednotlivá on-chip zařízení různým virtuálům může být problematické. A že u AMD i tohle snad vypadá o něco líp.

Pravda je, že osobně jedu taky dodnes hlavně Intel, ale to je spíš setrvačností a konzervativismem oboru "průmyslových PC", ve kterém se pracovně pohybuji. Máte pravdu, problémů s Intelem je "minimum" (a radši už mlčím, abych to nezačal rozvádět.) Můj nový noťas na kancelářskou práci má šestijádro AMD.

3
Tohle už vypadá docela rozumně. Pokud se Vám vejde microATX board do té malé skříně.

Volba zda točivý disk nebo SSD je patrně věc subjektivního vkusu. Třeba u nás na pracovišti jsme ohledně toho poněkud ve při. SSDčko umí být fajnově rychlé, pokud mu nenaložíte moc - každopádně věnujte zvýšenou pozornost zálohám.

Procík má dvoukanálový řadič RAM - určitě doporučuji osadit moduly RAM po dvou, mj. i proto, že ta věc má integrovanou grafiku. Byla by škoda, omezit si průchodnost RAMky osazením pouze jednoho modulu.

Nechám na Vás, kolik těm virtuálkám chcete dávat RAMky. 16 GB mi nepřijde úplně horentně mnoho. Podle mého je v dnešní době 16 GB rozumná hodnota na Windows 10 desktop, pokud nechcete po spuštění několika dnešních rozežraných (vadných) aplikací narážet na kapacitu volné RAM. To je bez virtualizace.
Pravda taky je, že holý systém Win10 potřebuje za normálních okolností dodnes třeba 1-2 GB, a třeba linuxovému virtuálu na hraní by mohly stačit taky asi 1-2 GB, zejm pokud to nebudete přehánět s grafickým prostředím.

Ohledně virtualizace... nedávno tu proběhlo vlákno ohledně pokročilejší akrobacie s VT-d, ve finále se probírala granularita IOMMU groups, což má vliv na nezávislé mapování např. IRQ... někde v té souvislosti (možná v odkazech) se lidi bavili o konkrétních čipsetech Intel a AMD. Jsou to zřejmě věci, které se nedočtete ani v datasheetech čipsetů. Ale tohle téma Vás nejspíš trápit nebude, pokud nemáte v plánu, mapovat virtuálkám konkrétní PCI-e periferie.

4
...hele... sice ten procesor má 65W TDP. Pokud by v tom byla integrovaná grafika, tak by to wattáží asi i vyhovělo, pokud ten zdroj není nějak ošizený, což by nemusel. Pro takovou sestavu je tenhle zdroj určen.

Ale: ten procesor grafiku *neobsahuje*. Takže pokud do toho přijde grafika větší než úplně minimální (asi 40W), tak je poměrně pravděpodobné, že těch 300W nebude stačit té *grafice*. Mimochodem v této souvislosti vidím jako trochu problematickou "malou" skříň (není uveden model, ale soudím podle mechanického formátu zdroje = TFX). Trochu trnu ohledně toho, že deska má dva dlouhé sloty PCI-e = dumám, co přesně chcete spáchat s grafikou (grafikami). Jo kdybyste to dal do bedny s ATX zdrojem standardního mechanického formátu PS/2, tak získáte mnohem větší výběr napájecích zdrojů, a můžete si je dimenzovat podle grafiky.

Obecně doporučuji volit jmenovitou wattáž konzumního zdroje jako dvoj- až trojnásobek součtu maximální spotřeby CPU a grafiky (zbytek se dá v gamesním stroji vcelku zanedbat). Když se podívám na osazení sekundáru konzumních zdrojů kondíky, tak vcelku kroutím hlavou nad těmi jmenovitými wattážemi.

5
Pokud správně rozumím, iotop ukazuje IO per proces.
Zajímavý údaj by byl, IO zátěž per block device = kolik toho hrne jednotlivý disk.
Doporučuji nainstalovat balík "sysstat" a poté použít
iostat 2
Bude Vám v intervalu 2s zobrazovat okamžité MBps a IOps na jednotlivé disky, zvlášť čtení a zvlášť zápis.
Jednotlivý točivý disk má strop asi 75 IOps, pokud jsou seeky skutečně náhodně rozmístěny po plotně. (Pokud nejsou seeky od sebe moc daleko, tak víc.)

Na jakém filesystému jsou ty home adresáře na serveru umístěny? (Ext4, XFS, btrfs apod.) Konkrétně btrfs v defaultním nastavení se zapnutým COW nemusí být to pravé oříškové pro všelijakou zátěž, která neustále mění stávající soubory (dnešní WWW browsery si udržují historii a další věci v DB souboru...) Máte ve fstabu pro ten svazek opšnu "noatime" ? Pokud jako emailového klienta nepoužíváte mutt, tak to ničemu nevadí a ušetří Vám to spoustu IOps.

Na serveru bych zkusil razantně zvednout dirty_ratio (90), dirty_background_ratio (80), dirty_expire_centisecs (třeba 6000). Tzn. zvětšit softwarovou write-back cache před diskem a prodloužit její trpělivost. Kolik máte v serveru RAMky a jak je využitá? Hodil by se výpis /proc/meminfo. Pokud fileserver nemá nic moc jiného na práci než servírovat disky, tak je nesmysl, aby měl spoustu volné ramky (free/available). Pokud je síťový disk subjektivně pomalý, měl byste se snažit, aby server měl co nejvíc v kolonkách "buffers", "cached" a "dirty". Zajímavý je údaj, kolik je v kolonce "writeback". Pokud je to hodně, znamená to, že disk hrubě nestíhá zápis.

NFS jede dneska by default nad TCP - doufám jste ho nepřepnul na UDP.

Co za ethernet je od serveru až na switch v učebně? Je tam aspoň gigabit? Ten řádově odpovídá sekvenční průchodnosti jednoho točivého disku.

Startuje na klientech okamžitě nějaký soft po přimountování síťového NFS svazku (home adresáře)? Třeba nějaký indexer pro rychlé vyhledávání (patrně spíš omylem)... Už tu padla zmínka o keši webových browserů - ta je taky v home adresáři... Projeví se problém ve chvíli, kdy děcka na klientech začnou browzdat? Tzn zkusit ten iotop na klientech.

Na kernel command line (do grubu) bych přidal intel_idle.max_cstate=1 (pokud CPU je intel) a pokud se nebojíte, tak ještě mitigations=off. Ale od toho už si velký výsledek neslibujte. Latence ospalých C-stavů by pod zátěží měly naopak ztratit vliv.

Co jsou zač switche v té síti? Mají management? Pokud ano, dokážete zjistit, zda mají zapnutý 802.3x flow control? Pokud je tahle věc zapnutá, zkuste ji vypnout. Totéž taky na serveru. Není to tutovka, ale mohlo by to pomoct. Jedná se o poměrně primitivní mechanismus, který ne vždy funguje správně a ku prospěchu věci. V lepším případě nevadí...

6
Sítě / Re:2.5G ETH do 10G optiky
« kdy: 16. 05. 2023, 14:54:53 »

SERDES je už hotový bitstream užitečných dat, který má svou jmenovitou rychlost. Full duplex, jeden kanál sem, druhý kanál tam. SERDES nese fakt jenom ethernetový payload, nenese žádný inband dorozumívací "režijní kanál" multiplexovaný mezi užitečnými daty. SERDES je už téměř hotová fyzická vrstva - jenom blikat laserem do optického vlákna.

Nějakou režijní inteligenci navíc (=MDIO) má MII a jeho početné potomstvo, což je původně propoj mezi MAC a PHY.

SERDES vs. SGMII/XGMII mohou být podporovány jako dva alternativní styly framingu na sdílených dvou párech (čtyřech pinech) čipů MAC a PHY.

No, ani ne, jednak záleží co se serdesem bere, ale PSC/PMA je o něco složitější. Věř mi, dal jsem si s tím už dost práce :-D
Rád věřím, respect :-)
No jasně, čistý payload se nafoukne o nějaké to 4/5 nebo 8/10 nebo 64/66 a tuším se ještě scrambluje nějakým polynomem... ale pořád je to jenom payload se vcelku pevnou obálkou navíc. Leze to už z výstupu PHY čipu na symetrickém páru. Samotný SFP transceiver je už jenom hloupý opakovač - a i pokud třeba není (protože kupodivu bridguje), tak "Ethernet na BASE-X SERDESu" nemá režijní kanál, kterým by se v takovém chytrohloupém SFP transceiveru dalo šťourat ze strany hostitele (PHY/MAC). Ne v těch podrobnostech, které řeší MII/MDIO.

Citace
Serdes sám o sobě koupíš jak IP na dané technologii (nebo jako hard IP v FPGA). Ale okolo potřebuješ spoustu logiky. Na druhé straně je teď dost populární serdes sdílet mezi aplikacemi (USB 3.0, Ethernet, PCIe, SATA)...
Ano - SERDES v obecnějším slova smyslu. Serializer-deserializer. Obsahuje ho každá sběrnice, která bajty nebo slova nepřenáší paralelně (co bit to drát). Říkat tomu posuvný registr nebo UART by bylo jednak staromódní, druhak dnešní SERDES toho umí víc, umí specifická kódování pro různé varianty sběrnic jak jste podrobně zmínil... a ano, dodává se to jako hotové bloky do FPGA, protože kdo by se s tím chtěl kodit od nuly, žejo...
Čímž jsme se poněkud vzdálili od původního tématu (SFP transceiver a PHY čip = ASIC v něm použítý).

7
Sítě / Re:2.5G ETH do 10G optiky
« kdy: 12. 05. 2023, 14:59:12 »
Jaká ale bude podpora u náhodného switche? Kdoví a v tom je právě ten problém.

Já bych tipnul, že to půjde. Pokud SFP modul v SPD EEPROM nabízí SERDES na některé z rychlostí, které switch podporuje. Nejlevnější switche od značek jako je D-Link (a mnohé noname průmyslové) nejsou nijak vybíravé na značku a model transceiveru, a v těch to nejspíš pojede. Stejně jako noname gigové optické SFP transceivery za dvě stovky.

Vemte nejlevnější noname optický gigový transceiver co máte, nebo optický 10gigový, a vražte ho do uvažovaného switche. Chodí?

Marvell 88X3310
-- koukám na něj, ten je vážně hustej.

V dostupném "data briefu" je zmíněno SGMII i SERDES pro užitečná data, a MDIO pro přístup ke konfiguraci = MII registrům. Není tam pinout ani popis registrů, takže těžko říct, jestli to umí I2C nativně. Pokud ne, dá se I2C MSA SPD "EEPROM" + relay MDIO over I2C zařídit externím maličkým MCU. Pokud by nebylo potřeba DDM, tak mohou být MSA data uložená v samostatné klasické sériové I2C NOR flashce (24C02 nebo tak něco).

Zkouším to na linux stroji (redhat 8, kernel 5.14.0). Vypadá to, že exportuje v serdes typ linky, při připojení 100M (využil jsem mikrotik mAP) to vrací SGMII. Při připojení 10G (na druhé straně je nějaká Aruba) to vrací 10GBASE-KR, interface v linuxu zobrazuje správnou rychlost. Jde si s tím také hrát přes ethtool --set-phy-tunable. Očividně linux má podporu.

Co je v tom Linuxu za síťovku? Když jsem se v tom před časem nimral, tak drivery pro Broadcom MAC (tuším tg3) pracovaly s MII PHY pomocí hezky odděleného "phy subsystému" (hrst specifických driverů pro MII PHY čipy), kdežto driver Intel "igb" (MAC) měl pouze interní podporu asi tří starých PHY čipů s MII (převážně starý 10/100/1000 metalický Marvell).

PHY čipy s MII rozhraním jsem viděl Marvell nebo Broadcom, ale asi jsou i další. Bohužel dokumentace PHY čipů na úroveň MII registrů zřejmě často není veřejně dostupná. Narazil jsem třeba na SFP s čipem Broadcom, který v té době Broadcom ani veřejně nezmiňoval.
Což je z hlediska psaní a údržby driverů dost rozdíl proti čipům "MAC+PHY all in one", ke kterým je dokumentace a leze z nich rovnou tupý SERDES nebo 10/100/1000 metalika.

Pozn.: 10GBASE-KR je podle mého prakticky holý SERDES na dvou metalických párech, jinak shodný s 10GBASE optikou.

SERDES je už hotový bitstream užitečných dat, který má svou jmenovitou rychlost. Full duplex, jeden kanál sem, druhý kanál tam. SERDES nese fakt jenom ethernetový payload, nenese žádný inband dorozumívací "režijní kanál" multiplexovaný mezi užitečnými daty. SERDES je už téměř hotová fyzická vrstva - jenom blikat laserem do optického vlákna.

Nějakou režijní inteligenci navíc (=MDIO) má MII a jeho početné potomstvo, což je původně propoj mezi MAC a PHY.

SERDES vs. SGMII/XGMII mohou být podporovány jako dva alternativní styly framingu na sdílených dvou párech (čtyřech pinech) čipů MAC a PHY.

8
Hardware / Re:Jak zmigrovat multi boot systém z HDD na SSD?
« kdy: 12. 05. 2023, 09:30:31 »
USB-C není marnej - jako náhrada čtyřpinového Micro USB. USB-C má v pinoutu 4x GND, 4x +5V, a 12 pinů pro datové signály, tzn. až 6 párů (ačkoli střední 4 piny zřejmě obvykle slouží jedinému half-duplexnímu páru USB 2.0 +/-). Má menší přechodový odpor pro napájení a je snad i mechanicky nepatrně robustnější, než Micro USB, a dá se bez rizika zasunout v obou pozicích (navzájem o 180 stupňů) - by design. A pravda je, že odolný proti vytržení zrovna není.

9
Sítě / Re:2.5G ETH do 10G optiky
« kdy: 11. 05. 2023, 22:03:24 »
Jen pozor, tohle je spf+, to můžeš strčit pouze do spf+ (2.5G, 10G) switche, do spf (1GB) to s velkou pravděpodobností nepůjde, kompatibilita je pouze zpětná a ne dopředná.

Mám zkušenosti, které jsou s tímto v rozporu.

Nejprve vsuvka: v SFP/SFP+ slotu jsou relativně běžné dvě různé normy:

A) SGMII/XGMII = modernější varianty MII, tzn. transceiver/modul obsahuje Eth PHY, počítá se s tím že může podporovat širší spektrum rychlostí a duplexů (nezávisle na rychlosti MII sběrnice v SFP slotu), dá se s transceiverem o tom přes MDIO popovídat. Původní MDIO nejde poslat přímo na pinout SFP šachty => v případě SFP se používá transport MDIO over I2C, který jede na jiné adrese, než MSA SPD EEPROM = SFP modul má oboje. Potíž je, že standardní je pouze základní sada MII konfiguračních registrů v transceiveru, a reálné transceivery používají proprietární rozšíření, pro která musí mít hostitel (switch/počítač) specifický ovladač... proto se transceivery tohoto typu obecně moc neujaly, čest výjimkám. Rozhodně tyto transceivery nejsou zrovna univerzální.
Transceivery typu MII z definice obsahují malý buffer, aby mohly pakety forwardovat (store and forward) mezi rozdílnými rychlostmi na MII a na vnějším Ethernetu.

B) SERDES = synchronní stream, tradičně na rychlosti PHY transceiveru (který je součástí hostitele), SFP modul tradičně umí jedinou pevnou rychlost a jedná se tradičně o hloupý opakovač/konvertor metalika/optika. SERDES SFP se vyskytují s rychlostmi 100M/1G/10G (tradičně umí pouze jednu z nich). SERDES SFP na trhu naprosto převažují.

No a pak jsou všelijaké exotické varianty.

Jsou dual-rate SFP transceivery 100/1000 Mbps SERDES.
Jsou dual-rate SFP+ transceivery 1/10Gbps SERDES.
Jsou switche s dual-rate porty SFP 100/1000 Mbps SERDES.
Jsou switche s dual-rate porty SFP+ 1/10Gbps SERDES.
Stále se jedná o tupé opakovače, jenom umí pracovat synchronně na té nebo tamté rychlosti. SPD EEPROM má pro toto podporu, takže pokud tomu rozumí taky switch, tak si z toho svoje vybere (nabídne jednu nebo druhou rychlost nebo oboje).
Osobně jsem viděl levný SFP+ modul dual-rate 1/10Gb SERDES fungovat v SFP 1Gbps síťovce DeLock s čipem i210. Ono to dává smysl - mechanický rozměr, pinout SFP konektoru a napájecí napětí jsou pokud vím stejné.

Pak jsou zřejmě moduly (jak mě nedávno upozornil zkušenější zákazník), které mají sice v SFP šachtě rozhraní SERDES na konkrétní rychlosti (třeba 1 Gbps), ale dělají store and forward a směrem ven mohou umět jinou rychlost než na vnitřním SERDESu - například pevných 100 Mbps optiku, nebo multirate metaliku. Takové transceivery/moduly lze použít i ve slotu, který neumí nic jiného než SERDES  o pevné rychlosti (která musí souhlasit s podporovanou rychlostí SFP modulu). Rozumí se, že vůči hostiteli takový modul nabízí v SPD EEPROM jenom SERDES na podporovaných rychlostech, a hostitel také tyto rychlosti vidí (podle mého ani nesahá přes i2C na modul, ale vezme údaj ze svého vlastního PHY). Ve skutečnosti do vnějšího Ethernetu se ale modul může linknout úplně jinou rychlostí. Což se z hostitele zřejmě nedá zjistit.

Takže pokud zmíněný modul od Mikrotiku umí metaliku od 10 Mbps do 10 Gbps (bravo!) a vůči hostiteli má dual-rate SERDES (košer oznámený v SPD EEPROM), může klidně fungovat jak v SFP+ slotu s podporou 10 Gbps only, nebo nejspíš i v SFP slotu s podporou 1 Gbps - pokud si hostitel dokáže přebrat údaj z SPD EEPROM o podpoře 1/10Gb SERDES ze strany modulu.

Nevýhodou je právě to, že SFP modul se chová sice jako bridge, ale nemanažovaný = z hostitelského zařízení se nedá dopátrat, jakou rychlostí jede vnější ethernetový port modulu, případně mu nějakou rychlost/duplex konfiguračně vnutit.

10
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 10. 05. 2023, 08:34:51 »
Nevím, co tam dělá tu spotřebu na 5V větvi a jestli to je vlastnost mojí sestavy, této konkrétní desky, výrobce nebo desek od AMD. A vlastně mi to je fuk. Ale myslím, že jsme se shodli, že to není ideální volba pro sestavu, která dokáže žrát 170W.

Vy máte napájecí zdroj s měřením odběru per větev?

+5V žerou točivé disky. Co jsem zatím viděl VRM třeba i pro RAM, jelo to z +12V - ale pravda je, že jsem hodně nahnutý směrem k intelu. Třeba chtěl výrobce Vašeho motherboardu dopřát zdroji rovnoměrné rozložení zátěže mezi větve, tak pověsil víc věcí na +5V...

+5V nebo +3.3V primárně ze stand-by větve žerou některé periferie, které mohou být použity k probuzení počítače. Po naběhnutí hlavní výkonové části zdroje přebere tuto zátěž částečně nebo úplně větev +5V. Viděl jsem třeba síťovky s čipy AMD, které žraly z +5VSB asi 1A per port... byly optické, zákazník toho chtěl v počítači 6 portů, a WoL tuším sice nebylo potřeba, ale nešlo vypnut (nebylo jak). Takže se nejdřív řešil zdroj, který by dal z +5VSB víc než 6A, a skončilo to přelepením stand-by voltage pinů v PCI konektoru...

11
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 07. 05. 2023, 15:28:29 »
Moc by ses divil, jak hrozně dlouho udrží teplotu žulový sklep dobře zaizolovaný proti vlhkosti :-D
Přijde na to, jakou teplotu = kolik oC... ;-)

12
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 05. 05. 2023, 19:17:25 »
Jo a k tomu podvoltování... na moderních Intelech (nevím jak AMD) P-state má dva atributy, jedná se vlastně o vektor [frekvence;napětí]. Obecně nižší P-stavy mají spolu s konkrétní nižší frekvencí taky konkrétní nižší napětí (VID). Ony ty P-stavy (naprogramované z fabriky pro konkrétní model či kus CPU) mají zřejmě rezervu na nějaké ty výrobní tolerance apod. - spíš je mi otázkou, jestli na dnešních procesorech reálně vůbec lze, zaseknout konkrétní napětí, nebo "editovat mapu P-stavů" apod. S každou novou generací si procesory tyhle věci řeší čím dál víc nejradši interně a nenechají si do toho zvenčí zasahovat.

13
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 05. 05. 2023, 18:47:40 »
P.S. Pochopil jsem to hlavně dnes, kdy jsem zkoušel nahodit ovladač amd-pstate. Dostal jsem se do stavu, kdy mi nefungoval ani ovladač acpi-cpufreq a procesor byl natvrdo na frekvenci 3800 MHz, jenže spotřeba na měřáku byla kolem minima (40W) a podobná, jako když byly frekvence jader cca 500 MHz. Tzn. že vyšší nahozené frekvence u CPU ještě neznamenají jeho větší zátěž a spotřebu.

presne:  frekvence (v idle) jako takova nema na spotrebu (temer) zadny vliv,  taktez nema na spotrebu v idle vliv teplotni/proudove
omezeni  (PPT, TDC, EDC) - to se uplatnuje az pri zatezi, co naopak vliv ma je  undervolting  - ten je  aktivni stale

Frekvence nemá zásadní vliv, pokud je procesor schopen po většinu času mikrospánkovat, pokud možno nerušeně = C-states. Čím hlubší stav, tím pro spotřebu o něco lépe. V C-stavech se totiž zastavují hodiny, odpojuje napájení některým blokům (vč. cache) apod. Pokud byste procesoru dovolil jenom C0, měla by být frekvence na spotřebě už dost znát. I pokud ale dovolíte jenom C0, bude idle smyčka resp. HLT mít menší odběr, než když procesor skutečně začne něco počítat = začnete cvičit s ALU / FPU / AVX / cache apod.

14
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 05. 05. 2023, 14:00:19 »
Ano v Proxmoxu je spuštěný turbostat a OPNsense je virtualizovaný FreeBSD. Chápu, že hostitel by měl být nadřazený, ale OPNsense opravdu žere o 10W více, i když přímo v něm ukazuje CPU usage kolem 0%.

To by mě zajímalo, jaká "céčka" ukazuje Turbostat při vypnutém virtuálu OPNsense. Jestli třeba v tom případě nejede někde C6-C7.

Další věc: jakoupak má to BSD periodu scheduleru. Pokud plánovač FreeBSD tiká v taktu 100-250-1000 Hz, zatímco Linux třeba jede tickless, tak mi dává smysl, že se procesor musí mnohem častěji probudit, aby guestův scheduler zjistil, že ani tentokrát nemá nic na práci.

Nebo tam může být nějaká další nuance v "integraci mezi guestem a hostitelem", která tohle chování způsobuje... zkusil jsem zagooglit, ale našel jsem jenom nějaké vágní poznámky v tom smyslu, že ta emulace stojí nějaký procesorový čas. (Někdo říkal "hlavně bacha, ať máte zapnuté VT-x.  :-) A pak nějaké rozsáhlé papery, které mi rychlým prolétnutím nic konkrétního neřekly.

15
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 05. 05. 2023, 11:18:32 »
...jestli správně chápu, turbostat je v linuxu který slouží jako hypervizor (proxmox) a opnsense je FreeBSD ve virtuálu...

V Turbostatu vidím, že CPU tráví drtivou většinu času ve stavu C2. To je zajímavá informace - měl jsem za to, že opnsense by default nechodí do C-stavů hlubších než C1 popř. C1E. Nemám zkušenost v tomhle virtualizovaném klubku, kdo vlastně drží otěže. On si scheduler ve virtuálu může CPU jádru říct, skrz MWAIT při přechodu do "idle" stavu, že chce usnout do C1, ale jednak dnešní CPU mají všeljaké C-state auto-promote / auto-demote fičurky, kromě toho QEMU-KVM se chová tak, že guest nedostane celé CPU jádro exkluzivně pro sebe, ale v rámci hostitele běží na jednotlivých jádrech jako proces v rámci hostitelova scheduleru, takže hostitelův scheduler si teoreticky může říct o hlubší C-state... (pokud hlubší C-stavy nejsou zakázány v konfiguraci CPU jádra = v MSR registrech).

Každopádně C2 by měl žrát míň, než C1E atd. Daní za hlubší mikrospánek je delší probouzení - rozdíly mezi jednotlivými C-stavy jsou klidně o řád! Máte-li možnost, zkuste spekulativně omezit C-stavy na mělčí / hlubší a porovnat spotřebu. Podle mého to bude o pár wattů sem nebo tam.

Stran: [1] 2 3 ... 76