[HookR]

Az elõzõ rész <tartalma>...

[special]

E L S Õ !

[Valdy]

Idézet: special - Dátum: 2007. dec. 5., szerda - 12:23

E L S Õ !

  Mivan, kibújt belõled a gyerek?  :Ð

[Rive]

Idézet: special - Dátum: 2007. dec. 5., szerda - 12:23

E L S Õ !

Ha így folytatod, lesz még MOST is    :Ð

[special]

elmúlt 5 nap relatív változása. tegnap minden papír felfelé indult a fed kommüniké hatására, az amd tovább süllyedt. az látszik, hogy a legtöbb részvényes lapít, viszonylag alacsony a forgalom, nincs pánikszerû értékesítési hullám, ami azért biztató.

intc: intel
ixic: nasdaq kompozit

Csatolt fájl:

•  stockperf.png (0byte)
  Letöltések:: 0

Szerkesztette: special 2007. 12. 06. 09:23 -kor

[SFIJ]

Idézet: special - Dátum: 2007. dec. 6., csütörtök - 9:22

ny a forgalom, nincs pánikszerû értékesítési hullám, ami azért biztató.

intc: intel
ixic: nasdaq kompozit

ja. beszált az ájemdébe szaudi arábia

Szerkesztette: SFIJ 2007. 12. 06. 09:47 -kor

[shabba]

Ami várható volt az bekötvetkezett, 5 milliárd alá esett AMD papírjainak értéke. Pedig alig egy hete még 6.8 milliárd körül jártak, év eleje felé meg 13 milliárd körül jártak még.

[dezz]

A K10 TLB hibájáról szóló cikkben talán nem ártott volna megemlíteni, hogy a Core 2-vel kb. ugyanez esett meg... (link)

[special]

jogos, hogy meg lehetett volna, de valójában nem hiányzik, mert zéró hatása volt végeredményben a piacra és az intelre. legközelebb, igyekszem nem elfelejteni.

[kovacs_istv]

Már a multkor is meg akartam kérdezni, hogyha a softwares vagy mikrokód szintû TLB patch halál a barcelonának, akkor a Phenomot miért engedték ki így? Azt hiszem azt nyilatkozták (vagy special írta?), hogy ott nem futnak kritikus appok. Hát...



Oké, ez szintetikus, meg minden, de akkor is.

szerk: forrás / techreport

Szerkesztette: kovacs_istv 2007. 12. 08. 12:11 -kor

[special]

azért, mert a phenomnak, mint asztali processzor, mondhatni inkább irreleváns a probléma, és patch nélküli teljesítményt kellene nézni. ezért nem állította le az amd annak a szállításait, mert ott teljesen elfogadható az alacsonyabb megbízhatóság. az alacsonyabb megbízhatóságot tessék úgy érteni, hogy még mindig nagyságrenddel magasabb, mint amire hétköznapi környezetben szükség van. ezeket a hibákat a szimuláció és a szilícium validáció éppen azért nem találta meg, mert annyira marginális valószínûségû események, annyira sok tényezõnek kell összejönni hozzá.

Szerkesztette: special 2007. 12. 08. 12:29 -kor

[kovacs_istv]

Ok, ez jogos. Viszont akkor miért létezik patch?

Idézet

AMD has provided a technical description of the problem as part of its documentation for a unsupported patch for the Linux kernel that alleviates the problem with only a minor performance hit.

[special]

Idézet: kovacs_istv - Dátum: 2007. dec. 8., szombat - 13:00

Ok, ez jogos. Viszont akkor miért létezik patch?

ha nem létezne, akkor meg az lenne a baj. lehetõség, tudod: milyen kódot futtatsz, mennyire kritikus az üzem.

[kovacs_istv]

Idézet: special - Dátum: 2007. dec. 8., szombat - 13:33

ha nem létezne, akkor meg az lenne a baj. lehetõség, tudod: milyen kódot futtatsz, mennyire kritikus az üzem.

Akkor összefoglalva:

Kritikus üzem -> Opteron (barcelona) -> 2008/?Q = majd egyszer
Nem kritikus üzem -> kritikus üzemre használod -> lehetõség: patch, jelentõs teljesitménycsökkenés
Nem kritikus üzem -> nem kritikus üzemre használod -> nem raksz fel patchet, OK

Azért különítettem el a középsõt, mert futnak low-budget servereim is, core2 duoval és X2-vel is. Az opteronokkal eddig is bajom volt, úgytûnik ez nem változik.

[special]

Idézet: kovacs_istv - Dátum: 2007. dec. 8., szombat - 15:31

