Opteroni za AM3+ vs FX-43xx poraba...

filip007 je 12. sep 2015 ob 13:12 izjavil:

Kakor sem jaz delal primerjavo je FX-4350 najhitrejši med vsemi FX. Ene igre dajo celo manj FPS na 8 jeder, sploh pa manj jeder manjša poraba. 125W so malenkost hitrejši, pa razlike med 95W in 125W je pri FX-4300 in 4350 samo 7W (Crysis 2 test). Več jederni testi so nepomembni, ker razen video kodiranja sploh nima veze. Sploh pa AMD je dal vsem FX enako L3 8MB in zato je 4 jederni nekje hitrejši.

Ja,samo pri serverju se to obrne na glavo. Pri običnih strojčkih rinejo silicij v čimvišje obrate in poskušajo kar največ prišparat s pametnimi sklopkami in ugašanjem mašine na semaforjih.

Pri FX-4xxx pač na ime mrtvih jeder požreš nekaj leakagea, zato pa živa jedra lahko vrtiš še v malo višje obrate.

Pri strežniku, sploh takem majhnem, single-thread sploh ni tako bistven. Bistveno je, da imaš zadosti računske moči, da pokriješ potrebe povprečeno skozi recimo 10 ms ( kar je v računalnškem času večnost) in to je to.

Tam ti visoki obrati ne pomagajo sploh. Če pa spustiš frekvence na še zadovoljive, pa čutiš vpliv mrtvih jeder, ki žrejo svoj štrom. Če bi bila ta jedra živa, bi lahko zaposlil tudi njih in na ta račun dodatno znižal frekvenco in s tem tudi napajalno napetost vsem skupaj.

Normalno te mašine imajo kot najvišjo prioriteto single-thread performance, kar pomeni čimvišje frekvence ( jedra, L1/L2/L3, ram etc), potem pa v okvirih tega šparajo štrom, izklapljajo neuporabljene enote itd.

Mene pa zanima drugi konec spektra - kako nizko lahko spustiš porabo kot prvo prioriteto in s tem še vedno dosežeš nek minimalno zahtevani performance, v okvirih tega pa recimo po potrebi imaš tudi nek prostor, ko mašina lahko pohodi plin v zahtevanih posebnih okoliščinah, seveda pri večji porabi.

Brane22 je 12. sep 2015 ob 13:49 izjavil:

Mene pa zanima drugi konec spektra - kako nizko lahko spustiš porabo kot prvo prioriteto in s tem še vedno dosežeš nek minimalno zahtevani performance, v okvirih tega pa recimo po potrebi imaš tudi nek prostor, ko mašina lahko pohodi plin v zahtevanih posebnih okoliščinah, seveda pri večji porabi.

tole jz ne bi rekel streznik
ti rabis nek univerzalen racunalnik
da malo kuri(vecino casa), ko pa rabi moc bi pa imel 8 jeder ali pa se vec

Sej maš P1 state iz youtuba.

drgač pa Athlona 5350 ali sempron.

PredatorX je 12. sep 2015 ob 14:11 izjavil:

Sej maš P1 state iz youtuba.

drgač pa Athlona 5350 ali sempron.

Za tadva vem. Ampak ta sta na AM1 platformi, ki je tema druge dileme.

Tle je vprašanje kaj, če AM1 ni zadosti, ker nima zadosti I/O vmesnikov.

Odgovor je torej AM3+. Ima ECC ( vsaj eni modeli uradno, mnogi pa neuradno), ima dosti I/O vrat itd, vprašanej pa je, če se ga da sprqaviti na zadosti majhno porabo.

Jap AM3+ ti nebo lihk preveč power efficient.
i3-T in C222, če hočeš power efficiency in zelo nizko porabo pri low clocking.

gddr85 je 12. sep 2015 ob 16:37 izjavil:

http://forums.extremeoverclocking.com/s...
menda vleče ca 140w v torture skupej s 6950 (idle)

Ne 140W. prideš pod 100W ali celo pod 80W - 100%! Prvo rabiš imeti spodobno plato ter spodoben napajalnik.

Neboš pa prišel pod 50W, ker je nemogoče.

Jap, pri am3+ maš še problem grafike, ker razn če vzameš 760G, rabiš še to.

jebat ga, to je budget server segment. Seveda nebo 50 različnih ponudb.

Čeprav bi se splačalo pogledat, če se da prisilit k delovanju eccja na non server čipsetih. Tam maš pol dost več izbire

če ne rabiš ne vem kak power od gpuja, pač daš notr eno mini z najmanjšo porabo

Pri porabi velja nekako tako, da je 1W 24/7/365 = 1e na leto.

Mi bo kdo razjasnil, kaj je fora imeti ECC, na DC oz. OC procu, ki se ti bo prej "zmotil" v 48ih urah, kot pa navaden ram na rock solid neOC sistemu?

m0LN4r je 12. sep 2015 ob 18:12 izjavil:

Mi bo kdo razjasnil, kaj je fora imeti ECC, na DC oz. OC procu, ki se ti bo prej "zmotil" v 48ih urah, kot pa navaden ram na rock solid neOC sistemu?

Cache je ščiten interno z ECCjem. Spšloh pa DC ni mišljen v smislu tanjšanja varnostnih matgin s siljenjem čipa v delo na istih frekvencah in nižjih napetostih ampak pri nižjih frekvencah kot prej.

m0LN4r je 12. sep 2015 ob 18:17 izjavil:

