[Algemeen] AMD nieuws en discussietopic - Deel 20

[mad_max234]

Phyxion schreef op donderdag 13 december 2007 @ 13:33:
[...]

Kan best wel dat er twee lijnen naast elkaar lopen hoor.

Ja, en dat is ook zo denk ik, want de shanghai 45nm procedé heeft namelijk geen vertraging, en dat zijden ze al toen ze nog druk bezig waren met de K10 core en deze vertraging begon op te lopen, maar de 45nm zou geen vertraging hebben. Daar maak ik op uit dat ze dus aan twee dingen werken.

En volgens mijn staat de 45nm al tijden voor mass productie in half 2008 en dat zou beteken dat ze 3Q a 4Q van 2008 in de winkels moeten liggen. Klopt ook wel als je kijkt naar wanneer ze de eerste sram maken en de eerst chip, en dan de eerste sample (moet nog komen). Dan lopen ze mooi op tijd met hun ontwikkeling van 45nm en is eind 2008 in de winkels heel realistisch.

[ Voor 29% gewijzigd door mad_max234 op 13-12-2007 13:51 ]

[GENETX]

AMD heeft ook maar 2 keuzes: Of 45nm gewoon op schema houden of de 65nm versies moetne opeens toch nog goed gaan clocken, anders hebben ze simpelweg een probleem. Ik denk dat de eerste optie meer waarschijnlijk is aangezien ze ook Intel bij wilden blijven.

Overigens net een telefoontje gehad van de lokale PC boer. Hopelijk heb ik vanavond (mits mn pa tijd heeft om er even langs te gaan) mn PCtje staan met Gigabyte 770 moederbord. Morgen heb ik vrij dus de tijd om alles er op te gooien en jullie dus mijn eerste bevindingen over het bord en chipset kan melden. Een echte review zal dan wel met kerst oid komen, maar ik ga hem zeker wel schrijven

[Astennu]

GENETX schreef op donderdag 13 december 2007 @ 14:49:
AMD heeft ook maar 2 keuzes: Of 45nm gewoon op schema houden of de 65nm versies moetne opeens toch nog goed gaan clocken, anders hebben ze simpelweg een probleem. Ik denk dat de eerste optie meer waarschijnlijk is aangezien ze ook Intel bij wilden blijven.

Overigens net een telefoontje gehad van de lokale PC boer. Hopelijk heb ik vanavond (mits mn pa tijd heeft om er even langs te gaan) mn PCtje staan met Gigabyte 770 moederbord. Morgen heb ik vrij dus de tijd om alles er op te gooien en jullie dus mijn eerste bevindingen over het bord en chipset kan melden. Een echte review zal dan wel met kerst oid komen, maar ik ga hem zeker wel schrijven

65nm is geen optie dat is veel te groot Bij 45nm kun je veel meer cpu's uit een waver halen waardoor je meer kan produceren en ook goedkoper. Nadeel zijn wel de R&D kosten die er bij komen kijken.

[Wouter Tinus]

Stephan224 schreef op donderdag 13 december 2007 @ 13:21:
je kan dus gemakkelijk aannemen dat ze ondertussen heus wel werkende samples hebben

Ik vertrouw liever op uitspraken van AMD's topmanagement dan op jouw aannames.

We have 45nm on the way. We will have initial samples also in January. I'm fairly confident that those puppies are going to boot,

http://www.crn.com/white-...SNDLRSKHSCJUNN2JVN?pgno=1

[Wouter Tinus]

mad_max234 schreef op donderdag 13 december 2007 @ 13:38:
Ja, en dat is ook zo denk ik, want de shanghai 45nm procedé heeft namelijk geen vertraging, en dat zijden ze al toen ze nog druk bezig waren met de K10 core en deze vertraging begon op te lopen, maar de 45nm zou geen vertraging hebben. Daar maak ik op uit dat ze dus aan twee dingen werken.

En volgens mijn staat de 45nm al tijden voor mass productie in half 2008 en dat zou beteken dat ze 3Q a 4Q van 2008 in de winkels moeten liggen. Klopt ook wel als je kijkt naar wanneer ze de eerste sram maken en de eerst chip, en dan de eerste sample (moet nog komen). Dan lopen ze mooi op tijd met hun ontwikkeling van 45nm en is eind 2008 in de winkels heel realistisch.

Natuurlijk werken ze aan twee dingen. Maar januari eerste samples betekent op zijn best mondjesmaat beschikbaarheid in Q4, wat ze verder ook blabberen. En 32nm een jaar daarna al verwachten is gewoon dromen.

[mad_max234]

Wouter Tinus schreef op donderdag 13 december 2007 @ 15:35:
[...]

Natuurlijk werken ze aan twee dingen. Maar januari eerste samples betekent op zijn best mondjesmaat beschikbaarheid in Q4, wat ze verder ook blabberen. En 32nm een jaar daarna al verwachten is gewoon dromen.

Ik heb niks gezegd dat ze het jaar daarop met 32nm komen? En ja ik zegt toch dat ze starten half 2008 met het mass productie proces en dat betekent meestal dat ze 4e kwartaal ongeveer (hoop eerder dan normaal, omdat ze haast hebben in mijn ogen) in de winkels liggen.

[EaS]

[achtbaanfreak]

volgens deze slide zal fab 38 dus in 2009 opperationeel worden? Want als dat het geval ik vraag ik me af waar ze 45nm willen gaan produceren. In fab 36 draaien waarschijnlijk 1 of 2 runs (ik verwacht niet meer), iniedergeval niet genoeg voor massa productie. En de ombouw naar 45nm staat voor fab36 gepland H1 2008. Dus als ik dit zo lees kunnen ze nooit in mid 2008 gaan produceren op 45nm.

[GENETX]

Ik weet zo niet welke Fabs AMD allemaal heeft en of dit de enige 2 zijn. Iets zegt me dat er meer is met "AMD Dresden" bovenaan de slides.

[mad_max234]

achtbaanfreak schreef op donderdag 13 december 2007 @ 17:14:
[afbeelding]
volgens deze slide zal fab 38 dus in 2009 opperationeel worden? Want als dat het geval ik vraag ik me af waar ze 45nm willen gaan produceren. In fab 36 draaien waarschijnlijk 1 of 2 runs (ik verwacht niet meer), iniedergeval niet genoeg voor massa productie. En de ombouw naar 45nm staat voor fab36 gepland H1 2008. Dus als ik dit zo lees kunnen ze nooit in mid 2008 gaan produceren op 45nm.

Ik weet niet wat ze nu in fab 36 maken, maar tijd terug rolde daar 13.000 wafers per week uit. Ik volg het niet zo van de fabs van amd, misschien dat iemand wat meer kan vertellen die het ook echt weet hoe het zit?

[XWB]

Fab 30 deed 20 000 wafers per maand (200mm), maar laatste (jaar?) zelf 25 000 (meer dan normaal voorzien was). Fab 36 doet er 13 000. Dat lijkt minder, maar deze fab heeft wel 300mm wafers. Daarnaast is er nog ruimte om tot 20k te produceren als ik me niet vergis. Geen idee of Fab 36 al op dit niveau zit. Chartered doet ook nog een deel, geen idee hoeveel.

[ Voor 20% gewijzigd door XWB op 13-12-2007 18:39 ]

[EaS]

achtbaanfreak schreef op donderdag 13 december 2007 @ 17:14:
[afbeelding]
volgens deze slide zal fab 38 dus in 2009 opperationeel worden?

FAB30 = FAB38

FAB30 wordt omgebouwd tot een 300mm wafer faciliteit (vandaar ook het nieuwe naamplaatje FAB38).
Wat er op de slide staat: FAB30/38 zal volledig omgebouwd zijn en volledig als standalone 300mm faciliteit functioneren in 2009. Wat niet betekend dat er 0,0 output plaatsvindt tot die tijd.

Want als dat het geval ik vraag ik me af waar ze 45nm willen gaan produceren. In fab 36 draaien waarschijnlijk 1 of 2 runs (ik verwacht niet meer), iniedergeval niet genoeg voor massa productie. En de ombouw naar 45nm staat voor fab36 gepland H1 2008. Dus als ik dit zo lees kunnen ze nooit in mid 2008 gaan produceren op 45nm.

Niemand maakt een instant switch. Misschien komen de termen ramping en transitioning je bekend voor?

[mad_max234]

Hacku schreef op donderdag 13 december 2007 @ 18:38:
Fab 30 deed 20 000 wafers per maand (200mm), maar laatste (jaar?) zelf 25 000 (meer dan normaal voorzien was). Fab 36 doet er 13 000. Dat lijkt minder, maar deze fab heeft wel 300mm wafers. Daarnaast is er nog ruimte om tot 20k te produceren als ik me niet vergis. Geen idee of Fab 36 al op dit niveau zit. Chartered doet ook nog een deel, geen idee hoeveel.

Ik las dat er 12-inch wafers en dan 13.000 per week werden gemaakt. (tijd terug dat wel, in 2006)

AMD IS GEARING up its latest baby, its Fab 36 factory based in Dresden, Germany. I visited Dresden two weeks ago, which is when the ramp up began. The first 12-inch wafers are already in production. While the reps declined to comment what processors are being printed on the wafers, the press release is expected quite soon. The company execs recently gave the green light to ramp up the production to 13.000 wafer starts a week. How many of those wafers are usable, remains to be seen.

Maar dat kan fout zijn natuurlijk.

[The Source]

Voor diegene die de webcast "2007 Financial Analyst Day" willen bekijken / beluisteren;
http://www.thomson-webcas...03f3bd5200a6ee9411c6eb0f5

[EaS]

AMD voegt Swift aan roadmap toe, 'Fusion' gebaseerd op een bestaande core i.p.v. de bulldozer core:

"In one change disclosed yesterday, AMD is adjusting a plan dubbed Fusion to combine its computing circuitry with ATI's graphics technology on a single chip. In July, AMD said the first product from that effort would use a sophisticated new microprocessor design, code-named Bulldozer.

Now AMD plans to make its first multi-function chip using modifications of an existing microprocessor, in a product called Swift that will arrive in mid-2009. In an interview, Mr. Ruiz said customers wanted AMD to reduce design risks and deliver a product sooner."

Bron: AMD Says Barcelona Botch Won't Happen Again



Voor de rest van de roadmap (weinig nieuws verder): http://download.amd.com/C...sDec2007AMDAnalystDay.pdf

[ Voor 8% gewijzigd door EaS op 14-12-2007 01:50 ]

[Jejking]

EaS schreef op vrijdag 14 december 2007 @ 01:39:
AMD voegt Swift aan roadmap toe, 'Fusion' gebaseerd op een bestaande core i.p.v. de bulldozer core:

"In one change disclosed yesterday, AMD is adjusting a plan dubbed Fusion to combine its computing circuitry with ATI's graphics technology on a single chip. In July, AMD said the first product from that effort would use a sophisticated new microprocessor design, code-named Bulldozer.

Now AMD plans to make its first multi-function chip using modifications of an existing microprocessor, in a product called Swift that will arrive in mid-2009. In an interview, Mr. Ruiz said customers wanted AMD to reduce design risks and deliver a product sooner."

