[shabba]

The Best Server CPUs part 2: the Intel "Nehalem" Xeon X5570
http://it.anandtech....doc.aspx?i=3536

Brutális teljesítményû az Intel új szerverchipje
https://www.hwsw.hu/hirek/38460/intel_xeon_...processzor.html

[bogdan]

Brutális teljesítményû az Intel új szerverchipje:
"A megnövekedett sávszélesség tette lehetõvé, hogy a négy processzormagba újra visszakerülhessen a Hyper-threading technológia"

ezt azert nem artana kijavitani, mert butasag.

[Ytse]

Idézet: bogdan - Dátum: 2009. márc. 31., kedd - 17:59

Brutális teljesítményû az Intel új szerverchipje:
"A megnövekedett sávszélesség tette lehetõvé, hogy a négy processzormagba újra visszakerülhessen a Hyper-threading technológia"

ezt azert nem artana kijavitani, mert butasag.

Jogos, igazából azt akartam írni, hogy kis memsávszélesség esetén a hyper-threading inkább árt mint használ... Javítom.

[bogdan]

???
pont foditva!!!
kis memoriasavszelesseg eseten van igazan ertelme, mert elfedi a memoria tavolsagat.

[special]

Idézet: bogdan - Dátum: 2009. ápr. 1., szerda - 22:38

???
pont foditva!!!
kis memoriasavszelesseg eseten van igazan ertelme, mert elfedi a memoria tavolsagat.

nem, a késleltetést fedi. a sávszélességigény nõ. telítõdött rendszerbuszon az újabb szálak szoros versenykondíciót hoznak létre, aminek lekezelése egyrészt teljesítményveszteség, miközben addicionális teljesítmény nem várható, mivel a sávszélesség a szûk keresztmetszet, amin az SMT nem segít. az SMT-vel megnövekedett memóriapárhuzamosságot egyébként szerintem már a memóriavezérlõk sem tudták volna lekezelni, így is szenvedtek azzal, hogy kiszolgálják a 8-16-24 szálat.

[bogdan]

igen, valoban, ha minden szal memoriaigenyes, akkor nagyobb savszelessegre van szukseg. de ez peldaul egyaltalan nem szuksegszeru! ha vegyes tulajdonsaguak a szalak, akkor nem telitodik a savszelesseg. raadasul az sem trivialis, hogy melyik savszelessegrol beszelunk (memoria, L3, vagy L2 cache..? lasd Elric megjegyzeset anno a Niagararol!)

mindenesetre a jelenlegi megfogalmazas biztos, hogy nem stimmel, mert nem a savszelesseg novekedese teszi lehetove a tobbszalusagot.

tovabba ez az egesz azt sugallja, mintha most lenne ra szukseg (azaz nott a kesleltetes), pedig ez pont forditva tortent! szoval a valodi magyarazat meg nem kerult a napvilagra.. konnyen lehet, hogy az L3 cache miatt van am!

[shabba]

Cisco discloses server ASICs
Chips expand Nehalem memory to 384 Gbytes
http://www.eetimes.com/news/semi/showArtic...cleID=217600100

[shabba]

Intel Previews Intel Xeon 'Nehalem-EX' Processor
http://www.intel.com/pressroom/archive/rel...sepri_20090526m

Szerkesztette: shabba 2009. 05. 27. 00:25 -kor

[d n . r]

Intel talking about the 16-thread RISC killer

[shabba]

Intel details Becton, 8 cores and all
Rings, slices and controllers, oh my!
http://www.semiaccurate.com/2009/08/25/int...-cores-and-all/

[d n . r]

Idézet: shabba - Dátum: 2009. aug. 26., szerda - 14:51

http://www.semiaccurate.com/2009/08/25/int...-cores-and-all/

by Charlie Demerjian
Átigazolt az Inquiertõl? Amúgy jó a honlap neve is: _semi_accurate (bár lehet, hogy nem önirónia, hanem kizárólag a semicon-ra utal)

[shabba]

Xeon L3426 45W TDP
http://www.pcinpact.com/actu/news/53095-xe...tension-p55.htm

Kár hogy a teszt környezet nem igazán szerverhez való.

[shabba]

Intel Readies 13 Westmere-based 32 nm Xeon Processors
http://techpowerup.com/110567/Intel_Readie...Processors.html

[Michell]

Üdv!

Nos nekem most van szerencsém az elsõ (Ibm) Xeon 55xx alapú szerverhez (1x 5530 - HT).

Mindenesetre az általam használt adatbázis/Erp eredményektõl egyáltalán nem vagyok elájulva, sõt:
a mért eredményeim - fõleg a közepes felhasználószámot szimulálók - nem vagy alig jobbak mint egy Xeon 5335 (NEC) rendszer teljesítménye.

(Ami lényeges eltérés a két rendszer közt, hogy a régebbi az Win 2003, míg az újabb az Win 2008 szerveren fut és az adatbázisverzió is frissebb - Oracle 11g - a Xeon 5530 szerveren).

Azért én némileg szignifikánsabb teljesítménynövekedést reméltem elõzetesen.

