[special]

Idézet: hvuk - Dátum: 2005. ápr. 23., szombat - 14:18

Ezzel tudod mi a gond? Az, hogy az Intel kötve hiszem, hogy a Fujitsu miatt lemondana az itanium széles elterjedtségérõl. Mert az Intel érdeke azt diktálná, hogy legyen hozzá egy bárki által megvehetõ chipset, amivel jól skálázódik a rendszer. Ha ez nincs, akkor inkább Opteronos rendszereket fognak venni (alsó és közepes szervereknél), hiszen már 4 processzornál is nagyobb teljesítményt nyújt, mint az Itanium2. És itt single-core-ról beszélek, dual-core-nál még durvább a helyzet. Fent pedig a Power5 szorongatja keményen. Az Intel szerintem erõforráshiány miatt állt le vele. Az Intelnek ugyanis minden más piac fontosabb az Itaniumnál, ott pedig nagy gondok vannak (kivéve a mobil piacot). Oda kell átcsoportosítani minden embert, ezért az Itaniumot meg hanyagolják. Majd megkapja a Xeonnal közös buszrendszert, mert arra a Xeonnak is szüksége van, aztán örüljön.

Nyilván, hogy az Intel szeretné, hogy az IPF-bõl is volume termék legyen. Csakhogy amíg ez nem realitás, addig mások a játékszabályok. A high-end pozícionálás koncentrált OEM-bázist jelent az eladásokból, tehát figyelembe kell vennie a nagy OEM-ek érdekeit, mert végeredményben az a saját érdeke is hosszabb távon. Arcoskodhatna, hogy mimárpedig csinálunk faszájos chipsetet, ezzel viszont a HP/Fuji/SGI branccsal szépen összeveszne (gyengébb kollaboráció), a másik oldalról viszont nem sokat hozna, hiszen a volumen vendoroknak nem sok szart érne úgy sem egy high-end proci, amely komplett megoldást igényel, szoftverbázissal stb.  Szóval ha már erõteljes lesz a jelenléte, aminek a következõ 2-3 évben realizáódnia _kell_, akkor CSI alapokon kúszhat le a volumen szegmensbe, _ha teljesíti az ígért költségparitás- és teljesítméybeli fölényt_.

[hvuk]

Idézet: special - Dátum: 2005. ápr. 24., vasárnap - 21:38

Nyilván, hogy az Intel szeretné, hogy az IPF-bõl is volume termék legyen. Csakhogy amíg ez nem realitás, addig mások a játékszabályok. A high-end pozícionálás koncentrált OEM-bázist jelent az eladásokból, tehát figyelembe kell vennie a nagy OEM-ek érdekeit, mert végeredményben az a saját érdeke is hosszabb távon. Arcoskodhatna, hogy mimárpedig csinálunk faszájos chipsetet, ezzel viszont a HP/Fuji/SGI branccsal szépen összeveszne (gyengébb kollaboráció), a másik oldalról viszont nem sokat hozna, hiszen a volumen vendoroknak nem sok szart érne úgy sem egy high-end proci, amely komplett megoldást igényel, szoftverbázissal stb.  Szóval ha már erõteljes lesz a jelenléte, aminek a következõ 2-3 évben realizáódnia _kell_, akkor CSI alapokon kúszhat le a volumen szegmensbe, _ha teljesíti az ígért költségparitás- és teljesítméybeli fölényt_.

Én az IPF széles körû elterjedése alatt nem azt értettem, hogy menjen le a low-end szegmensekbe, meg a WS-ekbe, hanem azt, hogy a 8+ processzoros szerverekben elterjedjen. Azaz a high-end piacon. Mert jelenleg ott is csak vegetál, legalábbis a többi szereplõhöz képest. A Fuji/SGI-vel nyugodtan összeveszhet, számára a HP a fontos partner az Itanium szempontjából. A többi csak a hab a tortán.

Mellesleg szerintem egy ok miatt dobták: jön a Xeonnal közös chipkészlet. Addig meg felesleges erõforrást ölni egy másikba, különösen akkor, amikor a szakemberekre nagy szükség van a desktop vonalon is.

[special]