Bron: AMD Says Barcelona Botch Won't Happen Again

Plannen zijn leuk, nu er nog wat van maken. Eerst resultaten, dan praten we verder.

[mad_max234]

Nieuwe roadmap.









Offtopic/
De Swift met een integrate "high end GPU", wie zij der ook al weer op de frontpage dat dit nooit ging gebeuren? (hadden het toen over de fusion, maar dit komt dicht genoeg in de beurt)

[ Voor 20% gewijzigd door mad_max234 op 14-12-2007 02:52 ]

[Hekking]

Wat me opviel was dat Quad core yields even hoog waren als de dualcore's. Dat kan volgense mij ook alleen omdat ze de clockspeeds laag houden denk ik

[ronny]

Wat mij ook opvalt is dat ze bij alle sheets de shanghai ongeveer voor half 08 hebben ingepland. Dan is het echt te hopen dat de eerste samples gaan boten in januari anders wordt het echt zeer krap (onmogelijk).
Verder weet ik niet of het verstandig is om ondanks de overstap op 45 nm niet meer L2 cache toe te voegen. De L3 groeit naar 6 MB, maar ik het het al een paar keer vaker gelezen dat mensen denken dat AMD achterloopt omdat Intel zoveel meer cahce gebruikt.
We zullen zien wat dit brengt.
Het wordt toch tijd voor wat nieuws voor mij.

[mad_max234]

ronny schreef op vrijdag 14 december 2007 @ 08:52:
Wat mij ook opvalt is dat ze bij alle sheets de shanghai ongeveer voor half 08 hebben ingepland. Dan is het echt te hopen dat de eerste samples gaan boten in januari anders wordt het echt zeer krap (onmogelijk).
Verder weet ik niet of het verstandig is om ondanks de overstap op 45 nm niet meer L2 cache toe te voegen. De L3 groeit naar 6 MB, maar ik het het al een paar keer vaker gelezen dat mensen denken dat AMD achterloopt omdat Intel zoveel meer cahce gebruikt.
We zullen zien wat dit brengt.
Het wordt toch tijd voor wat nieuws voor mij.

AMD heeft niet zoveel cache nodig(heeft het altijd met minder af gekund), ligt aan de architectuur en dat de geheugen ccontroller in de cpu zit. Dit is nu wat je noemt appels met peren vergelijken, Intel heeft altijd al meer baat gehad bij sneller geheugen en meer cache dan AMD, ik heb de Phenom nog niet kunnen testen maar vermoed dat het zie zo heel veel uit maakt.

Een groei van 2MB naar 6MB is 3x meer cache, dat heeft intel echt niet gedaan met de Yorkfield 3x meer cache op haar cpu, die gaan van 8MB naar 12MB, dat is 0.5x.

[Dazsur]

Het is gewoon afwachten. Mijn 2 S939 systemen voldoen prima. Over een jaartje maar kijken!

[Phyxion]

Net mn AMD Unleashed kaartjes binnengekregen. Had ze nog niet binnen verwacht

[ronny]

mad_max234 schreef op vrijdag 14 december 2007 @ 14:06:
[...]


AMD heeft niet zoveel cache nodig(heeft het altijd met minder af gekund), ligt aan de architectuur en dat de geheugen ccontroller in de cpu zit. Dit is nu wat je noemt appels met peren vergelijken, Intel heeft altijd al meer baat gehad bij sneller geheugen en meer cache dan AMD, ik heb de Phenom nog niet kunnen testen maar vermoed dat het zie zo heel veel uit maakt.

Een groei van 2MB naar 6MB is 3x meer cache, dat heeft intel echt niet gedaan met de Yorkfield 3x meer cache op haar cpu, die gaan van 8MB naar 12MB, dat is 0.5x.

Ik weet dat AMD met minder cache toe kan, maar ik denk dat ze toch echt heel erg hebben bezuinigd op het L2 cache.
Dat de L3 is toegenomen is natuurlijk altijd goed, maar dat is ook een stuk trager als het gedeelde L2 cache van Intel.
Tentijde van de "oude" AMD waren er ook verschillende apps die wel voordeel hadden van het grotere L2 cache. Daarnaast gaat het er niet op wat ik er van weet en vind, maar wat de meerderheid van de mensheid er van vind.
Als ik het mij goed kan herinneren heeft zelfs Astennu hier een opmerking gemaakt dat hij het niets vond om dan 1MB per core terug te moeten naar 512 KB!
Volgens mij zegt dat genoeg.

[Phyxion]

Goed nieuws

Unlocked black Phenoms to come next week

A big surprise for overclockers

AMD didn’t even wanted to give up this information at investors event but it is working on the introduction of a brand new of Black series of Phenom, meant for the retail.

This CPU has been inspired by a great success of the Athlon black edition box 5000+ and 6400+ series and AMD hopes to get the same success with the unlocked Phenom's.

We don't know the clock speeds but we will try to find out.

[ Voor 4% gewijzigd door Phyxion op 14-12-2007 21:07 ]

[mad_max234]

ronny schreef op vrijdag 14 december 2007 @ 20:34:
[...]


Ik weet dat AMD met minder cache toe kan, maar ik denk dat ze toch echt heel erg hebben bezuinigd op het L2 cache.
Dat de L3 is toegenomen is natuurlijk altijd goed, maar dat is ook een stuk trager als het gedeelde L2 cache van Intel.
Tentijde van de "oude" AMD waren er ook verschillende apps die wel voordeel hadden van het grotere L2 cache. Daarnaast gaat het er niet op wat ik er van weet en vind, maar wat de meerderheid van de mensheid er van vind.
Als ik het mij goed kan herinneren heeft zelfs Astennu hier een opmerking gemaakt dat hij het niets vond om dan 1MB per core terug te moeten naar 512 KB!
Volgens mij zegt dat genoeg.

Dan moet Astennu nog maar eens goed onderzoek doen, en jij ook. En ik heb het niet over wat de rest van de wereld denk, want die zeggen cache???? wat is dat, die kan het een worst wezen als hij maar doet wat hij moet doen. En ga niet op andermans slimme opmerking af, maar trek je eigen conclusies. (doe onderzoek)


Bron:http://www.xbitlabs.com/a...lay/core2duo-e6420_3.html

We hebben het dus over tweakers die weten wat cache is, maar er niet genoeg verstand hebben en niet helemaal weten waar ze over praten. cache is leuk maar zelfs de C2D heeft er maar een paar procent (soms zelfs nog geen 1% en soms net 5%) voordeel bij, en dat bij het verdubbelen van de cache.

[ Voor 4% gewijzigd door mad_max234 op 14-12-2007 21:55 ]

[Wouter Tinus]

cache is leuk maar zelfs de C2D heeft er maar een paar procent (soms zelfs nog geen 1% en soms net 5%) voordeel bij heeft, en dat het verdubbelen van de cache.

Het effect van de hoeveelheid cache op de prestaties van applicaties is een curve die in het begin heel stijl is, maar daarna ook heel snel vlak wordt. De stap van 512KB naar 1MB is dus een stuk meer waard dan die van 2MB naar 4MB. Zie hier bijvoorbeeld een grafiek voor SPECint2000 (wat verouderd dus, maar het illustreert het punt wel):

http://en.wikipedia.org/wiki/Image:Cache%2Cmissrate.svg

Je ziet hier dat het verschil tussen een 1MB cache en een oneindig groot cache relatief weinig is (dus laat staan tussen 2MB en 4MB ), terwijl in het gebied tussen 64KB en 1MB enorme winsten te halen zijn (deels afhankelijk van de verdere architectuur).

Voor de benchmark in die grafiek is 512KB eigenlijk ook al genoeg, maar de trends van de laatste zeven jaar (snellere cores, grotere geheugens, meer bloated software) zullen dat "goed genoeg"-punt zeker naar boven geschoven hebben voor veel toepassingen. Dat er überhaupt al desktopapplicaties bestaan die nog duidelijk kunnen profiteren van 4MB of zelfs 6MB cache is daar een duidelijk teken van, en in servers lopen ze natuurlijk altijd voor.

[ Voor 19% gewijzigd door Wouter Tinus op 14-12-2007 22:33 ]

[mad_max234]

Ja dat is altijd al zo geweest, dat meer cache ook steeds minder voordeeld behaald naar maten je het vergroot. En er zijn wel wat taken die er voordeel bij kunnen hebben, maar veel is het vaak niet.

Game hebben nog het meeste voordeel van meer cache omdat ze bijna altijd veel het geheugen aanspreken. Maar daar zou de Phenom nog een voordeeltjehebben tov de C2Q, de integrate controller. Al dacht ik laatst iets gelezen te hebben dat de delay best tegen viel, en ondanks de L3 de delay hoger was dan die van de K8.

[Wouter Tinus]

mad_max234 schreef op zaterdag 15 december 2007 @ 00:05:
Ja dat is altijd al zo geweest, dat meer cache ook steeds minder voordeeld behaald naar maten je het vergroot. En er zijn wel wat taken die er voordeel bij kunnen hebben, maar veel is het vaak niet.

Als dat allemaal klare koek is, waarom suggereer je dan dat 512KB tot 1MB weinig uitmaakt omdat 2MB of 4MB ook weinig uitmaakt? Je andere argument (de geïntegreerde geheugencontroller) is een heel stuk beter en het toevoegen van het L3 als backup helpt ook zeker, maar 512KB L2 per
core is en blijft gewoon aan de lage kant voor een moderne processor:

K10: 512KB per core * **
Sun T2: 512KB per core, shared tot 4MB *
K8: 1MB per core *
Itanium: 1,25MB per core **
Xeon: 3MB per core, shared tot 6MB
Fujitsu: 3MB per core, shared tot 6MB *
Power: 4MB per core, shared tot 8MB * **

* Geintegreerde geheugencontroller
** L3-cache

Ik denk dat de stap van 512KB naar 1MB L2 voor veel toepassingen meer zal opleveren dan de stap van 2MB naar 6MB L3.

[mad_max234]

Wouter Tinus schreef op zaterdag 15 december 2007 @ 03:34:
[...]

Als dat allemaal klare koek is, waarom suggereer je dan dat 512KB tot 1MB weinig uitmaakt omdat 2MB of 4MB ook weinig uitmaakt? Je andere argument (de geïntegreerde geheugencontroller) is een heel stuk beter en het toevoegen van het L3 als backup helpt ook zeker, maar 512KB L2 per
core is en blijft gewoon aan de lage kant voor een moderne processor:

Hoe kom je daar nu weer bij, ik zal de laatste zijn die dat beweerd, ik weet dat al jaren dat hoe kleiner de cache hoe meer invloed dat heeft als je hem vergroot. Dat is dus gesneden koek voor mij ja

Maar de stap van 512KB naar 1024KB is al niet echt groot bij de K9 (al weet niemand hoe dat bij de Phenom is), en AMD heeft over het algemeen minder last van latency, daarom gaf ik juist C2D ook als voorbeeld omdat die waarschijnlijk nog het meeste baat heeft bij meer cache, van deze twee. (omdat conroe nog een fsb heeft via de chipset)