[special]

Idézet: Michell - Dátum: 2010. jan. 4., hétfõ - 10:26

Üdv!

Nos nekem most van szerencsém az elsõ (Ibm) Xeon 55xx alapú szerverhez (1x 5530 - HT).

Mindenesetre az általam használt adatbázis/Erp eredményektõl egyáltalán nem vagyok elájulva, sõt:
a mért eredményeim - fõleg a közepes felhasználószámot szimulálók - nem vagy alig jobbak mint egy Xeon 5335 (NEC) rendszer teljesítménye.

(Ami lényeges eltérés a két rendszer közt, hogy a régebbi az Win 2003, míg az újabb az Win 2008 szerveren fut és az adatbázisverzió is frissebb - Oracle 11g - a Xeon 5530 szerveren).

Azért én némileg szignifikánsabb teljesítménynövekedést reméltem elõzetesen.

mennyi az a nem túl szignifikáns?

nyilvánvaló, hogy a nehalem elõnye egyutas rendszerben a legkisebb, mivel ott még nem igazán limitáló tényezõ az FSB. a hyper-threadingnek és a primitíveknek viszont azért ki kellene ütköznie, meg a néhány többi csiszolás együttes hatásának (fejlettebb elágazásbecslés, nagyobb ooo window, kétszintû tlb). én olyan 20-30 százalékot várnék legalább. nem lehet, hogy szoftveresen van gond? vagy méginkább, nem lehet, hogy nem a processzor a szûk keresztmetszet? (hanem mondjuk memória, diszk i/o)

Szerkesztette: special 2010. 01. 06. 10:06 -kor

[Michell]

Idézet: special - Dátum: 2010. jan. 6., szerda - 9:02

mennyi az a nem túl szignifikáns?

nyilvánvaló, hogy a nehalem elõnye egyutas rendszerben a legkisebb, mivel ott még nem igazán limitáló tényezõ az FSB. a hyper-threadingnek és a primitíveknek viszont azért ki kellene ütköznie, meg a néhány többi csiszolás együttes hatásának (fejlettebb elágazásbecslés, nagyobb ooo window, kétszintû tlb). én olyan 20-30 százalékot várnék legalább. nem lehet, hogy szoftveresen van gond? vagy méginkább, nem lehet, hogy nem a processzor a szûk keresztmetszet? (hanem mondjuk memória, diszk i/o)

-mennyi az a nem túl szignifikáns?

Plusz minusz 10%.

A tesztek amiket futtatok valamennyire szeparálhatóak, hogy melyikben a proc+memória a meghatározó, melyikben a diszk I/O.

Az a gondom, hogy a leginkább proc+mem függõ résznél:
1 aktív session + 0.1%; 4 aktív session +10%; 25 aktív session -10% az "elõny".
(Gyakorlati tapasztalatom szerint az általam vizsgált rendszernél 100 bejelentkezett felhasználó az kb 5-6 aktív sessiont jelent.)

Ez nem szép tendencia.
Én is minimum 30% javulást vártam.
(És mértem már +20-40%-kal jobbat mind Xeon 5345, mind Xeon 5160 !! rendszerben, de azok kétutasak voltak.)


Viszont régebben méregettem a ki és bekapcsolt HT hatását - Xeon 54xx rendszerben, ez felemás eredményeket adott. Ott pont a közepes 4-8 aktív session teljesítmény romlott, kb 5%-ot.
(Móricka magyarázat szerint azért, mert a session-ok idõszakosan másik "processzorra" kerültek át futás közben.)

Tehát a HT az egy külön kérdés, de a mostani rendszernél ezt nem tudtam kimérni.

[Michell]

Üdv Mindenkinek!

Nos részben megvan a magyarázat az általam mért nem túl fényes eredményekre.

Az alapja az amit special is írt, az a tesztrész amit használok és leginkább I/O független (végülis adatbázis
teszteket csinálok), az nagyon érzékeny a memóriaátvitelre.

És az eddigi összes szerverkonfigurációval volt pár apró "baj" ebből a szempontból:

A Xeon 55xx -ek három csatornás memóriavezérlőt tartalmaznak, de a disztributorok megszokásból memóriapárokkal
állítják össze az ajánlatokat.

Több szerver - 3 memóriacsatorna ide meg oda - 8 vagy 16 memóriaslotot tartalmaz (ha mindet kitöltöd akkor
eleve nem az igazi)

És végül, ezek a Xeonok - ugyanúgy mint az Athlon 64 régebben - ha egy csatornán egynél több memóriamodult
találnak visszaveszik a sebességet !
DDR3 1333-ról 1066-ra. És hát a 2 GB-os modulok csak olcsóbbak mintha 4 GB-osokból építkeznének.

Úgy látszik a fenti pár apróság pedig már elég, hogy a "Nehalem" alapú szerverek most némely esetben csak a
Xeon 54xx-es szerverek szintjén teljesítsenek.

Talán majd a következő generáció.

Esetleg a fentiekre másnak is érdemes majd figyelni, a Xeon 55xx processzoros szerverek beszerzésénél - már ha van rá módja.