Azért különítettem el a középsõt, mert futnak low-budget servereim is, core2 duoval és X2-vel is. Az opteronokkal eddig is bajom volt, úgytûnik ez nem változik.

pedig low-budget szerverre az opteronok 1xxx és a xeon 3xxx vonalak és hozzájuk tartozó lapok vannak. az ár gyakorlatilag desktop, viszont papíron mindenesetre valamivel nagyobb megbízhatóság, I/O és DIMM-kapacitás jár.

a teljesítménycsökkenés, mint látható, igencsak változó. a jól cache-elhetõ, számításigényes kódoknál szinte semmi, majd minél jobban függ a futásidõ a memóriamûveletek sebességétõl, úgy romlik le a teljesítmény. sajnos üzleti célú szervereknél éppen ez utóbbi jellemzõ, tehát még patchelve is csúnyán nézne ki.

[shabba]

Az Intel 32-szer nagyobb, mint az AMD
http://hirek.prim.hu/cikk/64696/

[d n . r]

Idézet: kovacs_istv - Dátum: 2007. dec. 8., szombat - 16:31

Azért különítettem el a középsõt, mert futnak low-budget servereim is, core2 duoval és X2-vel is. Az opteronokkal eddig is bajom volt, úgytûnik ez nem változik.

Nos, hogy valami komolyságot is próbáljunk már ennek kölcsönözni, kifejtenéd kissé bõvebben, milyen bajaid voltak az X2 / Opetronokkal, és pontosan milyen következtetéseket kivántál levonni a konkrét bajaidból?

[kovacs_istv]

Idézet: d n . r - Dátum: 2007. dec. 9., vasárnap - 12:09

Nos, hogy valami komolyságot is próbáljunk már ennek kölcsönözni, kifejtenéd kissé bõvebben, milyen bajaid voltak az X2 / Opetronokkal, és pontosan milyen következtetéseket kivántál levonni a konkrét bajaidból?

Aha

Az egyik projectnél a gépeket szerzõdéses alvállalkozó szolgáltatta, a feladatot mi adtuk ki. Mielõtt kiírtuk a tendert modelleztük a feladatot különbözõ workstatiönökön (te jó ég, de hülye szó) és arra jutottunk, hogy egy unitos, inteles 1way gépekre van szükség 4G rammal, külön SAS storage boxxal. Még a dual-core procikkal se skálázódott semmit az applikáció, teljesen feleslegesnek tartottuk az SMP-t.

Szerzõdtünk, átadtunk-átvettünk, majd kiderült, hogy a partnerünk átvágott minket és 2way opteron boxokat lízingelt az ISP-tõl, mi flopsra fizettünk, emiatt kevesebb gép futott kevesebb rammal, ráadásul egy évig nem tudtunk elállni a szerzõdéstõl, mivel csak a flops értéket jeleztük elvárásként, a hardware típusában csak szóbeli megállapodás történt. Ettõl persze még nincs baj az opteronnal, node..

A kevesebb RAM miatt el kellett kezdeni optimalizálni az adatbázist és pikkpakk kiderült, hogy ár/értékben nagyon keményen át lettünk húzva a palánkon. Tudnillik a modellezéshez a project elején E6600-as c2d-t, 2x5160 xeont és egy 6000+ X2-t használtunk. A serverekben 2db 2222-es opteron van. Szinte hihetetlen, de adott aplikáció alatt (MySQL alapú egyedi adatbázisserver + PHP+PEAR+ZEND kombó, L7 softwares load balancing) a huszonöt százalékos raw tranzakciókezelési hátrányt, amit a 6000+ produkált a tesztek alatt egy-az-egyben sikerült reprodukálnia. Így teljesen más lett a leányzó fekvése és újra kellett gondolnunk a projectet. Késõbb (a szóbeli megállapodás miatt) jogi útra lett terelve a dolog és a gazdasági kollégák kiszámolták, hogy ha csak egy single xeont vesznek minden opteronos gép helyett, nettóban (tehát a minket ért bevételkiesés nélkül, csak a hardwares beszerzésen) alsóhangos hét számjegyet spóroltunk volna. Cserébe ráfizettünk és a teljesítmény is a béka segge alatt van. Különítsd el a cég baromságát a nevetséges ár/teljesítmény aránytól pls.

----------------------------

Vettem két gépet egy webes project kiszolgálásához, az elsõt teljesen statikus frontendnek szántam, abszolúte desktop C2D E6600, 4g ram, 2x320RE winyó. A másodikat adatbázis és applikáció servernek akartam használni, ez egy dual opteron lett szintén 4g rammal, raid5 scsi winyókkal. Az utóbbi gép rendes server, redundáns táppal, hotswap winyókkal, stb.