Wat denk jij dat dat het voor een impact het heeft? Ik denk in de meeste gevallen bijna niks en game maximaal 10% en dan nog geen eens in alle games. AMD heeft toen niet voor niks gedaan , dat was omdat het gewoon niet zoveel scheelde. (was in hun ogen niet de kosten waard)

En je kan het niet met me eens zijn, dat is jou goed recht. Zelfs de stap van 512KB naar 256KB (Sempron) maakt nog niet zo heel veel uit (ongeveer het zelfde als 512KB naar 1024KB, misschien iets meer), en nu zins de conroe maakt het bij intel ook weer iets minder uit dan met de Netburst.

Ik denk dat de stap van 512KB naar 1MB L2 voor veel toepassingen meer zal opleveren dan de stap van 2MB naar 6MB L3.

Ja dat zou kunnen maar veel zal het niet zijn, ze maken alle twee niet zoveel uit denk ik, misschien dat ze samen nog voor een boots kunnen zorgen die je wel gaat merken, want 10% is nauwelijks merkbaar, en daaronder al helemaal niet.

Edit/

Kijk in de meeste gevallen scheelt de stap daaronder iets meer maar nog geen eens zoveel meer. (sommige gevallen iets meer dan andere)





SuperPi laat hier wel een groter verschil zien, stap onder de 1MB zal hier waarschijnlijk nog veel groter zijn. (was te verwachten )




Nu is dit natuurlijk geen Phenom, maar de C2D heeft volgens mijn nog steeds meer baat bij meer cache omdat hij over de chipset via de FSB met het geheugen in verbinding staat.

In sommige gevallen buiten game om, is het 2x zoveel niks is nog steeds niks.

[ Voor 28% gewijzigd door mad_max234 op 16-12-2007 01:29 ]

[Xadeon]

offtopic:
Ik heb nogal moeite om je verhaal te lezen, door spel- of typefouten en misplaatste leestekens. Maar goed dat terzijde.

Zover ik heb kunnen opmaken uit je reactie, spreek jij je zelf een beetje tegen.

mad_max234 schreef op zaterdag 15 december 2007 @ 04:39:
[...]


Hoe kom je daar nu weer bij, ik zal de laatste zijn die dat beweerd, ik weet dat al jaren dat hoe kleiner de cache hoe meer invloed dat heeft als je hem vergroot. Dat is dus gesneden koek voor mij ja

Wat denk jij dat dat het voor een impact het heeft? Ik denk in de meeste gevallen bijna niks en game maximaal 10% en dan nog geen eens in alle games. AMD heeft toen niet voor niks gedaan , dat was omdat het gewoon niet zoveel scheelde. (was in hun ogen niet de kosten waard)

En je kan het niet met me eens zijn, dat is jou goed recht. Zelfs de stap van 512KB naar 256KB (Sempron) maakt nog niet zo heel veel uit (ongeveer het zelfde als 512KB naar 1024KB, misschien iets meer), en nu zins de conroe maakt het bij intel ook weer iets minder uit dan met de Netburst.

Ja dat zou kunnen maar veel zal het niet zijn, ze maken alle twee niet zoveel uit denk ik, misschien dat ze samen nog voor een boots kunnen zorgen die je wel gaat merken, want 10% is nauwelijks merkbaar, en daaronder al helemaal niet.

Nu is dit natuurlijk geen Phenom, maar de C2D heeft volgens mijn nog steeds meer baat bij meer cache omdat hij over de chipset via de FSB met het geheugen in verbinding staat.

Ik denk dat Wouter Tinus probeert uit te leggen, dat hoe groter de cache hoe lager de impact. Afgezien of het hier gaat om een AMD of een Intel.
Verder is het mij niet duidelijk of in de benchmarks die je aanhaalt de processors gelijk geklokt zijn of niet, want neem aan dat dat meer invloed heeft.

edit: Het punt dat een grotere cache(bijv. 6mb) nog geen weinig prestatie winst opleveren komt volgens mij doordat er maar weinig progs zijn die echt behoefte hebben aan een grote(re) cache. AMD is zich daar schijnbaar van bewust, want grotere caches kosten eenmaal veel geld en waarom die implanteren als er slechts enkele progs daar gebruik van maken. Daarnaast kan AMD bij behoefte aan een grote(re) cache toch redelijk opvangen door de geïntegreerde memorycontroller. Maar zover ik uit Wouter Tinus z'n verhaal kon opmaken. Zal dat in de toekomst wel degelijk veranderen.

[ Voor 13% gewijzigd door Xadeon op 15-12-2007 09:38 ]

[albatross]

mad_max234 schreef op zaterdag 15 december 2007 @ 04:39:
Wat denk jij dat dat het voor een impact het heeft? Ik denk in de meeste gevallen bijna niks en game maximaal 10% en dan nog geen eens in alle games. AMD heeft toen niet voor niks gedaan , dat was omdat het gewoon niet zoveel scheelde. (was in hun ogen niet de kosten waard)

(...)

In sommige gevallen buiten game om, is het 2x zoveel niks is nog steeds niks.

Waarom zou een game daar zo veel baat bij hebben? Ik zou eerder denken dat, sinds de throughput bij gamen heel hoog is, dat een game er nauwelijks iets aan heeft. Correct me if I'm wrong. Nee, echt, ik wil het graag weten.

[kalizec]

Ik denk dat er nog iets over het hoofd gezien wordt.

De L2 en L3 caches van AMD zijn 'exclusive'. De L2 cache van Intel is 'inclusief'.
Dat betekent dat er meer informatie in de caches van AMD past dan bij Intel.
Dat werkt als volgt.

Een inclusive L2 cache heeft alle info die in L1 staat ook zelf opgeslagen staan plus nog meer.
Een exclusive L2 cache heeft alleen info opgeslagen staan die niet al in L1 staat.

Dat betekent dat als als de L1 cache 256kB is en de L2 cache is 512kB dat de CPU dus 768kB data kan cachen als de cache 'exclusive' is en slechts 512kB als de cache 'inclusive' is.

[edit]

Verder is er dan ook nog associetiviteit. Een 8-way 'associative' cache van 512kB zal een lagere misrate hebben dan een 2-way associative cache van 1024kB. Omdat iedere geheugen plaats niet een eigen stukje cache kan hebben, en het ook niet haalbaar is om alle cache te doorzoeken op zoek naar het antwoord bepaald associetiviteit op hoeveel plaatsen gezocht kan worden. Je kun je je afvragen waar dat goed voor is, want het staat er in, of het staat er niet in. Maar aangezien ieder geheugen adres aan een of meerdere cache-locaties gekoppeld staat, dan betekent dat dat die locatie overschreven wordt als er een ander geheugenadres opgeslagen moet toevallig ook met die plaats geassocieerd wordt.

Kortom, er komt meer bij cache kijken dan alleen grootte. Dus gewoon cache-groottes vergelijken is zinloos. Misrates vergelijken is wel zinnig.

[ Voor 41% gewijzigd door kalizec op 15-12-2007 11:40 ]

[Joepi]

Blijkbaar is er iets gruwelijk mis met de latency in zowel L2 als L3 want de watts rijzen torenhoog de pan uit als je de B2 op 2.7GHz (dus 9900!) krikt
De japanners in akiba hebben weer eens kortdaad een OC-poging gedaan (gewoon ut of the box, hoppa, ik bewonder die handelaren van akiba echt voor dit: wie doet dit nou in NL... iemand?)
http://www.watch.impress..../20071215/etc_phenom.html
Kijk maar:

http://pc.watch.impress.co.jp/docs/2007/1215/tawada122.htm

Interessant is ook best dat hier voor het eerst een Gigabyte GA-MA790FX-DQ6（AMD 790FX） opduikt (enige mobo met aangepaste bios zoveer ik weet!)
Misschien was het een fout van AMD dat ze MSI als launchpartner gekozen hebben
Gigabyte is nu toch veel beter thuis in aktuele tweaks dan MSI, dat wel aan het 'terug komen' is, ok.
Blijkbaar heeft men zich blind gestaard op "Spider" met Quad-CF enz.

Ook best vreemd dat alle positive nieuws over streamcomputing niet eens genoemd werd in polen!?
de nieuwste telg:
http://ati.amd.com/techno...ting/stream-computing.pdf

info:
http://ati.amd.com/technology/streamcomputing/folding.html
btw...:
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=teamstats
gogogo!

[mad_max234]

Xadeon schreef op zaterdag 15 december 2007 @ 09:24:

offtopic:
Ik heb nogal moeite om je verhaal te lezen, door spel- of typefouten en misplaatste leestekens. Maar goed dat terzijde.

Zover ik heb kunnen opmaken uit je reactie, spreek jij je zelf een beetje tegen.

Nee niet vergeten, gewoon even buiten beschouwing gelaten, om het niet theoretische nog ingewikkelder te maken. Ook niet belangrijk in onze discussie vind je wel, want ik vergelijk de cache van conroe tot conroe, en K8/k9 met K8/K9.

Xadeon schreef op zaterdag 15 december 2007 @ 09:24:

offtopic:
Ik heb nogal moeite om je verhaal te lezen, door spel- of typefouten en misplaatste leestekens. Maar goed dat terzijde.

Zover ik heb kunnen opmaken uit je reactie, spreek jij je zelf een beetje tegen.


[...]


Ik denk dat Wouter Tinus probeert uit te leggen, dat hoe groter de cache hoe lager de impact. Afgezien of het hier gaat om een AMD of een Intel.
Verder is het mij niet duidelijk of in de benchmarks die je aanhaalt de processors gelijk geklokt zijn of niet, want neem aan dat dat meer invloed heeft.

edit: Het punt dat een grotere cache(bijv. 6mb) nog geen weinig prestatie winst opleveren komt volgens mij doordat er maar weinig progs zijn die echt behoefte hebben aan een grote(re) cache. AMD is zich daar schijnbaar van bewust, want grotere caches kosten eenmaal veel geld en waarom die implanteren als er slechts enkele progs daar gebruik van maken. Daarnaast kan AMD bij behoefte aan een grote(re) cache toch redelijk opvangen door de geïntegreerde memorycontroller. Maar zover ik uit Wouter Tinus z'n verhaal kon opmaken. Zal dat in de toekomst wel degelijk veranderen.

offtopic/
Ben dyslectische, als je iets niet begrijp, vraag het dan probeer ik het beter uit te leggen. (En het was nogal laat)

ontopic/
En ja ik weet wat hij probeer uit te leggen, en dat klopt ook, maar het scheelt gewoon niet zoveel, wel iets maar niet zoveel. misschien als je nog kleiner dan 512KB per core, maar de sempron heeft er ook niet zoveel last van. En ja de curve zal minder stijl worden naar maten je cache toe voegt. maar zwakt niet zo heel snel af zoals praktijk benchmakrs laten zien.

Korte uitleg:
Kort gezegd tinus zegt, minder cache maakt veel uit bij 1MB cache per core, hoe minder cache hoe groter de impact, in het gebied tussen 64KB en 1MB enorme winsten te halen zijn

Ik zeg dat dat wel mee valt, en dat het meestal niet zoveel uitmaakt, en dat de grote van de impact ook wel mee valt met dit soort grote van cache. (misschien 64KB naar 128KB dat het een wereld van verschil is ) Maar tussen 256 en 512KB maakt het zelfs niet zoveel uit, kijk maar naar de sempron.