Ez itt a hammeres topik, szal legyen ez az utolsó IPF-riposzt tõlem: ez a vegetálás nem jó jelzõ ez olyan termékre, amelynek a piaca (IPF-servers) háromszorosára bõvült egy év alatt, és ahova összességében milliárdokat fektetnek be a nagyobb partnerek. A high-endben való elterjedéshez pedig a mostani modell a megfelelõ. Itt proprietary megoldások játszanak.

Szerkesztette: special 2005. 04. 25. 12:46 -kor

[h1ghland3r]

Idézet: hvuk - Dátum: 2005. ápr. 24., vasárnap - 20:17

Én az IPF széles körû elterjedése alatt nem azt értettem, hogy menjen le a low-end szegmensekbe, meg a WS-ekbe, hanem azt, hogy a 8+ processzoros szerverekben elterjedjen. Azaz a high-end piacon. Mert jelenleg ott is csak vegetál, legalábbis a többi szereplõhöz képest. A Fuji/SGI-vel nyugodtan összeveszhet, számára a HP a fontos partner az Itanium szempontjából. A többi csak a hab a tortán.

Mellesleg szerintem egy ok miatt dobták: jön a Xeonnal közös chipkészlet. Addig meg felesleges erõforrást ölni egy másikba, különösen akkor, amikor a szakemberekre nagy szükség van a desktop vonalon is.

Azert ne vesszen mar ossze az SGI-vel ... Az Origin, meg az Altix talan a legeletkepesebb Itaniumra epulo termekek. Legalabbis valszeg tobb jovojuk van, mint az Integritynek.

[hvuk]

Idézet: special - Dátum: 2005. ápr. 25., hétfõ - 13:46

Ez itt a hammeres topik, szal legyen ez az utolsó IPF-riposzt tõlem: ez a vegetálás nem jó jelzõ ez olyan termékre, amelynek a piaca (IPF-servers) háromszorosára bõvült egy év alatt, és ahova összességében milliárdokat fektetnek be a nagyobb partnerek. A high-endben való elterjedéshez pedig a mostani modell a megfelelõ. Itt proprietary megoldások játszanak.

Válaszoltam az Itanium topicban.

[Bujdy]

halálra lett ítélve a 754 hír...

De a mobil procik továbbra is S939-esek lesznek, nem?

[Pitbull]

Idézet: Bujdy - Dátum: 2005. máj. 2., hétfõ - 10:19

halálra lett ítélve a 754 hír...

De a mobil procik továbbra is S939-esek lesznek, nem?

mobil procik S754-sek.

[Bujdy]

Idézet: Pitbull - Dátum: 2005. máj. 2., hétfõ - 17:59

mobil procik S754-sek.

Mekkora lúzer vagyok!

Én is S754-et akartam írni, így értelme sem volt a postnak...

[special]

Idézet: Bujdy - Dátum: 2005. máj. 2., hétfõ - 21:32

Mekkora lúzer vagyok!

Én is S754-et akartam írni, így értelme sem volt a postnak...

nem kell a dráma

[AzErdos[TM]]

Venice power consumption
Tulajdonkeppen mar a kutya is ezt ugatja, minden komolyabb lapon lattam mar a linket (melyeket latogatok).
Meg az is lehet, hogy Off-Topic es a TDP-s thread-be kellett volna irnom, de elegge dobbenetes amit az AMD muvelt... yumm!

Csak izelitoul:

[Asker]

Nesze neked Dothan & tsai.

[AzErdos[TM]]

Forras
_a lenyeg_

Idézet

Nor has AMD completed benchmarks that pit its desktop line against Intel’s 840 Extreme Edition. That’s because AMD has been unsuccessful in its attempts to purchase a PC equipped with the Intel processor, so it can’t run comparison tests, De Onis says. “We can’t get a processor online, anywhere,” she says. I have a message in to Intel requesting an update on availability of systems equipped with its 840 EE chips.

ha ez igaz akkor              

[SFIJ]

The Dual-Core War: Is Intel in Trouble? 

[Asker]

AMD is thinking @ DDR500

Szerkesztette: Asker 2005. 05. 05. 16:03 -kor

[SFIJ]

Idézet: Asker - Dátum: 2005. máj. 5., csütörtök - 16:03

AMD is thinking @ DDR500

loxart sem er a ddr 500. ugyanolyan 50 nanos ramcellak vannak benne. a proci 64 byte-os csomagokat ir be es olvas. a dual-os RAM kontroller 10-15%-os performance boost-ot hoz, holott 100%-ot szeretnenk latni.

