Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: xsouku04 22. 08. 2024, 11:45:29
-
Říkal jsem si, že si zkusím postavit také jeden server s intel procesorem, který má mít v klidu nižší spotřebu než AMD a doufal jsem také v lepší stabilitu.
Pořídil jsem si serverovou desku Supermicro X13SAE-F https://www.supermicro.com/en/products/motherboard/x13sae-f, s ipmi, ECC ale navíc možností použít běžný intel procesor a nikoli předražené a extra žravé a pomalé xeony.
Nakoupil jsem 4 krát KSM48E40BD8KM-32HM - Kingston DDR5 32GB DIMM 4800MHz CL40 ECC DR x8 Hynix M
a procesor 13th Gen Intel(R) Core(TM) i9-13900K
Jako chladič procesoru jsem koupil ARCTIC Freezer 7 X, kompaktní chladič CPU, 4 heatpipe, 92mm fan
s tím, že aby se to uchladilo omezím trošku maximální výkon.
Co mne ale zarazilo je subjektivní pomalost práce v konzoli.
Zkusil jsem tedy testovat výkon jednoho jádra i celkový výkon a je to dost bída.
Maximálně tak 2/3 toho co by mělo být. Nicméně aby se to neuvařilo, musím v biosu vypnout Turbo.
A pak je to cca poloviční výkon toho co by to mělo naměřit. Jde mi především o výkon jednoho jádra, který se subjektivně zdá horší nebo stejný než na mém pracovním notebooku. Jedno pracující jádro by to uvařit nemělo i ani s turbem.
Jak ale omezit výkon tak,a bych mohl nechat turbo a procesor se nepřehříval při větší práci jsem nepřišel.
Zde je můj změřený výkon s vypnutým turbem.
https://www.passmark.com/baselines/V11/display.php?id=507149559932
(co se týče špatného výkonu paměti, předpokládám, že hráči běžně paměť přetaktovávají a kupují ty nejrychlejší, tedy je běžné že serverová s ECC je na tom hůře)
A zde jsou hodnoty, co by to mělo naměřit.
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i9-13900K&id=5022
Spotřeba v klidu je jen nepatrně nižší než u podobně výkonného AMD. Nestojí to za řeč. Při vypnutém turbu a maximální zátěži se maximální spotřeba blíží 80W, což je zjevně podobné jako AMD, až na ten poloviční výkon.
Asi nejlepší by bylo nechat turbo zapnuté v případě, že se používá jen několik vláken, ale omezit celkovou spotřebu procesoru jinak. To se mi nedařilo. I když pokud by to mělo znamenat dvojnásobnou spotřebu tak nevím jestli je to moudré.
Procesor má Performance Cores 8 a další 16 běžných. Vypadá to, že performance cores se o těch běžných liší, jen když je zapnuté turbo. Co je ale navíc problém, že i když celkově stroj nemá žádnou práci, přiděluje práci jednotlivých jádrům náhodně. Tedy Performance Cores nedostávají práci přednostně, což znamená, že se většinou turbo stejně nevyužije a poloviční výkon na jedno jádro to většinou naměří i když je turbo zapnuto. Tedy z toho pramenil ten subjektivní pocit, že je to pomalé např. při instalaci balíčků. Jen pokud přidělím úlohu konkrétnímu performance jádru (např. taskset -c 31 sysbench cpu run) mohu využít výhody performance cores a tedy i turba a naměřím cca 2/3 udávaného výkonu jednoho jádra. Testování jaká je maximální spotřeba a jestli se mi procesor nepřehřeje provádím příkazem ( sysbench cpu run --threads=32).
Dovedete mi někdo poradit čím by to mohlo být ?
-
No jednovláknová úloha by se měla sama přemigrovat na rychlejší jádro. Tak mi to funguje na ARM big-little.
Mezi P a E jádry není jen rozdíl v tom turbo. Ty E jádra jsou i při stejné frekvenci o dost pomalejší než P. Je to jako dříve atom/core.
Turbo bych nechal zapnuté. Jestli je nutné omezovat výkon, tak bych to udělal v PL1, PL2. Když by se to přehřívalo, tak stejně bude CPU samo frekvence snižovat - možná není nutné to omezovat dopředu.
80W je nějak málo, phoronix měřil spotřebu střední 150W a maximální 300W, jestli to teda nebude tím, nebo přehříváním ???
nejsou prostě ty P jádra vypnuté? ani to neodpovídá specifikaci Intelu, ten říká TDP jen procesoru PL1=125W, PL2=253W (turbo)
https://www.phoronix.com/review/intel-core-i9-13900k/20
-
aktuální PL1 a PL2 jde zjistit pomocí
sudo apt install powercap-utils
powercap-info -p intel-rapl
Maximální zatížení CPU bych dělal spíš takto:
sudo apt install stress-ng
stress-ng --cpu 0 --cpu-method fft --timeout 300 --metrics-brief --tz
Toto 5 minut (300 s) pustí na všech procesorech a změří výkon (bogo ops/s (real time)) i teplotu.
Zkusil bych i --cpu 1 na jednom procesoru a koukal htop, jestli to je na P jádře a jakou má to jádro frekvenci. To bogo ops/s děleno frekvence jádra v MHz by mělo na Intelu být kolem 0.5
Pak jde zkusit --cpu 8 (všechny P), --cpu 16 (to nevím, jestli udělá P + hyper-thread P, nebo P+E?), --cpu 24 (P+E bez HT?)
-
Nezmínil jste OS, ve výsledcích benchmarku vidím Debian 12.
Podle mého jste si skoro na všecko odpověděl sám :-)
Koukám že ten procík má "jenom" dva kanály RAM... slušný Xeon má čtyři nebo osm :-)
RAMky jste koupil nominálně 4800Mtps, deska podle datasheetu jede 4400 max...
Může být ještě rozdíl, jestli osadíte jeden nebo dva DIMMy na kanál (pokud deska při dvou DIMMech na kanálu sníží takt) = aby to nakonec nejelo v benchmarku rychleji, když necháte jediný DIMM na kanál. Ale může to jet naopak taky pomaleji, pokud řadič využije prokládání řádkových dekodérů ve více DIMMech na společném kanálu. Ten rozdíl by měl být pár procent.
"Subjektivně pomalý v konzoli"... to je trochu bizardní :-) Mně nezatížený linux na konzoli v shellu reaguje okamžitě na prakticky libovolně starém CPU včetně všelijakých ATOMů a Vortexů. Ještě abych já jakožto trapný wetware byl schopen pozorovat latence obsluhy konzole... Pokud to myslíte tak, že srovnáváte svižnost nějakých výpočetních úloh jak to odsejpá, třeba kompilaci kernelu, ve srovnání "s jiným systémem", tak to už ale nesrovnáváte konzolu, srovnáváte celý systém. Například jste se nepochlubil, co tam máte za diskový subsystém.
Napadá mě, zkusit zakázat hlubší C-stavy. Povolit třeba C1/C1e, ale hlouběji nikoli. Svého času asi 8 generací před Vaším procesorem se to dělo v grubu pomocí zaklínadla intel_idle.max_cstate=1, ale rozhodně nechci tvrdit, že toto funguje i na Vašem CPU :-) Taky bych zmínil, že toto šlo na mnoha motherboardech konfigurovat v BIOS SETUPu, někde okolo vlastností CPU nebo power managementu. Pozor, zvedne Vám to idle spotřebu. Ale mohlo by se to pak víc hejbat.
Znáte utility jako turbostat a cpupower (http://support.fccps.cz/industry/pwr/p-states.htm#lin_tools) ? Pravda je, že na moderních big.LITTLE Intelech jsem je ještě nepoužil, možná bude potřeba hodně čerstvá verze. A nechci tvrdit, že tam najdete nějaké konkrétní moudro, spíš jenom přehled o dostupných frekvencích a C-stavech.
Mimochodem, kde se Vám pohybují teploty CPU? Jak je vidí senzor coretemp.
Taky bych možná zkusmo navrhl, dát na cmdline "mitigations=off". To bejvala potenciálně slušná brzda na procesorech, kterých se to týkalo - ale pokud Váš procesor má tyhle problémy vyřešené v hardwaru, mohl by být výsledek tohoto zaklínadla čistá nula.
Pokud se týče storage, doporučil bych třeba "iostat 2" z balíku sysstat (pro základní náhled, co se tam děje). A mountovat oddíly s opšnou noatime. A pak jsou nějaké laditelné čudlíky pod kapotou, co se týče write-back bufferingu: dirty_ratio, dirty_background_ratio (http://support.fccps.cz/download/adv/frr/hdd/hdd.html#knobs) a tak. Latenci způsobenou pomalým diskem samozřejmě pocítíte hlavně při nějaké reálné zátěži, nikoli v benchmarku soustředěném na CPU.
Pokud se týče latencí různých procesů, zkuste latencytop jestli se dobře pamatuju. (Takových toolů je víc.)
Správně zmiňujete dva druhy CPU jader. Máte-li možnost v BIOSu, schválně zkuste spekulativně zakázat všechna úsporná jádra. Ušetříte trochu topného výkonu, který by Vám pokročilý power management poté měl přenechat pro zbývající "plnotučná" jádra. Taky ušetříte dost drbání na hlavě scheduleru (ano všiml jsem si, umíte přiřadit procesu jádro natvrdo.) A dále, plnotučná jádra by měla umět HT. Zkuste ho schválně taky před benchmarkem zakázat - výsledkem by mohl být lepší výsledek v benchmarku pro single-core zátěž.
Jinak ad pomalost obecně... vrtá mi hlavou, co ještě by na tom třeba BIOS mohl zvorat.
Jak vypadají /proc/interrupts ?
Nedržkuje třeba kernel při startu do dmesg, že musel nějaký IRQ source uškrtit, protože není řádně obsloužen?
Pokud to BIOS umí, tak spekulativně zakázat PCI-e ASPM... opět to trochu zvedne spotřebu, ale mohlo by to nepatrně ulevit od nějakých latencí ze strany periferních zařízení. (Tuším driver síťovek Intel jednu dobu ASPM na síťovkách šmahem vypínal, protože to bylo rozbité.) Z poslední doby si nevybavuju, že by mě zrovna ASPM někde pokousalo. Vlastně to obvykle už nejde ani vypnout.
Jan Fikar zmiňuje PL1/PL2: tyhle power-levely se dají v některých BIOSech konfigurovat. Jde o konfigurovatelné omezení spotřeby. Podle toho pak jede dnešní přechytralý power management procesoru = bude Vám škrtit frekvence. Viz opět turbostat a spol.
Tuším taky vídám v některých BIOSech na moderních CPU možnost, jet CPU power management autonomně v režii HW (CPU), nebo ho přenechat postaru operačnímu systému. Relevantní zkratky jsou snad HWP a RAPL. Pokud necháte powermanagement "postaru operačnímu systému", tak by se měl chytit ovladač intel_pstate (http://support.fccps.cz/industry/pwr/p-states.htm#lin_sysfs), který pak jede podle nastaveného "profilu". Resp. podle aktuální dokumentace se zdá (https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html#operation-modes), intel_pstate umí nechat HWP zapnuté a jenom mu říct žádaný režim (powersave / performance). V tom případě se zřejmě HWP řídí PL nastaveným v BIOSu... ? Nezkoumal jsem to... tyhle věci se v kernelu i v hardwaru v průběhu let postupně mění.
Ještě ohledně těch power-limitů... vídám to omezené v pasivních počítačích (s moderními Intel CPU) s napájením 24V. Když ten limit zvednu, a dám CPU za uši, občas shoří tavná pojistka v přívodu, která s předchozími generacemi téže modelové řady vždycky přežila...
-
Používat i9, a nebo cokoliv co je určeno do desktopu, v serveru je úplný nesmysl.
Buď máš povrchní informace, a nebo jsi podcenil přípravu. V každém případě pro stavbu čehokoliv musíš mít vědomosti, a ty ti tedy chybí.
Jako laik jsi si měl koupit hotový server, a je jedno zda HP, DELL nebo Lenovo.
A když už stavět tak na Xeon.
Když se vyjadřuješ o technických věcech, tak věř že u serveru "na to prdí pes". U serveru jde hlavně o to aby to bylo stabilní a spolehlivé. Všechny technické termíny jsou k smíchu, např. u HP máš PDF s kompatibilními podporovanými komponenty (nebo konfigurátor), který ti řekne přesně co k dané funkcionalitě potřebuješ.
A rychlost je pouze otázkou volných peněz ve šrajtofli.
-
...ještě bych možná dodal: vybavuji si spíše matně z poslední doby jakousi legraci, kdy jsme měli na konkrétním exotickém kusu PC o něco horší tepelnou vazbu CPU na chladič. Intel CPU. A když jsme tomu dali v Linuxu za uši nějakým benchmarkem, tak bylo hezky vidět, jak HWP nebo kýho čerta opatrně ladí frekvenci (P-state) a zespoda jemně líže nastavenou hraniční teplotu. Ne maximum pro PROCHOT, ale nějaký níže nastavený práh, snad svázaný s power limitem. Jemně se přibližuje, aby využil povolenou obálku, ale nepřekročil. Vzhledem k tomu, že se nejednalo o práh pro PROCHOT, tak jsem ho nikdy neviděl throttlovat. Co to bylo za profile a kde se to případně nastavovalo... už nevím.
-
Ja jsem kdysi videl "subjektivne pomalou konzoli" na nejakych Sun strojich kde byl zapnuty mirroring konzole na seriovou linku (ci tak neco, uz je to cca 20 let). Muzete zkusit zkontrolovat nejake jejich ILO nebo IPMI ci jak se tyto technologie jmenuji. Jinak si myslim, ze pomalou konzoli z duvodu ze CPU nejede na 100% vykonu, ale treba jen na 50% nemate sanci poznat.
-
Ja jsem kdysi videl "subjektivne pomalou konzoli" na nejakych Sun strojich kde byl zapnuty mirroring konzole na seriovou linku (ci tak neco, uz je to cca 20 let). Muzete zkusit zkontrolovat nejake jejich ILO nebo IPMI ci jak se tyto technologie jmenuji. Jinak si myslim, ze pomalou konzoli z duvodu ze CPU nejede na 100% vykonu, ale treba jen na 50% nemate sanci poznat.
Na některých dražších boardech (serverových?) lze v BIOSu zapnout sériovou konzoli na COM portu.
A přesně jak říkáte, pomalá je potom i VGA konzola (např. BIOS SETUP), protože čeká až se všechno nasype na ten sériák (naštěstí s vypnutou flow control).
Nicméně odhaduji, že tady tazatel mluví o konzoli linuxového OS, Linux jede přímo na VGA HW, zároveň sériovou konzolu Linuxu nemá v grubu zapnutou a chová se mu to podobně na lokální fyzické konzoli VGA+kb+mouse, jako vzdáleně přes SSH...
Naprosto souhlasím, že mírné vytížení CPU se na konzoli moc nepozná.
Až když jedou všechna jádra CPU po strop (a ta zátěž není nice), nebo je vytížený disk, všimne si humanoid delší odezvy na konzoli.
Některé systémy dělají delší pomlky při loginu - buď jako ochranu proti hádání hesel hrubou silou, nebo tam vážně něco startuje (tahá se z disku konfigurace uživatelské session), nebo si server zjišťuje Váš reverzní DNS záznam apod. Jakmile jste v shellu, tak podle reakce na úder do klávesy Enter byste neměl poznat, jestli jedete na 386 nebo na 20jádrovém Xeonu.
Nevím jestli jsem měl někdy pocit, že mi "shell odřádkuje ještě dřív, než můj prostředník dopadne na Enter". Možná kdysi dávno, když jsem byl zvyklý na Linux na šrotové 486 kde něco běželo, a od ní jsem se otočil na židli k dual-Xeon serveru s čerstvým nezabydleným FreeBSD a HW RAIDem ze dvou Cheetahů :-)
-
Tyhle K procesory nejsis pojedou v nejakem intelem specifikovanem rezimu, takze ten overclock bude aplikovan jenom po dobu par vterin, pak se to vrati poslusne na papirove TDP, coz bude znamenat ten mizernej vykon.
Aby jste z K procesoru vytezili maximum, dejte ho do herni desky, ktera vam dovoli overridnout casove a vykonove limity - jasne, procesor si rychleji ohoblujete, ale jeho vykon bude top. Stejne jako vas ucet za energie :D
Tohle je bohuzel pravda i pro znackove workstationy - mam tam 10900K, ale chova se to zcela obycejne bohuzel.
-
No a nemůže bejt ten CPU jednoduše vadnej, když je raptor-lake nestabilní už od výroby a někteří vývojáři hlásí 100% failture rate?
-
Tyhle K procesory nejsis pojedou v nejakem intelem specifikovanem rezimu...
Jedinej rozdil verze CPU s K a bez je odemceny nasobic. Vychozi chovani = bez manualnich zasahu, je identicky. Tzn kdyz vytocis sbernici muzes nasobicem shodit frekvenci CPU nebo naopak, muzes nasobicem frekvenci CPU zvednout bez zmeny frekvence sbernice.
Davat neco takovyho do serveru je samozrejme totalne uchylny, a je dost pravdepodobny, ze celej problem spociva prave v kombinaci MB vs CPU. Ono se totiz u desktopovych CPU jaksi taky nepredpoklada ECC jakkoli je "supported". Dost pochybuju ze to nekdo nekdy nejak zvlast testoval. Natoz CPU s malejma a velkejma pindikama ... to zarucene nikoho ani nenapadlo ze by do ty desky nekdy nekdo daval.
-
Tyhle K procesory nejsis pojedou v nejakem intelem specifikovanem rezimu...
Jedinej rozdil verze CPU s K a bez je odemceny nasobic.
Vychozi chovani = bez manualnich zasahu, je identicky. Tzn kdyz vytocis sbernici muzes nasobicem shodit frekvenci CPU nebo naopak, muzes nasobicem frekvenci CPU zvednout bez zmeny frekvence sbernice.
Ma to jiny base/boost frekvence a tim ze to jsou vyberove kusy, tak boostuji ochotneji nad ramec klasickych limitu - pokud jim takovy boost deska povoli. Coz ta, ktera dusledne implementuje doporuceni intelu (napr. serverova - kde se hledi na stabilitu) neudela v takove mire, jako nejaka herni. A tam je pak znat ten rozdil ve vykonu.
S "odemcenym" nasobicem se nema cenu hrat poslednich asi 6+ generaci, protoze ty procesory se v ramci boostu dynamicky pretaktovavaji lepe. A od doby co nas opustilo FSB, nic jako frekvence zbernice neni, jsou tam referencni hodiny (100MHz) od cehoz se odviji dynamicke casovani ruznych casti systemu - a jedina externi sbernice je bud DMI do PCH (coz je pouze preznacene PCIe), anebo pametovy rozhrani - rucne nastaveny nasobic do techto nema co kecat.
Odemceny nasobic u moderniho cpu totiz znamena, ze si muzete frekvenci samotneho vypocetniho jadra nastavit rucne - a k nicemu praktickeho to neslouzi, nez aby jste zjistili, jak vyberovy kousek mate, nebo jak kvalitne jste si sestavili chlazeni. Vsichni ostatni preferuji dynamicke rizeni frekvenci.
Davat neco takovyho do serveru je samozrejme totalne uchylny, a je dost pravdepodobny, ze celej problem spociva prave v kombinaci MB vs CPU. Ono se totiz u desktopovych CPU jaksi taky nepredpoklada ECC jakkoli je "supported". Dost pochybuju ze to nekdo nekdy nejak zvlast testoval. Natoz CPU s malejma a velkejma pindikama ... to zarucene nikoho ani nenapadlo ze by do ty desky nekdy nekdo daval.
O intel ECC taky vite prd. Takze vec se ma takto: mate-li spravny cpu (dle generaci nekdy i3, nekdy i9, ale podle ARK to poznate rovnou, pac je tam explicitne zaznam o podpore ECC) + workstation/server chipset (Wxxx,Cxxx), tak vam ECC bude fungovat. Zda to bude nebo nebude zalezi opravdu od generace procesoru, protoze intel meni politiku podle toho jak se zrovna vyspi, ale VZDY jde dohledat konkretni vysledek podpory stylem, ze kdyz nemate tu spravnou komponentu, tak vam ECC nepojede nikdy, ale pokud mate vsechny komponenty ty spravne, tak vam ECC pojede vzdy. Nic mezitim na Intel platforme neexistuje (v takove obdobe jako u AMD, ze vam ecc nepriznaji ale pojede, mate-li stesti na model desky kde to zadratovali - to je fakt peklo).
-
Debian 12.
zkusit zakázat hlubší C-stavy. .....ine "mitigations=off". To bejvala potenciálně slušná brzda na procesorech, kterých se to týkalo - ale pokud Váš procesor má tyhle problémy vyřešené v hardwaru, mohl by být výsledek tohoto zaklínadla čistá nula.
Pokud se týče storage, doporučil bych třeba "iostat 2" z balíku sysstat (pro základní náhled, co se tam děje). A mountovat oddíly s opšnou noatime. A pak jsou nějaké laditelné čudlíky pod kapotou, co se týče write-back bufferingu: dirty_ratio, dirty_background_ratio (http://support.fccps.cz/download/adv/frr/hdd/hdd.html#knobs) a tak. Latenci způsobenou pomalým diskem samozřejmě pocítíte hlavně při nějaké reálné zátěži, nikoli v benchmarku soustředěném na CPU.
Pokud se týče latencí různých procesů, zkuste latencytop jestli se dobře pamatuju. (Takových toolů je víc.)
Skvělé, tohle bych chtěl, umět pod linuxem. Tohle jsem ovládal pod Windows dobře (u 5. generace intel, to co platilo tehdy, už taky dnes je jinak, jsou jiné problémy), ale na linuxu bych na to koukal jak na zelenou louku, nevím kde začít.
-
aktuální PL1 a PL2 jde zjistit pomocí
sudo apt install powercap-utils
powercap-info -p intel-rapl
Maximální zatížení CPU bych dělal spíš takto:
sudo apt install stress-ng
stress-ng --cpu 0 --cpu-method fft --timeout 300 --metrics-brief --tz
Toto 5 minut (300 s) pustí na všech procesorech a změří výkon (bogo ops/s (real time)) i teplotu.
Zkusil bych i --cpu 1 na jednom procesoru a koukal htop, jestli to je na P jádře a jakou má to jádro frekvenci. To bogo ops/s děleno frekvence jádra v MHz by mělo na Intelu být kolem 0.5
Pak jde zkusit --cpu 8 (všechny P), --cpu 16 (to nevím, jestli udělá P + hyper-thread P, nebo P+E?), --cpu 24 (P+E bez HT?)
Díky powercap-info -p intel-rapl vrací:
enabled: 1
Zone 0
name: package-0
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 101341345790
Constraint 0
name: long_term
power_limit_uw: 80000000
time_window_us: 55967744
max_power_uw: 125000000
Constraint 1
name: short_term
power_limit_uw: 253000000
time_window_us: 2440
max_power_uw: 0
Zone 0:0
name: core
enabled: 0
max_energy_range_uj: 262143328850
energy_uj: 137487495199
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 976
Jak to měl nastavit,a by celková spotřeba moc nepřesahovala 80W ale mohl bych mít zapnuté turbo? Jde mi hlavně o stabilitu a nízkou spotřebu. Co se týče výkonu na tom až tolik nezáleží, ale nechci mít výkon zbytečně nízký.
Jinak nyní to vypadá, že když byla práce pro jedno jádro, dostane to P jádro. Jestli je to ale náhoda, nebo prostě lepší jádra dostávají práci přednostně netuším.
lscpu --all --extended
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ
0 0 0 0 0:0:0:0 yes 3000.0000 800.0000 800.0000
1 0 0 0 0:0:0:0 yes 3000.0000 800.0000 800.0000
2 0 0 1 4:4:1:0 yes 3000.0000 800.0000 873.3020
3 0 0 1 4:4:1:0 yes 3000.0000 800.0000 800.0000
4 0 0 2 8:8:2:0 yes 3000.0000 800.0000 3000.0000
5 0 0 2 8:8:2:0 yes 3000.0000 800.0000 800.0000
6 0 0 3 12:12:3:0 yes 3000.0000 800.0000 800.0000
7 0 0 3 12:12:3:0 yes 3000.0000 800.0000 800.0000
8 0 0 4 16:16:4:0 yes 3000.0000 800.0000 800.0000
9 0 0 4 16:16:4:0 yes 3000.0000 800.0000 800.0000
10 0 0 5 20:20:5:0 yes 3000.0000 800.0000 800.0000
11 0 0 5 20:20:5:0 yes 3000.0000 800.0000 800.0000
12 0 0 6 24:24:6:0 yes 3000.0000 800.0000 800.0000
13 0 0 6 24:24:6:0 yes 3000.0000 800.0000 800.0000
14 0 0 7 28:28:7:0 yes 3000.0000 800.0000 800.5930
15 0 0 7 28:28:7:0 yes 3000.0000 800.0000 800.0000
16 0 0 8 32:32:8:0 yes 2200.0000 800.0000 800.0000
17 0 0 9 33:33:8:0 yes 2200.0000 800.0000 800.0000
18 0 0 10 34:34:8:0 yes 2200.0000 800.0000 800.0000
19 0 0 11 35:35:8:0 yes 2200.0000 800.0000 800.0000
20 0 0 12 36:36:9:0 yes 2200.0000 800.0000 800.0000
21 0 0 13 37:37:9:0 yes 2200.0000 800.0000 800.0000
22 0 0 14 38:38:9:0 yes 2200.0000 800.0000 800.0000
23 0 0 15 39:39:9:0 yes 2200.0000 800.0000 800.0000
24 0 0 16 40:40:10:0 yes 2200.0000 800.0000 800.0000
25 0 0 17 41:41:10:0 yes 2200.0000 800.0000 800.0000
26 0 0 18 42:42:10:0 yes 2200.0000 800.0000 800.0000
27 0 0 19 43:43:10:0 yes 2200.0000 800.0000 800.0000
28 0 0 20 44:44:11:0 yes 2200.0000 800.0000 800.0000
29 0 0 21 45:45:11:0 yes 2200.0000 800.0000 800.0000
30 0 0 22 46:46:11:0 yes 2200.0000 800.0000 800.0000
31 0 0 23 47:47:11:0 yes 2200.0000 800.0000 800.0000
příkaz stress-ng --cpu 1 --cpu-method fft --timeout 300 --metrics-brief --tz vrátí:
stress-ng: info: [2698402] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2698402] dispatching hogs: 1 cpu
stress-ng: metrc: [2698402] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2698402] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2698402] cpu 839468 300.00 300.00 0.00 2798.22 2798.27
stress-ng: info: [2698402] cpu:
stress-ng: info: [2698402] acpitz 27.80 C (300.95 K)
stress-ng: info: [2698402] x86_pkg_temp 39.00 C (312.15 K)
stress-ng: info: [2698402] successful run completed in 300.00s (5 mins, 0.00 secs)
Příkaz stress-ng --cpu 0 --cpu-method fft --timeout 300 --metrics-brief --tzvrátí:
stress-ng: info: [2685313] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2685313] dispatching hogs: 32 cpu
stress-ng: metrc: [2685313] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2685313] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2685313] cpu 13700343 300.00 9564.14 0.16 45667.75 1432.45
stress-ng: info: [2685313] cpu:
stress-ng: info: [2685313] acpitz 27.80 C (300.95 K)
stress-ng: info: [2685313] x86_pkg_temp 70.22 C (343.37 K)
stress-ng: info: [2685313] successful run completed in 300.01s (5 mins, 0.01 secs)
Příkaz stress-ng --cpu 8 --cpu-method fft --timeout 300 --metrics-brief --tz vrátí:
stress-ng: info: [2692151] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2692151] dispatching hogs: 8 cpu
stress-ng: metrc: [2692151] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2692151] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2692151] cpu 6692351 300.00 2399.98 0.00 22307.82 2788.51
stress-ng: info: [2692151] cpu:
stress-ng: info: [2692151] acpitz 27.80 C (300.95 K)
stress-ng: info: [2692151] x86_pkg_temp 55.88 C (329.02 K)
stress-ng: info: [2692151] successful run completed in 300.00s (5 mins, 0.00 secs)
Příkaz stress-ng --cpu 16 --cpu-method fft --timeout 300 --metrics-brief --tz vrátí:
stress-ng: info: [2693912] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2693912] dispatching hogs: 16 cpu
stress-ng: metrc: [2693912] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2693912] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2693912] cpu 9652540 300.00 4799.94 0.00 32175.10 2010.97
stress-ng: info: [2693912] cpu:
stress-ng: info: [2693912] acpitz 27.80 C (300.95 K)
stress-ng: info: [2693912] x86_pkg_temp 61.56 C (334.71 K)
stress-ng: info: [2693912] successful run completed in 300.00s (5 mins, 0.00 secs)
Jinak tu pomalost v konzoli jsem nemyslel tím, že bych dlouho čekal na ls nebo dokonce zmáčknutí klávesy, ale např. při instalaci balíků pomocí apt, kde se vlastně testuje výkon jednoho jádra a mám tak srovnání s ostatními servery a třeba svým notebookem.
To že si to nevybírá nejvýkonnější volné jádro se nyní nepotvrdilo, ale možná je to jen náhoda. Nyní jsou výkonnější jádra od 0, ale dříve byly od zadu (tedy 32 a níže).
-
Zaměřil bych se na sledování vytížení cpu (htop s (kernel)threads - shift+k, shift+h) ,nežere něco 99% jako třeba Xorg? (https://forum.root.cz/index.php?topic=29462.0)
A to co byli zmíněno (interrupts) a c -stavy.alee procento času v daném c-stavu myslí že samo o sobě není směrodatný, ale další 2 veličiny: naměřená doba (matice)přechodu mezi stavy a frekvence přechodů
Jo a víte jak je konzole pomalá s systémovym diskem microSD Class 4? Ani nemusí swapovat (ram plná po okraj)
-
Používat i9, a nebo cokoliv co je určeno do desktopu, v serveru je úplný nesmysl.
Všechny technické termíny jsou k smíchu, např. u HP máš PDF s kompatibilními podporovanými komponenty (nebo konfigurátor), který ti řekne přesně co k dané funkcionalitě potřebuješ.
A rychlost je pouze otázkou volných peněz ve šrajtofli.
Kde se takový nový server dá koupit, aby to nemělo nesmyslné parametry jako nesmyslně málo paměti? Nabídka je dost špatná, navíc já nechci RACK, ale běžný case a spotřebu na prázdno ne vyšší než 30W, spotřebu v plném výkonu ne vyšší než 100W, pak není problém to uchladit.
Běžný desktop jsem jako server používal mockrát a ve většině případů jsem nezaznamenal jediný problém nebo pád systému za celou životnost strojů. Tedy mluvit o tom, že se musí připlatit za xeon proto, aby to nepadalo je nesmysl. Xeon je dražší hlavně proto, že zákazníci co kupují servery bývají ochotni platit více.
Pokud je jediný neserverový komponent procesor (to je případ mého stroje: serverový zdroj, serverová deska, fungující ECC paměti, jen běžný procesor), pravděpodobnost problému je ještě nižší, protože závada na procesorech bývala v minulosti velmi vzácná. I když doba se mění a dnes je to i možné.
Hotový server bych si rád koupil, ale jaksi se to běžně neprodává s parametry které bych si představoval. Jediný čeho se nabízí hodně jsou repasované servery, ale tam je špatný poměr výkon/spotřeba. Tedy čtvrtinový výkon ale dvojnásobná spotřeba.
-
aktuální PL1 a PL2 jde zjistit pomocí
sudo apt install powercap-utils
powercap-info -p intel-rapl
Díky powercap-info -p intel-rapl vrací:
enabled: 1
Zone 0
name: package-0
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 101341345790
Constraint 0
name: long_term
power_limit_uw: 80000000
time_window_us: 55967744
max_power_uw: 125000000
Constraint 1
name: short_term
power_limit_uw: 253000000
time_window_us: 2440
max_power_uw: 0
Zone 0:0
name: core
enabled: 0
max_energy_range_uj: 262143328850
energy_uj: 137487495199
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 976
Jak to měl nastavit,a by celková spotřeba moc nepřesahovala 80W ale mohl bych mít zapnuté turbo? Jde mi hlavně o stabilitu a nízkou spotřebu. Co se týče výkonu na tom až tolik nezáleží, ale nechci mít výkon zbytečně nízký.
Tyhle cisla rikaji ze mas 80W dlouhodobe, 125W po dobu 56 sec, a 253W kratkodobe po dobu 2.44ms.
To jsou hodne konzervativni cisla, ale zas je to neco, co diktuje intel. Je to stabilni, ale nevykonny, v porovnani s herni masinou co pusti bez casoveho limitu tech 253W.
-
aktuální PL1 a PL2 jde zjistit pomocí
sudo apt install powercap-utils
powercap-info -p intel-rapl
Díky powercap-info -p intel-rapl vrací:
enabled: 1
Zone 0
name: package-0
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 101341345790
Constraint 0
name: long_term
power_limit_uw: 80000000
time_window_us: 55967744
max_power_uw: 125000000
Constraint 1
name: short_term
power_limit_uw: 253000000
time_window_us: 2440
max_power_uw: 0
Zone 0:0
name: core
enabled: 0
max_energy_range_uj: 262143328850
energy_uj: 137487495199
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 976
Jak to měl nastavit,a by celková spotřeba moc nepřesahovala 80W ale mohl bych mít zapnuté turbo? Jde mi hlavně o stabilitu a nízkou spotřebu. Co se týče výkonu na tom až tolik nezáleží, ale nechci mít výkon zbytečně nízký.
Tyhle cisla rikaji ze mas 80W dlouhodobe, 125W po dobu 56 sec, a 253W kratkodobe po dobu 2.44ms.
To jsou hodne konzervativni cisla, ale zas je to neco, co diktuje intel. Je to stabilni, ale nevykonny, v porovnani s herni masinou co pusti bez casoveho limitu tech 253W.
Díky za vysvětlení. Ještě mám navíc zakázané turbo. A snad proto je celkově tak poloviční výkon než by měl být. Tak snad to bude stabilní. I když zde říkají https://www.youtube.com/watch?v=UmGsyuI1dYw&t=80s , že procesory intel 13900K/14900K mají výrobní chybu a se serverovou deskou deskou co mám já (nebo podobnou od Asusu), kde jsou často i podtaktovány padají tak v 50% případů. Intel je dnes už fakt katastrofa. Pokud chci aby to mělo stejnou spotřebu jako má AMD, tak to má prostě poloviční výkon a i tak to může padat.
-
"Rychlost v konzoli" při instalaci balíčků je víceméně pocitová záležitost, a ovlivňuje jí víc faktorů. Rozhodně se nedá jednoduše říct, že je to pomalým CPU. Když vyloučíme stahování balíčků a možné variace v překladu adres a aktuální přenosové rychlosti sítě, tak se pak v samotné instalaci bude podílet nejspíš primárně rychlost I/O operací na disku, dekomprese na CPU je rychlá, a prakticky jen minimum balíčku pak dělá nějakou další operaci, co by nějak víc vytěžovala CPU. Jsou určitě výjimky, například balíček s jádrem nebo nějakými moduly (drivery), co po instalaci ještě sestavují nové initrd a což typicky na pár desítek vteřin vytíží CPU, protože se výsledná image komprimuje. Sem tam se aktualizuje index pro vyhledávání v manuálových stránkách, ale to je zas hlavně věc I/O.
Takže pokud vám přijde, že je to v porovnání s nějakým jiným PC pomalejší, určitě bych zkontroloval i tyhle ostatní věci mimo CPU. Např. jeden počítač s NVMe SSD, druhý se SATA. Jeden počítač s ext4, druhý třeba s nějakým CoW filesystémem, případně i s více zařízeními (mirroring).
Zkontrolovat, jestli na tom, co se zdá pomalejší neběží na pozadí nějaká I/O aktivita (např. ZFS scrub, resilver. BTRFS scrub, balancing atp.), nebo i něco z userspace, co třeba indexuje soubory atp.
-
A stran toho měřeného výkonu CPU, který je za očekáváním. Mě to přijde, že tomuhle problému moc nepomůžete tuňením v OS, C-Staty atp. To ovlivní primárně spotřebu a teplotu v idle, když systém není vytížený.
Vypnutí turba ta současná CPU samozřejmě strašně poníží, pro snížení spotřeby se opravdu spíš koncentrujte na PL1 a PL2 v BIOSu/EFI, a případně laborovat s podtaktováním a napětími.
Ale ta fundamentální chyba je podle mě už v té úvodní myšlence, že si koupíte "balls to the wall" nejrychlejší Intel z herní mainstream řady, který má turbo boost skoro na 6GHz pro maximální jednovláknový výkon. Ten samozřejmě s továrními hodnotami topí jako prase (125W TDP v "Intel specified" zátěži a ve špičkách 250W) a dáte to dohromady s nějakým laciným základním chladičem, co od pohledu dovede uchladit tak do 100W max.
Kdybych dělal sestavu s nějakým současným Intelem i9, abych ho nebrzdil, přiblížil se těm číslům z veřejných benchmarků a využil jeho potenciál, tak tam nepůjde nic menšího než Noctua s pořádným pasivním blokem a 12/14cm ventilátor(y), nebo alternativy s podobným výkonem od ostatních výrobců. Pokud by to mělo být opravdu tiché, tak bych zvážil AIO vodníka (což je btw. to, co doporučuje Intel).
K tomu samozřejmě i slušný case, kde bude zaručený rozumný průtok vzduchu.
Schválně se mrkněte na recenze těchhle CPU, na popis sestav a jejich chlazení, když to benchmarkují.
-
To jsou konzervativní hodnoty aby to neodcházelo.
https://www.cnews.cz/clanky/vadne-procesory-intel-core-13-a-14-generace-jdou-k-soudu-chysta-se-prvni-hromadna-zaloba/
Procesory byly šity hodně shity jehlou a napájecí rázy je poškozují.
Je možné, že se deska snaží šetřit procesor, aby to běželo stabilně a fakt se to nepoooo.
BTW netuším, proč si někdo do serveru kupuje herní procesor pro děcka, který má vydržet tři roky.
Do serverů se kupují Epyc a Xeony, ne herní procíky.
-
Do serverů se kupují Epyc a Xeony, ne herní procíky.
Obecně, když je to věc za peníze, tak asi jo. Ale asi záleží na využití, měl jsem během let pár pseudo-serverů s desktopovými CPU, i recyklovanými headless sestavami - na vývoj, testování, nějaké zálohy služeb, nenáročné osobní projekty atp. Nemělo to ECC, BMC atp., ale nutně to nebylo moc problematické, běželo to roky.
Ale šlo o starší generace Intel Core. Osobně by se mi do toho spíš teď nechtělo právě kvůli aktuálním modelům desktopových Intel CPU. Které mají problémy, vyšší modely mají brutálně nízkou efektivitu a ten hybrid s P a E-Core. Možná je to teď už lepší i stran sw podpory, ale pamatuji si, že jsem u někoho tak 2 roky zpátky třeba řešil hypervizor a virtuály na Core 12. generace (Alder Lake) a moc pěkně to tedy nechodilo, zvlášť když tam byl ve VM ještě jiný OS než Linux. Byly tam strašné variace ve výkonu, nakonec jsem to musel přes affinity zapinovat jen na P cory.
Takže mě by odrazoval i tenhle aspekt.
-
Jenže staré Intely byly něco jiného než ty dnešní. Proto hodně lidí přechází na Ryzeny a Epyc.
Intel sám teď uz vidí, že marketing na prodej procíků stačí jen když není konkurence. AMD si taky prošlo hnojem a pak mělo tři roky mizerné období. Třeba se Intel malinko odmolochovatí a omladí.
-
Intel prý vydal opravu microkódu, aby mu procesory tolik neodcházely. https://www.anandtech.com/show/21518/intel-publishes-first-microcode-update-for-raptor-lake-stability
Ale zatím jen pro výrobce desky.
Ostatní servery mám na AMD, ale občas problémy se stabilitou, ač vyloženě problém procesoru se nikdy neprokázal. Spadne to tak v průměru ani ne jednou za rok. Dvakrát jsem reklamoval desku.
Tam jsem chtěl zkusit Intel. No je to fakt horší. Poloviční výkon při stejné spotřebě a 50% šance problému s procesorem (https://wccftech.com/unreal-engine-discloses-50-percent-failure-rate-intel-core-i9-14900k-13900k-cpus/). Dle statistik firem co na těch procesorech provozují herní servery. No jestli budu mít smůlu, tak koupím starší generaci Intelu nebo i7. Na čem si troufnout nechat běžet databázi, kde fakt výpadky ani jednou za rok nechci ještě pořád vyřešené nemám. Asi fakt budu muset koupit nějaká server s xeonem. Nebo Epyc?
-
Na čem si troufnout nechat běžet databázi, kde fakt výpadky ani jednou za rok nechci ještě pořád vyřešené nemám. Asi fakt budu muset koupit nějaká server s xeonem. Nebo Epyc?
Pokud je to mission critical, tak si udelejte HA cluster s online replikaci, proste vzor google aka "mnoho levnyho hnoje".
Taky zvazuji zda storage doma nepremigrovat pod nejaky cluster, kde si muzu nody aktualizovat postupne a dalsi dva to udrzi.. protoze jak naroky na provoz rostou, tak to uz neni ze jednou za rok rebootnu fileserver a nabehne ci ne.. ten stav ze ne a pak to resim den, nebo je tam nejaky servis na dva dny kdy se snazim proplachnout case od prachu, prepajet vypalene ledky, atd.. a to ovlivni spoustu ostatnich veci.
Jasne.. cele je to o architekture. Ale clovek tak nejak porad osciluje mezi dedikovanymi nody vs konsolidaci, vse ma sve pro i proti.
-
příkaz stress-ng --cpu 1 --cpu-method fft --timeout 300 --metrics-brief --tz vrátí:
stress-ng: info: [2698402] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2698402] dispatching hogs: 1 cpu
stress-ng: metrc: [2698402] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2698402] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2698402] cpu 839468 300.00 300.00 0.00 2798.22 2798.27
stress-ng: info: [2698402] cpu:
stress-ng: info: [2698402] acpitz 27.80 C (300.95 K)
stress-ng: info: [2698402] x86_pkg_temp 39.00 C (312.15 K)
stress-ng: info: [2698402] successful run completed in 300.00s (5 mins, 0.00 secs)
To vypadá dobře 2798.22/3000 (to je frekvence jednoho jádra na max asi?) = 0.93
Příkaz stress-ng --cpu 0 --cpu-method fft --timeout 300 --metrics-brief --tzvrátí:
stress-ng: info: [2685313] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info: [2685313] dispatching hogs: 32 cpu
stress-ng: metrc: [2685313] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [2685313] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [2685313] cpu 13700343 300.00 9564.14 0.16 45667.75 1432.45
stress-ng: info: [2685313] cpu:
stress-ng: info: [2685313] acpitz 27.80 C (300.95 K)
stress-ng: info: [2685313] x86_pkg_temp 70.22 C (343.37 K)
stress-ng: info: [2685313] successful run completed in 300.01s (5 mins, 0.01 secs)
to vypadá taky dobře, max teplota 70C, výkon jako 16.3x jedno jádro, to by tak mohlo být
bych zapnul turbo a zkusil ten poslední příkaz, pokud se to nebude přehřívat, tak bych to nechal
příkon se stejně omezí na 80W podle toho powercap/rapl
-
Noooó.... Intel má ty procíky slušně zakletý ;D
https://diit.cz/clanek/black-myth-wukong-na-core-1314-pada-navzdory-zaplatam (https://diit.cz/clanek/black-myth-wukong-na-core-1314-pada-navzdory-zaplatam)
Děcka kníkají, že jim hry padají ???
Prostě se to jéb.. :P
A TOMUHLE chceš svěřit důležitou práci?
Jako herní procík na práci fakt není.
Jestli to chceš mít stabilní, šáhni po serveru Dell Poweredge R750/R760 nebo samozřejmě Epyc.
-
Mám doma nonstop běžící "server" sloužící jako NAS, DLNA, web server a hypervisor (1x virtuál).
Je v něm AMD Athlon II X4 605e (koupeno 2009, 45W, průměrné trvalé zatížení cca 30%), 8GB RAM a 20TB disky.
Je naprosto tichý (jen zpomalené 120mm větráky, disky v boxech) a funguje roky bez problémů.
Aktuální uptime má 403 dní.
Takže i laciné desktopy mají své využití jako "servery".
Sice už minimálně 5 let přemýšlím o upgradu, ale dokud běží a stíhá to, co dělá, tak ho nechávám naživu.
-
Na netu se rok+ resi ze 13. a 14. gen. Intelu rezne, pada a ruzne dalsi problemy. Intelu padnou akcie nejniz za 20let. Pripravuje se class action lawsuit na Intel.
A ty si das i9 do serveru? To je gol. Intel bych si nedal nikdy uz ani do herniho PC, natoz serveru.
-
to vypadá taky dobře, max teplota 70C, výkon jako 16.3x jedno jádro, to by tak mohlo být
bych zapnul turbo a zkusil ten poslední příkaz, pokud se to nebude přehřívat, tak bych to nechal
příkon se stejně omezí na 80W podle toho powercap/rapl
Když jsem zapnul turbo (ostatní hodnoty stejné) tak se to přehřívalo i při memtestu a při stress testu spotřeba skočila i na 250w na chvíli než se to přehřálo, což samozřejmě nemá šanci uchladit ten chladič co tam je a tak rozežranej stroj ani nechci. Procesor měl až 100 stupňů a deska pípala. Naměřený výkon jednoho jádra byl cca 3/4 výkonu, který to mělo mít. A když pracovalo jedno jádro, tak se to ještě nepřihřívalo. Tedy je tam něco špatně. Už se mi to nechce moc opakovat, navíc nyní je to v serverovně.
No a jak jsem zjistil, polovina procesorů je vadných časem začnou odcházet. S vypnutým turbem se tomu dost možná vyhnu. Takže to tak nechám. Pokud to nebude padat, pořád jsem na lepším výkonu i ceně než s levnějším xeonem. (kdybych to viděl, tento procesor bych nekoupil, teď mu ale dám šanci)
-
Noooó.... Intel má ty procíky slušně zakletý ;D
https://diit.cz/clanek/black-myth-wukong-na-core-1314-pada-navzdory-zaplatam (https://diit.cz/clanek/black-myth-wukong-na-core-1314-pada-navzdory-zaplatam)
Děcka kníkají, že jim hry padají ???
Prostě se to jéb.. :P
A TOMUHLE chceš svěřit důležitou práci?
Jako herní procík na práci fakt není.
Jestli to chceš mít stabilní, šáhni po serveru Dell Poweredge R750/R760 nebo samozřejmě Epyc.
Kdybych tušil, že Intel nyní prodává procesory, kde je každý druhý vadný, tak bych to samozřejmě nekupoval. Ono je to moc i pro běžné hráče. V minulosti jsem měl ale několik strojů, kde bylo serverové vůbec nic a za celou svoji životnost jako 8 let se ani jednou nekousnuli ani nehavarovali pod slušnou zátěží. Prostě kdyby se neprováděly aktualizace měly by uptime 8 let. Dávat 200 tisíc za rozežraný superstroj se mi opravdu nechce.
-
jak jsem rad, ze kupuju jen amd :-)
-
jak jsem rad, ze kupuju jen amd :-)
Zase si neužiješ prču...
-
Nevim jestli jsem to neprehledl, ale v cem ten Intel o polovinu pomalejsi nez servery s AMD? Uz tady cely den resime, ze to mas pomale a porad nevime co na tom bezi ;-)
-
Passmark má pomalejší, než ostatní s tímhle CPU. Je to asi tím omezením na 80W bez turba. Ale s tím se mu to přehřívá.
-
Lepší koupit hotový server. Třeba něco takového:
https://www.fujitsu.com/global/products/computing/servers/primergy/tower/tx1310m5/#key-features
Dokoupit RAM na 128 GB, a hotovo. RAM nemusí být origo Fujitsu, může se koupit Kingston.
-
...že se musí připlatit za xeon proto, aby to nepadalo je nesmysl. Xeon je dražší hlavně proto, že zákazníci co kupují servery bývají ochotni platit více.
No to teda fakt ne :-)
Xeony mají proti Core vyvedeno víc PCI linek, a GPU část křemíku je nahrazena významně většími L1/L2/L3 cache, a podobně.
Xeony se do serverů a pracovních stanic kupují proto, že vzhledem ke svým vlastnostem jsou pro příslušnou zátěž vhodnější.
U stroje, který vydělává řádově víc peněz za kvartál, než byla jeho pořizovací cena, tě rozdíl v ceně CPU fakt nezajímá. Zajímá tě v první řadě spolehlivost (protože downtime je to nejdražší, co na tom stroji můžeš "provozovat"), a efektivita v požadované zátěži, protože je nesmysl kupovat dva fyzické stroje, když stejnou práci za stejný čas udělá jeden. Nejen kvůli pořizovací ceně, ale taky kvůli ceně prostoru, příkonu, údržby a servisu. Je to o rentabilitě.
-
No to teda fakt ne :-)
Xeony mají proti Core vyvedeno víc PCI linek, a GPU část křemíku je nahrazena významně většími L1/L2/L3 cache, a podobně.
To neni pravda. Existuje spousta Xeonu, ktere jsou identicke kremiky a pouzdra se svymi Core protejsky, a jediny rozdily jsou v povolene ECC a casto zakazane iGPU. Tohle se typicky delo v 2-3-4-5-6-7-8-9-10 generaci. Pak to Intel prestalo bavit, a na 11-12-13 generaci uz tyhle entry level (tj. prevazne desktop socket) Xeony nejsou.
Pokud mluvite o necem, co ma vice PCIe linek, tak to byva typicky serverova platforma na jinem socketu. A i do techto socketu (2011/2066/3647) existovali "herni" / HEDT / workstation procesory, ktere ECC nemeli, meli mene jader, ale vyssi takty a boosty.
oznaceni "Xeon" je nicnerikajici pri vyberu (no dobra, znaci to ze to ma ECC, protoze neznam xeona bez ecc). Ve vsech ostatnich parametrech to je ale uz zavisle na modelu, generaci, socketu.