Lange uitleg:
Zie paar posten hoger

En waar spreek ik me tegen dan? Weet donders goed waar ik het over heb, dus lijkt me sterk.

albatross schreef op zaterdag 15 december 2007 @ 09:36:
[...]


Waarom zou een game daar zo veel baat bij hebben? Ik zou eerder denken dat, sinds de throughput bij gamen heel hoog is, dat een game er nauwelijks iets aan heeft. Correct me if I'm wrong. Nee, echt, ik wil het graag weten.

Lezen, en benchemarks opzoeken. Game hebben meestal de meeste baat zoals je in de benchmaks kan zien. Dit omdat ze relatieve vaak het geheugen nodig hebben, meer dan ander gangbare desktop software.

[ Voor 170% gewijzigd door mad_max234 op 15-12-2007 15:29 ]

[albatross]

mad_max234 schreef op zaterdag 15 december 2007 @ 14:26:
Lezen, en benchemarks opzoeken. Game hebben meestal de meeste baat zoals je in de benchmaks kan zien. Dit omdat ze relatieve vaak het geheugen nodig hebben, meer dan ander gangbare desktop software.

Ja, de benchmarks spreken voor zich. Alleen verbaaste ik me een beetje, omdat ik dacht dat de throughput erg hoog zou zijn in een game, waardoor je weing aan je cache zou hebben. Kennelijk valt dat nog wel mee, dus.

[XWB]

mad_max234 schreef op donderdag 13 december 2007 @ 19:11:
[...]


Ik las dat er 12-inch wafers en dan 13.000 per week werden gemaakt. (tijd terug dat wel, in 2006)

13k per week? Lijkt me niet.

[mad_max234]

Hacku schreef op zaterdag 15 december 2007 @ 14:50:
[...]


13k per week? Lijkt me niet.

Nee, vond het ook al vreemd, maar dat stond er echt zoals je kan zien. (en gaf ook al aan in mijn post dat het fout zou kunnen zijn, maar dat heb je niet ge quote. )

The company execs recently gave the green light to ramp up the production to 13.000 wafer starts a week. How many of those wafers are usable, remains to be seen.

albatross schreef op zaterdag 15 december 2007 @ 14:49:
[...]


Ja, de benchmarks spreken voor zich. Alleen verbaaste ik me een beetje, omdat ik dacht dat de throughput erg hoog zou zijn in een game, waardoor je weing aan je cache zou hebben. Kennelijk valt dat nog wel mee, dus.

Game zijn vaak juist het enigste die rond de 5-10% verschil laten zien bij het verdubbelen van de cache, de rest van de desktop software vaak maar 0-1% met uitschieters erbij van paar procent.

[ Voor 71% gewijzigd door mad_max234 op 15-12-2007 15:26 ]

[Xadeon]

mad_max234 schreef op zaterdag 15 december 2007 @ 14:26:

offtopic:
Ben dyslectische, als je iets niet begrijp, vraag het dan probeer ik het beter uit te leggen. (En het was nogal laat)

offtopic:
Mijn excuses, dat wist ik niet.

[achtbaanfreak]

Hacku schreef op zaterdag 15 december 2007 @ 14:50:
[...]


13k per week? Lijkt me niet.

Er staat me bij dat op de frontpage stond dat FAB 30 + 36 samen 50K wafers per maan produceren, maar kan het bericht zo snel niet vinden.

edit:
artiekel gevonden, en ik heb het fout gelezen. Er staat dat met de bump en test facilitie in gebruik FAB 38 45K wafers per maand zal gaan produceren.

quote: http://tweakers.net/nieuw...n-vernieuwing-fab-30.html

In de tweede helft van volgend jaar moet de productie van 65nm-chips in Fab 38 op stoom komen, en eind 2008 zou de maximale capaciteit van de fabriek zijn bereikt. Samen met de Fab 36-verbouwing en de nieuwe testfaciliteiten moet Fab 38 per maand ruwweg 45.000 wafers van 300mm kunnen produceren

[ Voor 48% gewijzigd door achtbaanfreak op 15-12-2007 17:20 ]

[mad_max234]

Dan klopt die 13.000 wel per week met een beetje creatief afronden.

Xadeon schreef op zaterdag 15 december 2007 @ 16:58:
[...]

offtopic:
Mijn excuses, dat wist ik niet.

Offtopic/
Maakt niks uit. Je ben netjes dus leg ik het ook netjes uit, en het is mij tekortkoming. Ik doe me best om het begrijpelijk te maken, maar soms is het niet te lezen dat weet ik. Maar daar kom ik pas achter als ik het voor de 10x lees of een dag later zie ik het pas als ik het nog eens terug lees. Soms staan er woorden tussen die er niet horen, of iets in die richting. kan je nog eens lachen zal ik maar zeggen.

[ Voor 82% gewijzigd door mad_max234 op 15-12-2007 18:07 ]

[XWB]

Dan klopt die 13.000 wel per week met een beetje creatief afronden.

Klopt niet. Fab 36 + 38 samen 45k per maand, waarvan Fab 30/38 zeker 25k op zich kan nemen = 20k voor Fab 36. En dat kan kloppen, toen Fab 36 productieklaar was kon deze 13k wafers per maand produceren en later opgekrikt worden naar 20k.

[Wouter Tinus]

mad_max234 schreef op zaterdag 15 december 2007 @ 04:39:
Hoe kom je daar nu weer bij, ik zal de laatste zijn die dat beweerd,

Ik citeer:

cache is leuk maar zelfs de C2D heeft er maar een paar procent (soms zelfs nog geen 1% en soms net 5%) voordeel bij, en dat bij het verdubbelen van de cache.

Je praat hier over het verdubbelen van 2MB naar 4MB in een poging om ronny ervan te overtuigen dat 512KB of 1MB weinig uitmaakt. Kromme logica tot en met. Dus als je echt zo goed weet waar je over praat druk je jezelf gewoon niet goed uit (en dat kun je niet op dyslexie afschuiven).

En in deze post doe je het gewoon vrolijk weer:

Kijk in de meeste gevallen scheelt de stap daaronder iets meer maar nog geen eens zoveel meer. (sommige gevallen iets meer dan andere)

1MB-2MB benchmarks zijn geen bewijs in een discussie over 512KB-1MB, want als je op dezelfde manier door redeneert hou je uiteindelijk helemaal geen cache meer over. Je beweert dat allemaal te snappen, maar je blijft die fout toch herhalen.

Ik zal eens wat echt relevante data geven: Windsor (1MB) vs. Brisbane (512KB) benchmarks:

http://www.hothardware.co...n_64_X2_65nm_BrisbaneCore

Daar zie je dat het verschil tussen inderdaad niet groot is voor desktopapplicaties.

[mad_max234]

Wouter Tinus schreef op zaterdag 15 december 2007 @ 19:35:
[...]


Ik zal eens wat echt relevante data geven: Windsor (1MB) vs. Brisbane (512KB) benchmarks:

http://www.hothardware.co...n_64_X2_65nm_BrisbaneCore

Daar zie je dat het verschil tussen inderdaad niet groot is voor desktopapplicaties.

Nou dan zijn we er toch, waarom dan tegenspreken als je helemaal aan het einde mijn punt bevestigt. (en neem aan dat je zelf ook wel over deze kennis beschikte voordat je ging posten? Ik namelijk wel. )

Of je nu 1MB -> 2MB pakt, of 2MB ->4MB of 512KB -> 1MB, k8/k9 of C2D, het maakt allemaal niet zoveel uit. Maar ga je van 512KB naar 4MB zal je wel iets meer verschil zien, maar zal niet veel zijn, maakt bijna in geen geval veel verschil. Dus waarom je druk maken als AMD geen 1MB gebruikt? Als het nu de stap van 512kb -> 2MB zou zijn per core, dan kom ik er misschien nog op terug. (En ja ik snap dat de curve in het begin iets steiler is, en dat het bij een bepaalde grote steeds minder uitmaakt)

1MB-2MB benchmarks zijn geen bewijs in een discussie over 512KB-1MB, want als je op dezelfde manier door redeneert hou je uiteindelijk helemaal geen cache meer over. Je beweert dat allemaal te snappen, maar je blijft die fout toch herhalen.

Dat was de eerste benchmark die ik tegen kwam, misschien fout van me omdat als voorbeeld te nemen, maar ik wist dat het met een K9 niet veel beter zal zijn. Zelfs minder gevoelig is voor de stap 512KB -> 1MB, dan de C2D voor de stap van 1MB -> 2MB of 2MB -> 4MB.

En ik weet niet hoor maar ik zeg toch dat cache wel impact heeft, maar niet een verdubbeling(in AMD zijn geval halvering). Dus weet niet maar je redenering klopt dus niet met wat ik zeg.

We hebben het over stapjes (verdubbeling/halvering), en kom je in eens met: "want als je op dezelfde manier door redeneert hou je uiteindelijk helemaal geen cache meer over"

Natuurlijk moet je cache hebben, jij beweerd dat ik dat niet vind. Is weer een vermakelijke avond.

Offtopic/
[quote]
(en dat kun je niet op dyslexie afschuiven).
[/quote]

Weet je wel wat dyslectisch inhoud? (Er zijn zoveel soorten, maar lettelijk is het: moeite met taal) Ik moet soms andere woorden kiezen omdat ik op dat moment niet weet hoe ik het schijf en zelfs de spellingscontrole kan me niet altijd goed aanvullen dat is maar 'e'en probleem, dan heb ik ook dat ik zinnen door elkaar gooi, en woorden oversla of juist ertussen prop. Dit heb ik meer als ik stress heb of moe ben of bijvoorbeeld alcohol op heb.

[ Voor 52% gewijzigd door mad_max234 op 16-12-2007 01:32 ]

[Hekking]

Hacku schreef op zaterdag 15 december 2007 @ 18:25:
[...]


Klopt niet. Fab 36 + 38 samen 45k per maand, waarvan Fab 30/38 zeker 25k op zich kan nemen = 20k voor Fab 36. En dat kan kloppen, toen Fab 36 productieklaar was kon deze 13k wafers per maand produceren en later opgekrikt worden naar 20k.

Als ik naar foto's kijk in de start post is FAB 36 1,5 keer groter dan fab 30/38.

Hier een quote van anandtech :In terms of capacity, by 2008 AMD plans to be able to crank out 20,000 (300mm) wafers per month out of Fab 36 which would double its microprocessor production capacity to approximately 100M CPUs per year (thanks to larger wafers and smaller transistors). For comparison, Fab 30 currently produces 30,000 (200mm) wafers per month. Unfortunately AMD was unable to provide us with any sort of guidance as to how quickly Fab 36 will ramp up to its 20K per month target. AMD's partnership with Chartered

Ik denk zelf dat fab 38 net aan de 10k komt momenteel. Het 90 Nm materiaal is net verkocht en de ombouw naar 65 Nm is vertraagt.

quote tweakers : Na de aanpassing, die in 2009 afgerond zou moeten worden, zou Fab 30 als Fab 38 door het leven gaan en zouden er 65nm- of 45nm-chips geproduceerd gaan worden.