In? Navaden ram je 99,8989987789999% zanseljiv, z dvignjeno latenco pa še bolj.

99,8989987789999% je _veliko_ premalo, če nimaš možnosti zaznave napak v RAM in hkrati gor moderen FS, ki na to računa.

Kolko % stabilen pa je DC+UV proc? Misliš a boš ga testiral vsaj 24/7, da boš potem 100% ziher, da je 100% stable?

NIti ne rabim 100%. Itak sistme lahko pade iz različnih vzrokov, med drugim motenj po mreži, SW bugov itd. Pomembnejši mi je bit-rot.

Poleg tega je testiranje pri dnu skale bistveno manj kritično kot na vrhu. Pri dnu so tokovi in z njimi povezane motnje veliko manjši. Plata naj bi za šalo nosila tistih 100+W breme, ti pa jo tu laufaš recimo s tretjino tega. To pomeni bistveno manj gretja, motenj, staranja kondijev in špic v napajanju.

Takrat bo glavno vprašanje ali zna silicij delat s to nižjo napetostjo in ne več toliko ali tokovne špice lahko prožijo neke neželjene efekte v čipu.

Tudi brez tega mogoče lahko znižaš frekvenco pod stock toliko, da zaradi tega pade znatno poraba ipd.

m0LN4r je 12. sep 2015 ob 18:35 izjavil:

Torej praviš da je 99.89% premalo, hkrati pa nisi prepričan, če je nižja voltaža na nižji frekvenci > = 99,895 ?

Pravim da je to premalo, če nimaš možnosti detekcije napak, ki potem ostanejo trajno s tabo, ker se pač vpišejo na diske itd.

Interni ECC checki na cacheu. verjetnost napake segmentacije in ostalih napak, ki jih zazna lahko SW, ustrezni razni mehanizmi reporta napak. Nizka verjetnost, da bo napaka procesiranja končala v podatkih na disku.

Velika večina operacij na serverju je priprava DMA kanalov in proženje prenosov. Vse ostalo je režijsko delo.

Če proc izračuna napačno vrednost, je velika verjatnost da bo zaradi tega program krešnil na milion drugih mestih preden pridemo do pisanja na disk. Poleg tega je velika večina vpisov in modifikacij prek DMA kanalov in ne proca. TA samo pripravi registre, DMA pa opravi prenos.

Če proc znori, bo torej narobe izkrmilil hardver, ne bo pa imel prstov v podatkih.

Oziroma vsaj večinoma. Recimo RAID sindrome izračunava proc. Ampak tudi tam imaš komot mehanizme za zaznavo napak in signalizacijo, da se nekaj čudnega dogaja.

Naša stalna poraba, povprečeno skozi mesec/24/7/365), je 1kW.

Največji del tega je računalniški gear.

Zdaj pa zračunaj kilometre in benz.

S tem da imamo battery backup za cel sistem. Poglej recimo, kaj bi to pomenilo, če porabo spravimo na pol ali tretjino pri ceni akumulatorjev. Ali pri možnosti solarnega napajanja itd itd.

Tezko, ce bos res lahko spravil porabo bistveno nizje.
Tudi z res varcnimi procesorji je lahko se vedno visoka.

Moj primer. Asrock q1900m, IBM Serveraid M1015, 1x8GB rama, ena dual gbit intel mrezna, 2x wd 3TB red + 3x seagate 3TB (obicajen desktop 7200rpm), 300W bronze napajalnik. Tole v idle kuri 45-50W, v load pa rahlo manj kot 60w.

S porabo vas zafrkavam. Sam sem se odpovedal stacionarni mašini za mobile mašino. Poraba 65W, ko se polne preko vtičnice. 3-4 ure brez.

Ce ti ustreza, super, men ne, niti nimam za kaj rabit prenosnika.

apu ?

torej vsak mobilni procesor v prodaji ? ;)



^{ne, apu ni samo pogruntavscina amdja}

Sem pravkar probal na prasterem Phenomu 955BE. Porabo se da spustiti _zelo_.

Za winse je bil en res odlicen program za phenome, se je dal res konkretno spustit porabo, pa se provizoris se je dal navijat.

Si vzameš pa potem neki haswell xenon s spodobnim čipstom. Tam je 8x sata praktično standard.

Za vse ostalo pa fault tolerant in falt redunant programiranje in sistemi.

Če se gre to za neke majhne cifre si lahko bp privoščiš sinhronizacijo podatkov na najstarejši način. Zapiše na disk, nato prebere iz njega in pošlje vsebino nazaj, kjer se na mašini ki je prej servirala podatke, vsebina preveri

EVili je 13. sep 2015 ob 18:47 izjavil:

Če se gre to za neke majhne cifre si lahko bp privoščiš sinhronizacijo podatkov na najstarejši način. Zapiše na disk, nato prebere iz njega in pošlje vsebino nazaj, kjer se na mašini ki je prej servirala podatke, vsebina preveri

To je v planu, ampak na drug način. KLient naredi čeksum na svoji strani in ga vpiše na fajl kot atribut. Server ponovi vajo na svoji strani in zapopa svoj atribut. Kdorkoli dostopa fajlu, primerja oba atributa. In občasen, mogoče letni ali kaj podobnega, data scrubbing- preverjanje vseh čeksumov itd.

Da bi to počel stalno med vsakim dostopom, odpade. Zato bi se prilegel ECC- kot neko osnovno zagotovilo, da napake vsaj v RAM cacheu bodo ujete in po možnosti popravljene.