Mindkét gépen ugyanaz az OS van (a c2dn is AMD64-es freebsd, ezt szereti), ehhez képest megmagyarázhatatlan okokból a backend 8 hónap alatt négyszer rebootolt, a frontend pedig 300 napos uptimeal bír. RAS? 

----------------------------

Volt cégemnél rengeteg FuSi serverrel dolgoztunk. Az Intelesekkel többnyire nem volt komolyabb probléma, egy-egy hibás csík ramot leszámítva, viszont az opteronos RX220as primergyk nagyobbik részén alapból rossz volt a SATA backplane, 1x512 ram amivel érkezett szintén és javítás után is random fagyásokat produkált, ráadásul mindezt primitív static webes kiszolgálásnál. Fél év, 10 csík recc kingston és 3x2x320G RE caviar után nem tudtam mást tenni, az AMD-t szidtam.

---------------------------

desktopra nem veszek AMD-t, mert az utóbbi egy évben semmilyen szinten nem rúghat labdába ár/érték szempontjából

---------------------------

AMD procis notebookot nem veszek, mert mind teljesítményben, mind energiatakarékosságban fényévekre van az Inteltõl

---------------------------

Szóval ezek lennének a konkrét bajaim. Gondolom el fogod mondani, hogy,
1.) rossz aplikációt használok és demagóg módon ez alapján általánosítok. Lehet, viszont nekem ez a munkám, ezzel dolgozok és ebben úgytûnik nem rúghat labdába az AMD.
2.) bármi miatt fagyhat az a gép. Igen, de a másik nem fagy bármi miatt és ez _nekem_ speciel elég volt ahhoz, hogy többet ne vegyek A64 alapú gépet backendnek.
3.) a FuSi tehet róla. Tutifix. Ugyanakkor az Inteles gépek tûrhetõek voltak, nekem pedig egy életre elment a kedvem a hajnali-kettõkor-fsckzok-a-serverteremben-mínusz-2-fokban típusú szombat estéktõl

[Asker]

elhisszük, de olyan xar nem lehet,  ha a világ egyetlen szuperhatalmának energiaugyeit rábizzák erre az architekturára... ami egy kicsit nagyobb felelõsséggel jár mint az ilyen olyan projecteid már bocs...  azonkívül mért vették az emberek mint a cukrot ABBAN az idõben?

[SFIJ]

Idézet: kovacs_istv - Dátum: 2007. dec. 9., vasárnap - 23:09

Volt cégemnél rengeteg FuSi serverrel dolgoztunk. Az Intelesekkel többnyire nem volt komolyabb probléma, egy-egy hibás csík ramot leszámítva, viszont az opteronos RX220as primergyk nagyobbik részén alapból rossz volt a SATA backplane, 1x512 ram amivel érkezett szintén és javítás után is random fagyásokat produkált, ráadásul mindezt primitív static webes kiszolgálásnál. Fél év, 10 csík recc kingston és 3x2x320G RE caviar után nem tudtam mást tenni, az AMD-t szidtam.

Es ez meg veletlenul sem a fusi sara volt, hanem az AMD-e, ugye? mertnem hasznaltal SUN blade-eket? Ja, hogy annak ara is van, mert rendesen van megtervezve?

Idézet: kovacs_istv - Dátum: 2007. dec. 9., vasárnap - 23:09

1.) rossz aplikációt használok és demagóg módon ez alapján általánosítok. Lehet, viszont nekem ez a munkám, ezzel dolgozok és ebben úgytûnik nem rúghat labdába az AMD.

eleve intelre fejlesztettel, vagy mi a szosz. tudok neked ugy A64-re optimalni, hogy intelen sirogorcsot kapsz, olyan lassu lesz.

Idézet: kovacs_istv - Dátum: 2007. dec. 9., vasárnap - 23:09

2.) bármi miatt fagyhat az a gép. Igen, de a másik nem fagy bármi miatt és ez _nekem_ speciel elég volt ahhoz, hogy többet ne vegyek A64 alapú gépet backendnek.

nalunk meg a HP xeon szerverek hullanak mint a legyek. akkor most fuj, fuj, intel? - oreg ez dedo, mar megbocsass.

Idézet: kovacs_istv - Dátum: 2007. dec. 9., vasárnap - 23:09

3.) a FuSi tehet róla. Tutifix. Ugyanakkor az Inteles gépek tûrhetõek voltak, nekem pedig egy életre elment a kedvem a hajnali-kettõkor-fsckzok-a-serverteremben-mínusz-2-fokban típusú szombat estéktõl

hat nemis a sarki latvanypekseg, az egyszer szent

Szerkesztette: SFIJ 2007. 12. 10. 08:12 -kor