Ik denk dat chatered een leuk aandeel heeft in de 65 Nm productie van dual cores. ik meende dat ook in de presentatie van AMD werd gezegt dat FAB 36 de enige was die quad core maakte. Chartered zal mss wel 20 K brisbane wafers produceren.

[XWB]

Chartered zal mss wel 20 K brisbane wafers produceren.

Kan je uitrekenen, AMD mag maximaal 20% uitbesteden. Hoe groter de productie, hoe meer ze kunnen uitbesteden.

[Maikel205]

Joepi schreef op zaterdag 15 december 2007 @ 13:20:
Blijkbaar is er iets gruwelijk mis met de latency in zowel L2 als L3 want de watts rijzen torenhoog de pan uit als je de B2 op 2.7GHz (dus 9900!) krikt

Op 2.7GHZ heeft de 9500 ook meer voltage nodig, dus niet vreemd dat het stroomgebruik een stuk hoger is. Dit tegelijk het probleem waar AMD mee zit, dat de meeste Phenoms op hogere snelheden niet stabiel zijn op standaard voltage.

[NitroX infinity]

Waren deze al bekend?

Athlon64 LE-1600 (45Watt, Single core, 2,2GHz, 1MiB L2, AM2)
AMD Pagina: linkje
Athlon64 LE-1620 (45Watt, Single core, 2,4GHz, 1MiB L2, AM2)
AMD Pagina: linkje

[ Voor 74% gewijzigd door NitroX infinity op 16-12-2007 10:29 ]

[XWB]

Yep, die zijn al een tijdje beschikbaar. Deze volgen de single core 3500 en 3800+ op die nog in omloop waren.

[Aries.Mu]

Hmmm, zo wordt een Phenom toch wel interessant...

http://azerty.nl/producte...ail/603/58767/phenom.html

Lees BTW ook de mini-review eronder, 3.0Ghz lijkt leuk met dat Overdrive programma.
De vraag is: welke processor biedt nu het meeste "bang for buck"? De Q6600 of deze?

[mad_max234]

Aries.Mu schreef op zondag 16 december 2007 @ 20:02:
Hmmm, zo wordt een Phenom toch wel interessant...

http://azerty.nl/producte...ail/603/58767/phenom.html

Lees BTW ook de mini-review eronder, 3.0Ghz lijkt leuk met dat Overdrive programma.
De vraag is: welke processor biedt nu het meeste "bang for buck"? De Q6600 of deze?

Lekker, van de week was hij nog 191 euro, word al stuk interessanter nu nog even wachten op de B3 stepping en madmax234 gaat er een halen, en hem een flink aan de tand voelen Leuk cadeautje voor een goede start in 2008.

En misschien de Phenom 9600 blach edition volgende week.

[ Voor 4% gewijzigd door mad_max234 op 16-12-2007 21:51 ]

[Maikel205]

mad_max234 schreef op zondag 16 december 2007 @ 21:49:
[...]


Lekker, van de week was hij nog 191 euro, word al stuk interessanter nu nog even wachten op de B3 stepping en madmax234 gaat er een halen, en hem een flink aan de tand voelen Leuk cadeautje voor een goede start in 2008.

En misschien de Phenom 9600 blach edition volgende week.

Zo te zien morgen al:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1197724403

[ Voor 51% gewijzigd door Maikel205 op 16-12-2007 22:50 ]

[mad_max234]

We zul zien.

Even iets anders, nieuwe Propus Quad en triple cores, 2 helft van 2008. En leo krijgt 1Q van 2009 een update voor AM3 package, hoop ook dat de bestaande AM2+ mobo een update krijgen. En de RD800 chipset staat dan voor de deur.

LEO platform takes over Spider Platform in 2H 2008 for enthusiast market

In 2H 2008, The "LEO" Platform will supercede the previously announced Spider Platform. By 2H 2008, The two new Deneb and Propus Quad and Triple cores will be out. Both wlil be 45nm processors with DDR2 and HT3 support.

Chipset of choice remains the same which will be AMD 790FX, 790 or 770, but paired with a newer south bridge, the SB700.

Graphics card shall be ATi R600 series with support of ATi CrossFire X on 790FX or 790X chipset.

In Q1 of 2009, The LEO platform will get an update with AM3 packaging and DDR3 support. New chipset RD800 series will be introduced with SB800. A new series of GPU the ATI R700 series will be introduced.

[ Voor 7% gewijzigd door mad_max234 op 17-12-2007 01:29 ]

[Astennu]

Nog even heel kort over die L2 cache discussie. Ik heb dat toen inderdaad gezegd. In sommige gevallen hielp het heel veel gelijk aan 200/300 MHz verschil in cpu speed. Dus had je een 2400 MHz cpu nodig waar de 2x512kb 2.6 nodig had om dezelfde performance te halen. Dus daarom wou ik niet terug naar een 2x512 kb omdat die 2x1mb na genoeg even hoog konden clocken en ik op die manier dus de beste performance had.

En even over dat Griffen notebook platform. Wat ik nu zie is dat het dus nog steeds een K9 core is met wat hele kleine tweaks en wat extra power saving en thats it ? Dan mogen ze die wel heel goedkoop maken want Intel is een heel stuk snell op gelijke clockspeeds. + Voor 2009 pas de refresh met een K10 achtige core. Ik vraag me af hoe lang intel er over gaat doen om een soort nehalem based notebook cpu klaar te maken. Ik mag hopen dat de opvolger van Griffen dan op 45nm is en die verbeterde IPC heeft die de desktop cpu's ook krijgen anders wordt het heel vervelend.

Ik zag trouwens ook staan dat fusion een high end discrete gpu krijgt. Dat zou dus een RV670 zijn echter is die op 55nm gemaakt dus dat lijkt me wat sterk zo i zo is een gpu zoals de RV670 nog te groot om aan een cpu toe te voegen ik denk eerder aan de low end kaartjes misschien iets alla HD2600 XT maar zelfs dat is erg groot.

[ Voor 52% gewijzigd door Astennu op 17-12-2007 09:32 ]

[mad_max234]

Astennu schreef op maandag 17 december 2007 @ 09:28:


Ik zag trouwens ook staan dat fusion een high end discrete gpu krijgt. Dat zou dus een RV670 zijn echter is die op 55nm gemaakt dus dat lijkt me wat sterk zo i zo is een gpu zoals de RV670 nog te groot om aan een cpu toe te voegen ik denk eerder aan de low end kaartjes misschien iets alla HD2600 XT maar zelfs dat is erg groot.

Gebaseerd op de High end van dit moment. De 690G is ook gebaseerd op x700, maar zit geen hele x700 in de chipset. En we hebben het dan al weer over 45nm, en fusion Swift gaat waarschijnlijk niet uit een stuk silicon bestaan, kan zijn dat de cpu (K10.5 waarschijnlijk) en gpu gewoon twee losse chips zijn, op 1 cpu voetje/pcb. (of hoe noem je dat?)

Zoals de Xenos in de Xbox 360, maar dan cpu+gpu


En over die cache, als het al 200Mhz scheelde (meestal niet) dan is het nog geen 10% van de 2400Mhz, dus daar heb je niks aan.(ga je niet merken) 300Mhz is net iets meer dan 10% van de 2400Mhz, maar de benchamrks laten zien dat de stap 512KB -> 1MB dat je aan die 10% eigenlijk alleen maar komt met paar games en lang niet allemaal. Meestal is de winst ver te zoeken.

[ Voor 25% gewijzigd door mad_max234 op 17-12-2007 16:33 ]

[craio]

Niet zeker indien dit hier hoort.
M'n vraag is indien AM2 compatibele koelers ook op AM2+ moederborden passen. Ik denk van wel maar zou een GA-MA770-DS3 +X2 5000+(BE) + Scythe Ninja RevB kopen en wil zeker zijn.

[mad_max234]

craio schreef op maandag 17 december 2007 @ 15:56:
Niet zeker indien dit hier hoort.
M'n vraag is indien AM2 compatibele koelers ook op AM2+ moederborden passen. Ik denk van wel maar zou een GA-MA770-DS3 +X2 5000+(BE) + Scythe Ninja RevB kopen en wil zeker zijn.

Ja de cpu koeler brachet is het zelfde van AM2 en AM2+, maar kijk even of er niks in de weg zit op het mobo. Zover ik weet is er nog niemand met een GA-MA770 + Scythe Ninja hier op het forum, dus ervaring met deze twee is er denk ik nog niet.

En misschien kan je Scythe eens een mailtje sturen.

[ Voor 24% gewijzigd door mad_max234 op 17-12-2007 17:46 ]

[GENETX]

Nee, ik bleek wel een GA-MA790X voor een schappelijke prijs te hebben gekregen. Maar het enige verschil tussen AM2 en AM2+ is alleen de HT3.0 support. De stock cooler van AMD zit er namelijk hier ook gewoon op (5600+)

[craio]

mad_max234 schreef op maandag 17 december 2007 @ 16:00:
[...]

Ja de cpu koeler brachet is het zelfde van AM2 en AM2+, maar kijk even of er niks in de weg zit op het mobo. Zover ik weet is er nog niemand met een GA-MA770 + Scythe Ninja hier op het forum, dus ervaring met deze twee is er denk ik nog niet.

En misschien kan je Scythe eens een mailtje sturen.

Ik ben ook aan het twijfelen over de geheugensloten. Misschien komen de latjes te hoog (heatspreader).
Ik heb Scythe ook al gemaild, maar de kans dat ik niet wil/kan wachten op dat antwoord is groot

[mad_max234]

craio schreef op maandag 17 december 2007 @ 16:18:
[...]


Ik ben ook aan het twijfelen over de geheugensloten. Misschien komen de latjes te hoog (heatspreader).
Ik heb Scythe ook al gemaild, maar de kans dat ik niet wil/kan wachten op dat antwoord is groot

Ja dan is het inschatten en kopen maar, zou ik zeggen. Als je het online besteld en je hebt er een extra een box cpu koeler bij zitten, dan zou ik het gewoon doen. Past hij niet mag je hem zo terug sturen zonder opgaven van rede, en je heb dan je box koeler als reserve om tijdelijk te gebruiken.

Edit/

Phenom prijsdaling als kerstactie

"Volgens AMD zouden de Phenom 9500, 9600 en 9600 Black Edition beschikbaar moeten zijn voor 'dual core prijzen"

[ Voor 19% gewijzigd door mad_max234 op 17-12-2007 17:50 ]

[Hekking]

BTW m'n Gigabyte FX790DS 5 aan de praat met Vista 64. Wel een beetje gezeur met de subwoofer en Realtek spyware drivers M'n 5600 haalt trouwens makkelijk 3.2 op 1,4 volt dus dat zit wel snor dacht ik. Wat mij betreft een veel meer waar voor me geld ( 170 euro ) dan toen m'n Asus bord met die gare biossen
( 155 euro) Ik weet niet wat jullie adviseren kwa max voltage bij normaal gebruik ?

[Joepi]

Nieuwe bios voor je

F3B
2007/12/13
Fix TLB erratum in L3 cache for AMD Phenom CPU
Improve HT3.0 bus overclocking ability

http://www.gigabyte.com.t...Model.aspx?ProductID=2694