[alvaro]

Idézet: SFIJ - Dátum: 2005. máj. 6., péntek - 12:34

loxart sem er a ddr 500. ugyanolyan 50 nanos ramcellak vannak benne. a proci 64 byte-os csomagokat ir be es olvas. a dual-os RAM kontroller 10-15%-os performance boost-ot hoz, holott 100%-ot szeretnenk latni.

pedig ha ugyanazt az idozitest tudjak tartani, mint a ddr400-nal, akkor ez az egyetlen ami erhet valamit. marmint az adott szabvanyon, adott mennyisegu ciklus melletti orajelnoveles. attol tenyleg gyorsabb lesz az eleres - ugyanannyi, de rovidebb ciklus.
ha rontjak az idoziteseket hozza, akkor meg valoban sz@rnak pofon.

Szerkesztette: alvaro 2005. 05. 06. 11:55 -kor

[SFIJ]

Idézet: alvaro - Dátum: 2005. máj. 6., péntek - 11:54

pedig ha ugyanazt az idozitest tudjak tartani, mint a ddr400-nal, akkor ez az egyetlen ami erhet valamit. marmint az adott szabvanyon, adott mennyisegu ciklus melletti orajelnoveles. attol tenyleg gyorsabb lesz az eleres - ugyanannyi, de rovidebb ciklus.
ha rontjak az idoziteseket hozza, akkor meg valoban sz@rnak pofon.

nos alvaro a kovetkezo tortenik, kicsit torz lesz a rajz, de szemleletes:

               ________          ________
DDR400 _______|       |________|       |________

                   ____              ____
DDR500____________|   |____________|   |_________

van egy masinan kicsit oregecske, de a benne levo ram 2-1-1-1.5T-n birja a 166MHz-et. ezzel a mutatvannyal gyorsabb vagyok mint egy 200-as FSBs PC3200 DDR400.

Szerkesztette: SFIJ 2005. 05. 06. 12:16 -kor

[Asker]

Vmit vmiért.

[alvaro]

Idézet: SFIJ - Dátum: 2005. máj. 6., péntek - 13:07

nos alvaro a kovetkezo tortenik, kicsit torz lesz a rajz, de szemleletes:

               ________          ________
DDR400 _______|       |________|       |________

                   ____              ____
DDR500____________|   |____________|   |_________

van egy masinan kicsit oregecske, de a benne levo ram 2-1-1-1.5T-n birja a 166MHz-et. ezzel a mutatvannyal gyorsabb vagyok mint egy 200-as FSBs PC3200 DDR400.

de azt mondom epp, hogy ez csak akkor tortenik, ha a ras/cas/mittomen idozitesek 5/4-szer tobb ciklust foglalnak magukban eztan. vagy valamit rosszul tudok?

[SFIJ]

Idézet: alvaro - Dátum: 2005. máj. 6., péntek - 12:17

de azt mondom epp, hogy ez csak akkor tortenik, ha a ras/cas/mittomen idozitesek 5/4-szer tobb ciklust foglalnak magukban eztan. vagy valamit rosszul tudok?

pontosan errol van szo. ma a jobb DDR400-ak 7-3-3-3-2.5T-t futnak a beharangozott DDR500 meg 8-4-4-4-3T-t fog. tehat annyit jelent a dolog, hogy van egy burst ami alatt ativtelre kerul a 64 byte. ennek a burstnek az idotartama ugyan csokken, de a burstok idobeni tavolsaga es ezzel a valos 'sustained' atviteli sebesseg sem. adtunk a szarnak egy pofont, magyaran. 8 bankod van egy DDR akarhanyas modulban, egy bank 50 nanos acces time-mal rendelkezik, tehat 50 nanonkent tud magabol uj adatot kibocsatani. ha fokozod a bankok szamat, akkor virtualice 50/8-as sebesseg fog latszani a 'burst'-ben de a burstok kozott bizony fennmarad a bigottnagy delay. a problema az hogy a CPU 'akarhonnan' (igaz igazitva) leker 64 byte-ot. amig az elso adatok becsorognak, az az ido egy orokkevalosag.

Szerkesztette: SFIJ 2005. 05. 06. 13:45 -kor