[ Voor 37% gewijzigd door Joepi op 17-12-2007 18:59 ]

[mad_max234]

Joepi schreef op maandag 17 december 2007 @ 18:57:
Nieuwe bios voor je


[...]


http://www.gigabyte.com.t...Model.aspx?ProductID=2694

Je zou bijna niet je bios flashen, zeker als alles werk zou ik hem lekker zonder de TLB bug fix houden. En overklokken doen ze toch al super, dus vraag me af wat ze er nog aan verbeterd hebben?

Bordje haalt al iets van 500Mhz HTbus dacht ik.

[ Voor 5% gewijzigd door mad_max234 op 17-12-2007 19:05 ]

[Anoniem: 215511]

Phenpm BE is reeds te koop:
http://www.techonweb.com/...ductdetail.aspx?id=A00BLV

Vaag alleen dat deze site 4mb L2 cache aangeeft, aanezien dit toch echt 2mb is bij de Phenom 9600. Waarschijnlijk bedoelen ze 2mb L2+ 2mbL3

[craio]

mad_max234 schreef op maandag 17 december 2007 @ 16:28:
[...]


Ja dan is het inschatten en kopen maar, zou ik zeggen. Als je het online besteld en je hebt er een extra een box cpu koeler bij zitten, dan zou ik het gewoon doen. Past hij niet mag je hem zo terug sturen zonder opgaven van rede, en je heb dan je box koeler als reserve om tijdelijk te gebruiken.

De processor is een Black Edition dus geen boxed koeler
Heb intussen wel email ontvangen van Scythe (van een zekere Yongboo Yoo) met de mededeling dat het geen probleem zou mogen zijn. Over de geheugenmodules kon hij(?) wel niets zeggen. Toch heb ik zojuist de bestelling gedaan

[ Voor 4% gewijzigd door craio op 17-12-2007 21:04 ]

[DaCoTa]

Joepi schreef op maandag 17 december 2007 @ 18:57:
Nieuwe bios voor je
[...]
http://www.gigabyte.com.t...Model.aspx?ProductID=2694

Is dit een fix die de L3 cache uitschakeld, of is dit de variant (uitschakelen van bepaalde dirty flag statussen) die ze bij Red Hat gebruiken en die dus geen 5-10%, maar slechts 1% performance hit heeft?

[Anoniem: 244481]

Ik wacht lekker op de prijsdaling en dan zie ik wat ik neem. Intel Of AMD .

[achtbaanfreak]

DaCoTa schreef op maandag 17 december 2007 @ 21:26:
[...]

Is dit een fix die de L3 cache uitschakeld, of is dit de variant (uitschakelen van bepaalde dirty flag statussen) die ze bij Red Hat gebruiken en die dus geen 5-10%, maar slechts 1% performance hit heeft?

De TLB wordt uitgeschakeld waardoor alle requests door de page translation table moeten, wat veel tijd kost.

Hier het hele verhaal

[Anoniem: 204645]

Hekking schreef op maandag 17 december 2007 @ 18:39:
BTW m'n Gigabyte FX790DS 5 aan de praat met Vista 64. Wel een beetje gezeur met de subwoofer en Realtek spyware drivers M'n 5600 haalt trouwens makkelijk 3.2 op 1,4 volt dus dat zit wel snor dacht ik. Wat mij betreft een veel meer waar voor me geld ( 170 euro ) dan toen m'n Asus bord met die gare biossen
( 155 euro) Ik weet niet wat jullie adviseren kwa max voltage bij normaal gebruik ?

Kan je geen review van de ga-ma790fx-ds5 schrijven
Ik zou ooh zo graag reviews van am2+ mbordjes zien van nederlandse/belgische bodem.

achtbaanfreak schreef op maandag 17 december 2007 @ 22:05:
[...]


De TLB wordt uitgeschakeld waardoor alle requests door de page translation table moeten, wat veel tijd kost.

Hier het hele verhaal

De tlb word toch enkel uitgeschakelt bij de phenom he? Of heeft dit ook gevolgen voor de andere processors?

[Joepi]

achtbaanfreak schreef op maandag 17 december 2007 @ 22:05:
[...]


De TLB wordt uitgeschakeld waardoor alle requests door de page translation table moeten, wat veel tijd kost.

Hier het hele verhaal

zo eenvoudig is dat helemaal niet!
Wouter heeft idd de bug goed beschreven, maar niet overwogen, of er ook een micro coode work out zou kunnen: dat wist toen/weet nu AMD misschien zelf nog niet eens.
Het zou buitengewoon interessant zijn met die nieuwe bios de 9500 op hart en nieren te testen/benchen!
Pure nieiwsgierigheid van me, want als de barcelona ook dramatisch betroffen is, dan was er lang werk van bv. datacorruptie gemaakt. Blijkbaar gaat het meer om bsod's zo nu en dan, maar pas - net wouter zegt - onder specifieke omstandigheden.
Inhoeverre de TLB sinpleweg off gezet is of of er via micro code inmiddels iets gefixed is zou mij echt interesseren - helaas heb ik er nu geen mogelijkheden voor - soorry!

[mad_max234]

Joepi kan je even niet goed volgen, maar de bug zit in de Agena en niet in de barcelona dacht ik, al lijken ze op elkaar het zijn verschillende cpu's, barcelona werkt gewoon nog op HT1.0 misschien heeft dat er iets mee te maken. Pas later zal de Barcelona overgaan op HT3.0, komt denk ik ook omdat er nog geen socket F+ mobo zijn, of hij is hardware matig uitgezet.

Edit/

Zat fout hij zit ook in de barcelona.

[ Voor 6% gewijzigd door mad_max234 op 18-12-2007 00:06 ]

[Joepi]

mad_max234
sorry, als het verwarrend is.
We hebben benchmarks en tests nodig!
ervoor - ernaar - klaar!
Zonder blijft het gissen!

[mad_max234]

Joepi schreef op dinsdag 18 december 2007 @ 00:09:
mad_max234
sorry, als het verwarrend is.
We hebben benchmarks en tests nodig!
ervoor - ernaar - klaar!
Zonder blijft het gissen!

Van de TLB patch?

Die zijn er hoor. voor de patch en na de patch, of bedoel je dat niet?

Edit/



http://techreport.com/articles.x/13741/3

[ Voor 30% gewijzigd door mad_max234 op 18-12-2007 00:50 ]

[Joepi]

Juist ja, maar dat is de SW-patch!
Dus niet de fixed bios met nieuwe microo code!
Bovendien MSI en niet gigabyte, die ik als net een beetje beter inschat.
Ik wil graag een nieuwe review zien, waarom berust iedere hw-site in die ad hoc SW-noodrem?

[mad_max234]

Joepi schreef op dinsdag 18 december 2007 @ 00:55:
Juist ja, maar dat is de SW-patch!
Dus niet de fixed bios met nieuwe microo code!
Bovendien MSI en niet gigabyte, die ik als net een beetje beter inschat.
Ik wil graag een nieuwe review zien, waarom berust iedere hw-site in die ad hoc SW-noodrem?

Nu snap ik het.

Er is geen patch met een microcode , de micro code zitten in de cpu (vandaar de B3), en die kan je niet flashen. daarom moet er een workaround gedaan worden via een bios patch voor de bestaande Phenom's. De Phenom B3 heeft de fix microcode en heeft als het goed is minder/geen last van de bug. En volgens mijn kan de bug alleen maar verholpen worden door hardwarematig iets te veranderen, want met de B3 lossen ze het "softwarematig (microcode)" op. (moet hardwarematig veranderd worden in het design, maar noem het maar even "softwarematig")

Edit/

Als ze het niet via de micro code doen, maar een respin dan ben je 1 a 2 maanden verder, dus is de microcode fix de beste snelste oplossing, dan maar iets inleveren.(veel minder dan met de TLB patch) Want anders moet ook het hele productie proces weer opnieuw beginnen. En dacht dat de belichting masks erg duur zijn.

edit2

Now, we wonder did AMD learn a lesson here and will the company put micro-code update function in its future cores such as Bulldozer, Fusion and so on, or will the Texas part of the company still consist out of 9 to 5vers who will go home at 5PM and not fix problems that are causing this company to bleed.

Misschien hoeft het niet meer in de toekomst een hele nieuwe stepping als ze de microcode willen update.

[ Voor 35% gewijzigd door mad_max234 op 18-12-2007 03:27 ]

[Anoniem: 131236]

al tijdje niks meer gepost over mijn ervaringen met het spider platform,
komt eigenlijk hier door.
http://gathering.tweakers.net/forum/list_messages/1264820

[GENETX]

Anoniem: 204645 schreef op maandag 17 december 2007 @ 23:08:
Kan je geen review van de ga-ma790fx-ds5 schrijven
Ik zou ooh zo graag reviews van am2+ mbordjes zien van nederlandse/belgische bodem.

In de vakantie zal ik wss wel even een reviewtje schrijven van mn GA-MA790X-DS4. Overigens doe ik neit aan OC-en, dus dat zal er ook niet in komen.

mad_max234 schreef op dinsdag 18 december 2007 @ 02:18:
Als ze het niet via de micro code doen, maar een respin dan ben je 1 a 2 maanden verder, dus is de microcode fix de beste snelste oplossing, dan maar iets inleveren.(veel minder dan met de TLB patch) Want anders moet ook het hele productie proces weer opnieuw beginnen. En dacht dat de belichting masks erg duur zijn.

Ga er maar gewoon van uit dat hij helemaal gefixt is. Die CPU komt een maand of 3,5 na bekendwording van de bug. Genoeg tijd lijkt me zo. Verder hadden de ES er volgens mij geen problemen mee, dus een fix meot ook niet ver weg zijn lijkt me. Ik gok er gewoon op dat de B3 helemaal geen fix oid nodig heeft, maar dat hij gewoon is zoals hij moet zijn. Verder zullen er misschien nog wel een paar andere foutjes worden verholpen. Ik weet ook niet of deze bug (als ik het zo lees) op te lossen is met microcode zonder deze performance verliezen.

[ Voor 55% gewijzigd door GENETX op 18-12-2007 09:20 ]

[Stephan224]

GENETX schreef op dinsdag 18 december 2007 @ 09:14:
In de vakantie zal ik wss wel even een reviewtje schrijven van mn GA-MA790X-DS4. Overigens doe ik neit aan OC-en, dus dat zal er ook niet in komen.

Mooi, ik zit toevallig een DS4 in mijn upgrade plannings staan dus ben benieuwd naar je bevindingen. Jammer dat je niet aan OCen doet alleen. Keep it posted.

[GENETX]

Stephan224 schreef op dinsdag 18 december 2007 @ 13:12:
[...]


Mooi, ik zit toevallig een DS4 in mijn upgrade plannings staan dus ben benieuwd naar je bevindingen. Jammer dat je niet aan OCen doet alleen. Keep it posted.

Nee, OC-en doe ik wle eens als die te traag wordt, geen zin om risico te lopen als het niet nodig is en zoveel verder zal een 5600+ met stock niet komen . Iig zal ik wel de OC-opties in de BIOS en Overdrive behandelen. Tot nu toe kan ik je zeggen dat ik hel tevreden ben. Loopt lekker vlot en stabiel. Geen problemen tegengekomen dus tot nu toe positief.

[mad_max234]

GENETX schreef op dinsdag 18 december 2007 @ 09:14:
[...]


In de vakantie zal ik wss wel even een reviewtje schrijven van mn GA-MA790X-DS4. Overigens doe ik neit aan OC-en, dus dat zal er ook niet in komen.


[...]


Ga er maar gewoon van uit dat hij helemaal gefixt is. Die CPU komt een maand of 3,5 na bekendwording van de bug. Genoeg tijd lijkt me zo. Verder hadden de ES er volgens mij geen problemen mee, dus een fix meot ook niet ver weg zijn lijkt me. Ik gok er gewoon op dat de B3 helemaal geen fix oid nodig heeft, maar dat hij gewoon is zoals hij moet zijn. Verder zullen er misschien nog wel een paar andere foutjes worden verholpen. Ik weet ook niet of deze bug (als ik het zo lees) op te lossen is met microcode zonder deze performance verliezen.

De B3 is juist de versie met de fix microcode (lees mijn uitleg nog eens goed), die komt dus uit de fabriek met de fix er al in, en dan een beter dan via de TLB patch bios update, dit heb ik ervan begrepen na wat onderzoek te hebben gedaan.

En deze bug word opgelost met de microcode, een respin is te duur, en word niet gedaan lijk me.

[Anoniem: 91868]

http://tweakers.net/productreview/5863
Ik ben lekker eerder

[GENETX]

mad_max234 schreef op dinsdag 18 december 2007 @ 13:26:
[...]


De B3 is juist de versie met de fix microcode (lees mijn uitleg nog eens goed), die komt dus uit de fabriek met de fix er al in, en dan een beter dan via de TLB patch bios update, dit heb ik ervan begrepen na wat onderzoek te hebben gedaan.

En deze bug word opgelost met de microcode, een respin is te duur, en word niet gedaan lijk me.

Het is misschien duur. Ik weet ook neit wat het effect is van die microcode update. iig moet er ook een deel zijn waar de 9500 -> 9550 in performance terug is te vinden. Ik weet het fijne er ook niet van en ook niet of er echt verschil in zit tussen de bug echt fixen of een stukje code die er misschien normaal ook in zit te veranderen. Ik maak geen CPU's . Achja, het gaat er ook om dat hij er komt en dat hij goed werkt en presteerd. Misschien wordt het ook pas echt met Shanghai gefixt (in de zin dat ook een microcode neit nodig zou zijn en de performance nog meer omhoog gaat).

[mad_max234]

Misschien bij de shanghai ook niet, bij de meeste niet kritische bugs word er gewoon omheen gewerkt door middel van een update microcode/bios. En bijvoorbeeld de K7 heeft jaren langen een fix gehad voor een bug die pas bij de K8 verholpen is. (las ik gisteren ergens)

De C2D had/heeft er 110 toen hij op de markt kwam, en meeste zitten er nog gewoon in de C2D maar met een wordaround opgelost. Intel kan wel hun Microcode updaten zonder een nieuwe stepping geloof ik.

En volgens mijn komen de 9650 en zo in januari toch? Na de triple en dual cores. Die triple cores die zullen ook wel lekker goedkoop worden trouwens.

[ Voor 14% gewijzigd door mad_max234 op 18-12-2007 15:35 ]

[GENETX]

Wat ik heb gehoort komen de B3's pas in februari-maart. Deze TLB bug wil ik overigens ook neit bepaald een niet kritische bug noemen. De tijd zal het leren, maar ik weet neit wat voor fix mogelijk is. Het lijkt me ook niet dat ze opeens al het werk in de L3 cache weg willen gooien, zeker omdat volgens mij ook daar voor Shanghai nog veel verbetering voor gepland stond behalve alleen de uitbreiding. Overigens weet ik dus neit wat het effect van een microcode update zal zijn. Of er dan nog functies wordne uitgeschakeld, of dat hij dan voor 99% gewoon zal werken zoals het moet. Wat mij betreft een essentiele bug die AMD het liefst gewoon verhelpt.

[ Voor 16% gewijzigd door GENETX op 18-12-2007 14:56 ]

[mad_max234]

GENETX schreef op dinsdag 18 december 2007 @ 14:36:
Wat ik heb gehoort komen de B3's pas in februari-maart. Deze TLB bug wil ik overigens ook neit bepaald een niet kritische bug noemen. De tijd zal het leren, maar ik weet neit wat voor fix mogelijk is. Het lijkt me ook niet dat ze opeens al het werk in de L3 cache weg willen gooien, zeker omdat volgens mij ook daar voor Shanghai nog veel verbetering voor gepland stond behalve alleen de uitbreiding. Wat mij betreft een essentiele bug die AMD het liefst gewoon verhelpt.

Niet kritische? Voor jou en mijn niet zo maar hij is wel kritische, wat denk je als er een serverpark met weet ik hoeveel opterons en virtuele machines die om de zoveel cyclus een crach veroorzaakt. Of een supercomputer met een TLB bug lekker als je al dagen onderzoek heb lopen en ze beginnen een voor een te crache, en het verkoopt toch niet een cpu die niet 100% stabiel is, doet me aan jaren terug denken.

En de bug word veroorzaakt door een circuit dat niet snel genoeg kan schakelen en dus langzamer is dan de rest, en daarom kan de L3 cache al verder zijn in het proces dan de L2 cache. Komt nog meer bij kijken, maar wouter tinus heeft daar mooi onderzoek na gedaan, en een heel mooi artikel over geschreven, misschien kan hij het nog wat meer uitleggen?

En volgens mijn komen de B3 toch echt eerder dan februari-maart, ga het even uitzoeken. Hoe kom je bij maart en februari? heb je daar aanleiding toe om dat te vermoeden?

[ Voor 48% gewijzigd door mad_max234 op 18-12-2007 15:05 ]

[GENETX]

mad_max234 schreef op dinsdag 18 december 2007 @ 13:48:
Misschien bij de shanghai ook niet, bij de meeste niet kritische bugs word er gewoon omheen gewerkt door middel van een update microcode/bios.

Je zit je dus nu gewoon tegen te lullen . Ook mede omdat je aangeeft dat de schakeling dus idd trager werkt omdat hij neit harder kan. Ik zei dus dat ik het nou niet bepaald een niet kritische bug (wat jij dus daar zegt) is. 2x Niet = Wel (overigens begrijp ik dat je daar overheen zal hebben gelezen met je dyslexie). Maar omdat de schakeling niet goed genoeg is zal deze moeten worden verholpen en dat lijtk em neit 123 gedaan met een microcode update, maar ik kan er ook anast zitten.

Overigens heb ik de B3 overal gezien voor maart en pas laatst ergens voor februari in een artikel. Januari lijkt me dan ook heel snel, maar het zou kunnen dat ze het al hebben ontdekt en al chips produceren waar de voorraad er nu snel uit moet.

Uit het artikel op T.net van Wouter Tinus:

Geruchten over een microcode-update die het probleem ook relatief pijnloos op zou kunnen lossen lijken niet te kloppen. Nieuwe bios-versies waarin de TLB standaard uitgeschakeld wordt hebben inderdaad ook een nieuwe versie van de microcode aan boord, maar dat alleen is niet genoeg om het probleem op te lossen. Via zijn Overdrive-tool wil AMD gebruikers de mogelijkheid geven om de TLB weer in te schakelen, maar dat is net zoals de rest van dat programma voor eigen risico.

De enige echte oplossing is wachten op de B3-stepping, die onder meer gebruikt zal worden voor de 2,4GHz en 2,6GHz Phenoms. Deze nieuwe stepping wordt in februari of maart verwacht. AMD zal dan ook de bestaande 2,2GHz en 2,3GHz Phenoms updaten. De nieuwe versies zullen te herkennen zijn aan een ander modelnummer; zo wordt de huidige Phenom 9500 bijvoorbeeld opgevolgd door de B3-editie 9550.

Lijkt me dus neit dat het een microcode update wordt maar toch echt een re-spin om de bug er uit te halen. Vandaar dat hij wss ook pas eind februari op zijn vroegst komt omdat ze wat tijd nodig hebben.

[ Voor 47% gewijzigd door GENETX op 18-12-2007 15:07 ]

[mad_max234]

Denk toch dat het januari is.

Ik kom namelijk dit soort dingen tegen in de neiuws posten:

It looks as if Phenom 9500, clocked at 2.2GHz, and Phenom 9600 will have an incredibly short life cycle. in early Q1, these two will be replaced with Phenom 9550 and 9650. These two and Phenom 9700 will be based on revision B3 and they will be errata-free.

Maar ook dit

The AMD executive quoted in the interview also addressed the quad-core "Barcelona" Opteron. Samples of design-corrected Opterons will be available in January while volume shipments will take place later in the quarter, according to the CRN report.

Dus we wachten maar even af.

[ Voor 3% gewijzigd door mad_max234 op 18-12-2007 15:08 ]

[GENETX]

Dat hangt idd van de bronnen af en welke nieuwer is. We zien hem iig wel. Overigens staat daar ook: "errata free" wat naar mijn mening inhoudt dat hij gewoon helemaal gefixt wordt, net zoals in eht artikel van Wouter Tinus wordt gesuggereerd.

Waar kotm dat overigens vandaan (link) want kan best zijn dat het neiuwer nieuws is. Dat van mij komt uit oudere artikels en de roadmaps. Kan best zijn dat ze het sneller gefixt hebben dan verwacht.

[mad_max234]

GENETX schreef op dinsdag 18 december 2007 @ 15:08:
Dat hangt idd van de bronnen af en welke nieuwer is. We zien hem iig wel. Overigens staat daar ook: "errata free" wat naar mijn mening inhoudt dat hij gewoon helemaal gefixt wordt, net zoals in eht artikel van Wouter Tinus wordt gesuggereerd.

Fix wilt zeggen dat het werkt, maar hoe het gefix is niet. Maa b3 is nodig om de microcode te updaten dat is zeker, en ze gaan niet even een circuit even in 3 weken herbouwen, want B3 sample worden binnen kort verwacht.

[GENETX]

Uit het artikel van Wouter:

Geruchten over een microcode-update die het probleem ook relatief pijnloos op zou kunnen lossen lijken niet te kloppen.

En wie heeft het over 3 weken? Wss is de bug al ergens in de eerste week van november boven water gekomen. Verder hadden ES ook geen problemen en als ik ook het artikel van Wouter Tinus lees is het bij de final samples niet goed getest. Kosrtom: Of het circuit schaalt niet goed (te lage yields) of er is 1 heel klein foutje wat met een weekje rekenen wel opgelost kan zijn. Persoonlijk gok ik dus op een normale harde fix.

Ik ga dus van Wouter Tinus uit, als jij mij een bron geeft waar wordt eengegeven dat er alleen een simpele microcode update nodig is zonder performanceverlies dan moet je het uiteraard melden. Maar tot zover, afgaande op Wouter Tinus, zal een microcode update niet volstaan.

[mad_max234]

GENETX schreef op dinsdag 18 december 2007 @ 15:16:
Uit het artikel van Wouter:


[...]


En wie heeft het over 3 weken? Wss is de bug al ergens in de eerste week van november boven water gekomen. Verder hadden ES ook geen problemen en als ik ook het artikel van Wouter Tinus lees is het bij de final samples niet goed getest. Kosrtom: Of het circuit schaalt niet goed (te lage yields) of er is 1 heel klein foutje wat met een weekje rekenen wel opgelost kan zijn. Persoonlijk gok ik dus op een normale harde fix.

Hoe kom je bij de eerste week van november? bron? (of gaat de tijd nu zo snel )En dat de ES geen problemen heeft kan komen omdat het een ander cpu stepping was dan die in mass productie ging, de prestatie van de ES was ook iets beter in het algemeen.

En yeilds hebben er niks mee te maken, weet niet hoe je daar bij komt. Alle modellen hebben er last van en heeft niks met of het goede yeilds zijn te maken of het schalen daarvan.

[GENETX]

mad_max234 schreef op dinsdag 18 december 2007 @ 15:29:
[...]


Hoe kom je bij de eerste week van november? bron? (of gaat de tijd nu zo snel )En dat de ES geen problemen heeft kan komen omdat het een ander cpu stepping was dan die in mass productie ging, de prestatie van de ES was ook iets beter in het algemeen.

En yeilds hebben er niks mee te maken, weet niet hoe je daar bij komt. Alle modellen hebben er last van en heeft niks met of het goede yeilds zijn te maken of het schalen daarvan.

nieuws: AMD kampt met fout in 2,4GHz en snellere Phenoms

Dat is dus 19-11. Trek daar dan nog eens 7 dagen vanaf (ok, begin week 2 dus), want AMD heeft dit wel eerder geweten dan dat wij dat doen. Tot en met vandaag hebben ze al een maand gehad dus iig. Verder zijn die ES idd een andere stepping. Maar waarom zou AMD opeens iets nog veranderen in de stepping die uitkomt waarvan dat deel in de ES prima werkte? Het heeft gewerkt dus de oplossing is nabij. Verder werd, zoals in het artikel van Wouter, alles goed getest bij de ES, maar niet bij de final.

Ook geluk speelt een rol: de reden dat AMD deze bug tijdens het testen niet gevonden heeft, is waarschijnlijk omdat de testexemplaren de fout helemaal niet hadden. Een van de moeilijkheden waar het bedrijf tegenaan loopt bij het maken van snellere versies van zijn quadcores is de variatie in het 65nm-procedé. Normaal worden de samples van een chip grondig doorgemeten om de maximale snelheid ervan te bepalen, maar de miljoenen exemplaren die uiteindelijk van de band komen rollen kunnen niet stuk voor stuk zo uitgebreid getest worden.

Hij werkt opzich wel perfect, maar dus niet op die snelheden. Heeft naar mijn weten dus wat met de yields te maken die dus niet hoog genoeg liggen om goede chips te produceren op 65nm.

Op grond van deze 2 quotes van Wouter gok ik dus op een complete fix. Het probleem lijtk mij niet echt heel groot en het zit in een klein hoekje dat helaas onopgemerkt is gebleven.

[ Voor 27% gewijzigd door GENETX op 18-12-2007 15:40 ]

[mad_max234]

GENETX schreef op dinsdag 18 december 2007 @ 15:35:
[...]

Hij werkt opzich wel perfect, maar dus niet op die snelheden. Heeft naar mijn weten dus wat met de yields te maken die dus niet hoog genoeg liggen om goede chips te produceren op 65nm.

Op grond van deze 2 quotes van Wouter gok ik dus op een complete fix. Het probleem lijtk mij niet echt heel groot en het zit in een klein hoekje dat helaas onopgemerkt is gebleven.

Nee elk model heeft er last van ook de laag geklokt opterons, dus heeft niks met de yeild te maken, al heeft een hoger geklokte opteron er wel meer last van. (meer cyclus meer crache kans) Maar elke B2 cpu hij nu op 1GHz loopt of op 3.0Ghz ze hebben allemaal last van dezelfde bug.

En ik hoop dat je gelijk hebt, maar denk niet dat ze het curcuit opnieuw hebben ontworpen.

En 19-11-07 is dus goede 3.5 weken bekent, en wat er intern bekent was. Ja daar kan je naar gissen maar niet mee nemen.

[ Voor 11% gewijzigd door mad_max234 op 18-12-2007 16:07 ]

[GENETX]

mad_max234 schreef op dinsdag 18 december 2007 @ 15:56:
[...]


Nee elk model heeft er last van ook de laag geklokt opterons, dus heeft niks met de yeild te maken, al heeft een hoger geklokte opteron er wel meer last van. (meer cyclus meer crache kans) Maar elke B2 cpu hij nu op 1GHz loopt of op 3.0Ghz ze hebben allemaal last van dezelfde bug.

En ik hoop dat je gelijk hebt, maar denk niet dat ze het curcuit opnieuw hebben ontworpen.

En 19-11-07 is dus goede 3.5 weken bekent, en wat er intern bekent was. Ja daar kan je naar gissen maar niet mee nemen.

Kijk eens op je kalender, het is 18-12 nu... Iets in mijn hoofd zegt dat wanneer de dag om is het exact een maand is geweest. Zoals ik het lees kan die schakeling gewoon niet op die snelheid lopen waardoor de fouten ontstaan. Dat is dus een yield probleem aangezien de ES het niet hadden op wss 90nm proces. Probleem is dat er wss geen goede CPU's uitkomen, hoe dan ook . Maar als ik Wouter's artikel lees zit er geen bug in behalve dan dat de schakeling de snelheid niet aan kan.

[Wouter Tinus]

Voor zover bekend is het probleem fysiek opgelost in de B3-stepping, dus dan zijn er ook geen BIOS- of kerneltrucs meer nodig. AMD heeft gezegd dat deze revisie "mid-to-late Q1" beschikbaar zal zijn, wat dus februari/maart betekent. Dat er dan in januari samples van komen is goed mogelijk dus.

Over microcode: een paar sites (met name The Inquirer) lijken te denken dat AMD helemaal geen microcode-updates kan doen in de K8/K10. Dat is pertinent niet waar: de microcode van de B2-stepping kan dus gewoon gewijzigd worden. Het is alleen niet mogelijk om het probleem op die manier op te lossen .

P.S. AMD heeft pas geleden gezegd dat het probleem binnen een week was opgelost toen ze het eenmaal hadden gevonden, maar dat ze wel een week of 5/6 (als ik me goed herinner) moesten zoeken naar de exacte oorzaak.

[ Voor 21% gewijzigd door Wouter Tinus op 18-12-2007 16:35 ]

[mad_max234]

Wouter Tinus schreef op dinsdag 18 december 2007 @ 16:27:
Voor zover bekend is het probleem fysiek opgelost in de B3-stepping, dus dan zijn er ook geen bios-trucs meer nodig. AMD heeft gezegd dat deze revisie "mid-to-late Q1" beschikbaar zal zijn, wat dus februari/maart betekent. Dat er dan in januari samples van komen is goed mogelijk dus.

Over microcode: een paar sites (met name The Inquirer) lijken te denken dat AMD helemaal geen microcode-updates kan doen in de K8/K10. Dat is pertinent niet waar: de microcode van de B2-stepping kan dus gewoon gewijzigd worden. Het is alleen niet mogelijk om het probleem op die manier op te lossen .

Ok, bedank voor de uitleg, dus onzin wat ze zeggen dat de microcode niet geupdate kunnen worden. Ja dan is het logische dat ze het fysiek hebben opgelost in de b3 anders was de B3 niet nodig, ik was namelijk ervan overtuigt dat de microcode bij de design in de cpu zat. Vroeger was dat toch ook zo als ik het goed herinner maar dat is dus niet meer het geval zins de K8?

[ Voor 24% gewijzigd door mad_max234 op 18-12-2007 16:44 ]

[Wouter Tinus]

mad_max234 schreef op dinsdag 18 december 2007 @ 16:38:
Ok, bedank voor de uitleg, dus onzin wat ze zeggen dat de microcode niet geupdate kunnen worden. Ja dan is het logische dat ze het fysiek hebben opgelost in de b3 anders was de B3 niet nodig, ik was namelijk ervan overtuigt dat de microcode bij de design in de cpu zat. Vroeger was dat toch ook zo als ik het goed herinner maar dat is dus niet meer het geval zins de K8?

Jawel hoor, de microcode zit nog steeds in de CPU meegebakken in een klein ROM-geheugen op de die. Maar het BIOS of het operating systeem kan tijdens het booten een nieuwe versie uploaden .

[mad_max234]

Ik dacht namelijk:

TBL patch = durty bios oplossing
B3 = microcode oplossing door een nieuwe stepping.

Maar heb ook iets gelezen dat de microcode update tijdens de post word geladen (dacht dat intel dat alleen deed) en dan vernieuwde code gebruikt word, dit dan telkens doet tijdens het opstarten. Of word de code in de cpu kompleet overschreven?

edit/
Als het rom is dan kan hij niet upgedate worden, en zal de nieuwe code dus geladen moeten worden tijdens de post of zo. Dus AMD doet dat dus ook op de zelfde manier als intel dat doet?

[ Voor 26% gewijzigd door mad_max234 op 18-12-2007 16:47 ]

[Wouter Tinus]

mad_max234 schreef op dinsdag 18 december 2007 @ 16:44:
edit/
Als het rom is dan kan hij niet upgedate worden, en zal de nieuwe code dus geladen moeten worden tijdens de post of zo.

Klopt, de microcode die wordt meegebakken op de chip zelf kan nooit meer gewijzigd worden, maar tijdens de POST is het iedere keer in een fractie van een seconde vernieuwd tot de volgende reset .

[Joepi]

Bedankt Wouter, maar toch is er een kansje, want AMD zegt voorlopig zeker helemaal niks meer, maar ze hebben de oorzaak en misschien een fixje via micro code - zeker beter dan die ad hoc SW-noodrem
Gigabyte is wel al klaar met een fixed BIOS bij de 790FX bordjes en ik ben echt benieuwd wat het doet bij benchmarks.
Helaas is er geen enkele site op het www tot nu toe erin geslaagd gewooon te tweaken en te benchen oom erachter te komen.
mocht hier bv. een TDer zijn die ff wat kon fixen: graag!

[mad_max234]

Wouter Tinus schreef op dinsdag 18 december 2007 @ 16:49:
[...]

Klopt, de microcode die wordt meegebakken op de chip zelf kan nooit meer gewijzigd worden, maar tijdens de POST is het iedere keer in een fractie van een seconde vernieuwd tot de volgende reset .

Even mij foutje herstellen.

Bedenk me ineens dat rom (niet altijd) wel beschreven kan worden. Rom wil niet zeggen dat het niet beschreven kan worden, mijn fout.

@joepi

wat bedoel je hier mee?

ad hoc SW-noodrem

weet wel wat ad hoc betekent, maar snap in deze content ad hoc SW-noodrem niet helemaal, wat bedoel je daarmee?

En gigabyte is niet klaar, AMD is klaar met de fix, gigabyte doet niks meer dan hem in zijn bios update stoppen.

[ Voor 22% gewijzigd door mad_max234 op 18-12-2007 17:03 ]