Intel Core Duo full av feil

[Boralis]

Da har jeg en liten vits som du kan kose deg med:

AFGHANISTAN - YBN Today it was confirmed that Osama Bin-laden was killed as a Cruise Missile, manufactured by Strongbad Industries asploded near his hideout. The Cruise Missile was equipped with an HP computer guidance system which employed an Intel Itanium processor. The missile missed the target, but Mr. Bin-laden was struck in the head by the processor's heatsink and died later from the injury.

Tenker den satt helt inne ved stolerota

5512740[/snapback]

 

He-he...

Bra "snorreh".. bra..

Intel er da brukandes til noe.. (dersom det hadde vært sant da)..

5512938[/snapback]

 

Årsaken til at den bommet er nå funnet,da det var følgende maskin som var brukt.

http://h10010.www1.hp.com/wwpc/no/no/ho/WF...9-12252780.html

 

[Del]

Årsaken til at den bommet er nå funnet,da det var følgende maskin som var brukt.

http://h10010.www1.hp.com/wwpc/no/no/ho/WF...9-12252780.html

 

5513734[/snapback]

Det er klart, Microsoft er jo ikke tingen for å kjøre beregninger, det vet da vel alle..

Men jeg skjønner ikke helt hvor ATI kommer inn i bildet.

[snorreh]

Her er iallefall en seriøs feil som rammer Intel Core Duo baserte bærbare:

http://www.tgdaily.com/2006/01/28/toms_har...er_drain_issue/

Connect any USB 2.0 device to your notebook and lose more than one hour of battery time: Tom's Hardware Guide's tests of a Windows-based Intel Core Duo mobile processor platform revealed a serious power consumption issue that, according to Intel, is caused by a Microsoft driver bug - a bug that has been known by Microsoft for some time, but kept from the public eye until today.

[...]

But engineers with whom we consulted later in the week indicated that the issue may lie with the chipset of Intel's new dual-core platform, which previously was code-named "Napa." We spoke with representatives of major notebook computer manufacturers, all of whom asked us not to reveal their names, but all of whom said this particular issue has prevented their systems from achieving the goal of four to five hours of battery life which Intel had led them to expect. After a series of extensive tests involving battery benchmarks, Tom's Hardware Guide's Munich Labs engineers were able to observe the precise power consumption problem involving the Core Duo 945 GM chipset.

 

Our assessment and observations, coupled with extensive consultation with engineers familiar with Intel dual-core architecture, plus information we received today from Microsoft, have led us to conclude that an anomaly in the way the currently available version of the ICH7-M Southbridge communicates with Microsoft's ACPI driver, is at the heart of the power drain issue.

[...]

Late this afternoon, representatives from Intel contacted Tom's Hardware Guide's Munich Labs, stating they believed the significantly reduced battery could have occurred because hardware in the Napa platform may be exhibiting problems reaching its deeper sleep states - which are regulated by Microsoft's ACPI driver. Then, at about a quarter-to-five Eastern time, Microsoft apparently lifted a confidentiality agreement on its Knowledge Base article and Intel was able to provide its contents to TG Daily.

 

The issue, according to Microsoft, concerns the asynchronous scheduler component - a part of the USB 2.0 driver that determines when devices can access local memory. With the revision to that driver implemented in Windows XP Service Pack 2, the scheduler can inadvertently be left running. As a result, Windows' internal task scheduler (a separate item) treats the asynchronous scheduler as a running process involving the attached device, and thus stops itself from ever giving the processor the signal to power down, or power lower - to slip into one of its ACPI sleep states. Because the scheduler is running, Windows thinks the system is continually busy. As a result, the computer can use more battery power.

[...]

Late Friday, Microsoft acknowledged to TG Daily - via the hands of Intel - that they believe the problem our engineers observed to have been caused by a misbehaving driver included in Windows XP SP2 - specifically, the Advanced Configuration and Power Interface (ACPI) driver, which is part of the operating system's power management scheme for USB 2.0.

[...]

Late this afternoon, representatives from Intel contacted Tom's Hardware Guide's Munich Labs, stating they believed the significantly reduced battery could have occurred because hardware in the Napa platform may be exhibiting problems reaching its deeper sleep states - which are regulated by Microsoft's ACPI driver. Then, at about a quarter-to-five Eastern time, Microsoft apparently lifted a confidentiality agreement on its Knowledge Base article and Intel was able to provide its contents to TG Daily.

 

The issue, according to Microsoft, concerns the asynchronous scheduler component - a part of the USB 2.0 driver that determines when devices can access local memory. With the revision to that driver implemented in Windows XP Service Pack 2, the scheduler can inadvertently be left running. As a result, Windows' internal task scheduler (a separate item) treats the asynchronous scheduler as a running process involving the attached device, and thus stops itself from ever giving the processor the signal to power down, or power lower - to slip into one of its ACPI sleep states. Because the scheduler is running, Windows thinks the system is continually busy. As a result, the computer can use more battery power.

[...]

In any case, one may wonder why Intel announced and apparently is shipping its platform, while this USB 2.0 issue still exists. According to Myers, Intel believes it has "done a great job job in reducing overall power consumption." The existing problem is "more of a USB problem" than a processor or chipset issue, he said: "It's an issue that we all [vendors] have to try to solve."

 

It's difficult for anyone to say, at this time, whether Intel or Microsoft is more at fault than one another; and in the end, the answer to that question may be insignificant.

[mar]

Det holder å med en "copy/paste" per avsnitt.

 

The issue, according to Microsoft, concerns the asynchronous scheduler component - a part of the USB 2.0 driver that determines when devices can access local memory. With the revision to that driver implemented in Windows XP Service Pack 2, the scheduler can inadvertently be left running. As a result, Windows' internal task scheduler (a separate item) treats the asynchronous scheduler as a running process involving the attached device, and thus stops itself from ever giving the processor the signal to power down, or power lower - to slip into one of its ACPI sleep states.

 

Høres litt ut som en software bug det der.

[Theo343]

Slik jeg leser det er det driveren som holder systemet i gang slik at det bruker mer strøm. Hvordan vil det oppføre seg om man installerer en Linux utgave?

Endret 29. januar 2006 av Theo343

[Anders Jensen]

Som sakt alle 10 var feil. Snorreh, du bidrar vel bare til å bekrefte mine fordommer her...

[Del]

Jeg ville vel heller sagt at ingen av dem var ja/nei spørsmål, Snorre ga en annen vinkling med mye god informasjon. Totalt sett er vi vel da i balanse.

[Anders Jensen]

snorreh har kategorisk feil i 3, 5, 7, 8, 9, og 10.

 

Nå har han kommentert original versjonen av 9, som mildt sagt var klønete formulert fra min side og jeg ser jeg har byttet om på inclusive og exclusive i den, men det er forsåvidt ikke av betydning siden påstanden er feil uavhengig av hvilken en påstår er best. De andre punktene er stort sett bevisst svada fra min side eller tolket feil/kommentert irrelevant av han. (eksemplevis 1, hvor jeg forøvrig dreit meg igjen og bytta om på navnene... må ha vært litt kjapp da jeg rota sammen dette, beklager, men igjen påstanden er feil/svada uavhengig av rekkefølgen også her.)

 

Her er begrunnelsen på hvorfor snorrehs svar på 3, 5, 7, 8, 9, og 10 er feil:

 

3) "Ettersom den totale systembåndbredden i et FSB-system deles mellom minne og I/O, så kan FSB representere en flaskehals når både CPU og I/O prøver å kommunisere med minnet samtidig"

 

Hva menes med "systembåndbredden" her? Minne og I/O deler kun båndbredden til crossbaren i NB, forøvrig sammen med FSB. Denne er typisk non-blocking og har aldri vært noen flaskehals. Flaskehalsen er minnebåndbredden. Den deles av I/O og FSB. Svaret henger forøvrig ikke på greip og jeg misstenker at topologien ikke er forstått.

 

5) Eksemplet som brukes avviker sterkt fra påståtte eksempel og er dermed irrelevant. Se forøvrig min forklaring på dette punktet lengre opp.

 

7) Selv innledningen i linkede dokument avskriver det fra å bevise hva snorreh ønsker å bevise. Det er forøvrig kategorisk feil at det ene er bedre enn det andre uansett. De har forskjellige fordeler, slik nevnt i linket dokument. La meg sittere:

 

"Considering the inconsistent performance improvement, the increased complexity of an exclusive cache hierarchy needs to be justified based upon the specifics of the application and system."

 

8) Katagorisk feil. Det påstås uten dokumentasjon at kort og bred pipeline (f.eks slik som i Power5) er mindre egnet til bruk med SMT enn en lang og smal pipeline (f.eks P4), mens det motsatte er vist i praksis med langt høyere effekt av SMT på Power5 enn på P4.

 

9) Et manglende elementet er f.eks færre OS involverende kontekst-svitsjer på et SMT system. Dette reduserer tid ved å redusere kontekst save/load og OS load (scheduler cpu time).

 

10) Det er ingen systemer som skalerer lineært eller bedre. Punktum. Dette er en definisjon og en matematisk konsekvens av Amdahls lov. Freak effekts slik som lineær eller superlineær skalering kan oppstå mellom noen datapunkter, men dette vil aldri være en trend og disse bryter ikke med Amdahls lov av grunner de som er spesielt interessert kan lese seg til selv. (tar mye tid å forklare, konseptet går på at en egentlig endrer systemet mer enn det kan se ut som). Freak effekts kan oppstå ved den såkalte memmory-effekten der en ved å legge til flere tråder og kjerner i et system også legger til mer cache og får dermed en større del av problemet lagret i cache, noe som kan ha en positiv effekt på noen workloads. Effekten snorreh nevner har ingenting med denne skaleringen å gjøre og er dermed irrelevant. Det snakkes om superlineær frekvensskalering på minnekontrolleren noe som nok skyldes andre effekter enn bare frekvensen. F.eks endringer i CPU frekvens, multiplier eller om dataene er helt forskyvde så kan en jo også tenke seg "feil testing" (feil som i ikke relevant for denne konklusjonen) ved at en har avvik i timings på minnemodulene.

Endret 29. januar 2006 av Anders Jensen

[Del]

Begynner å bli litt sent, så det lyt bli kort.

 

Når det gjelder punkt 3 leste jeg ikke Snorres svar så grundig som deg, jeg tolket det dit at siden FSB og GPU konkurrerer om samme begrensede minnebåndbredde, så kan man ihvertfall indirekte se på dagens implementasjon av FSB i Intel systemer som begrensende for båndbredden mellom GPU og RAM, hvilket jeg synes var en interessant vinkling.

 

For punkt 10 anbefaler jeg deg å lese din egen argumentasjon i punkt 9, der ligger det en liten selvmotsigelse. Forøvrig stusset jeg også på dette med frekvens og minnekontroller her, kanskje Snorre kan utdype denne biten?

 

Punkt 8 må jeg tenke på, dette er jo et interessant punkt, kanskje noen har flere vettuge innspill her?

[Anders Jensen]

Når det gjelder punkt 3 leste jeg ikke Snorres svar så grundig som deg, jeg tolket det dit at siden FSB og GPU konkurrerer om samme begrensede minnebåndbredde, så kan man ihvertfall indirekte se på dagens implementasjon av FSB i Intel systemer som begrensende for båndbredden mellom GPU og RAM, hvilket jeg synes var en interessant vinkling.

5519635[/snapback]

Jeg forstår ikke. Du sier at siden kjøkkendøra er for trang så er det vanskelig å komme seg gjennom døra til stua?

 

For punkt 10 anbefaler jeg deg å lese din egen argumentasjon i punkt 9, der ligger det en liten selvmotsigelse. Forøvrig stusset jeg også på dette med frekvens og minnekontroller her, kanskje Snorre kan utdype denne biten?

5519635[/snapback]

Mulig det bare er for sent på kvelden for meg også, jeg ser ikke en gang hvordan 9 og 10 har noe som helst til felles.

 

Punkt 8 må jeg tenke på, dette er jo et interessant punkt, kanskje noen har flere vettuge innspill her?

5519635[/snapback]

Det kommer mest ann på antall inflight instruksjoner i pipelinen. Generelt kan en si at hvis produktet av lengde og bredde er større for et design så øker også behovet for SMT for å få utnyttet pipelinen. Ref. Alpha EV8 som skulle være 4-way SMT på 8 issue og en eller annen pipeline dybde jeg ikke husker. Ca 8-10 steg tipper jeg. Dette er kjente prinsipper innen datamaskinarkitektur. Ikke noe hokuspokus her. Endret 30. januar 2006 av Anders Jensen

[Del]

Nei, jeg sier at hvis alle som skal til kjøkkenet også må bruke stuedøra, så kan det bli litt trangt i stuedøra.

 

På punkt ni angir du en effekt som ikke har noe med cache å gjøre, men som ofte kan hjelpe deg til super-lineær skalering.

[Anders Jensen]

Nei, jeg sier at hvis alle som skal til kjøkkenet også må bruke stuedøra, så kan det bli litt trangt i stuedøra.

5520819[/snapback]

Er fortsatt ikke med deg. Dette høres helt tullball ut. Akkurat som nedenfor:

På punkt ni angir du en effekt som ikke har noe med cache å gjøre, men som ofte kan hjelpe deg til super-lineær skalering.

5520819[/snapback]

 

"9) SMT bidrar kun til to ting; å gjemme forsinkelse til minnehierarkiet (RAM + cache) samt utnytte ledige ressurser i kjernen der det er mulig."

 

Litt av ei bombe at jeg nevnte noe som hadde med SMT å gjøre og ikke med cache å gjøre... og det kan ikke hjelpe til noen superlineær skalering som helst. Superlineær skalering er egentlig bare en regnefeil fra de som påstår å ha oppnåd den. En tilskriver all ytelsesøkning til en faktor som ikke var alene om å generere økningen.

Endret 30. januar 2006 av Anders Jensen

[blackbrrd]

En kort kommentar angående cache...

 

Større cache senker hastigheten (dvs øker tilgangstiden), men øker treff-raten. Om stor treg cache eller liten kjapp cache egner seg best kommer an på programmene som kjøres på cpu'n. For å motvirke problemet med at cachen blir tregere jo større den blir så er cache gjerne delt opp i nivåer, f.eks L1, L2, L3, etc...

 

Det går ikke an å kategorisk si "større cache gir bedre ytelse" eller "mindre cache gir bedre ytelse", det kommer som sagt an på programmene som kjøres.

[kindings]

Nei, jeg sier at hvis alle som skal til kjøkkenet også må bruke stuedøra, så kan det bli litt trangt i stuedøra.

Burde ikke begi med ut i denne diskusjonen, men hvorfor er det ikke trangt i kjøkkendøren(særlig dersom ikke alle trenger å bruke stuedøren).. Er den bredere? Samme hvor flaskehalsen er, dvs om det er stuedøren eller kjøkkendøren?

[Theo343]

Høres ut som alt for mye dører i dette huset.

[el-asso]

Høres ut som alt for mye dører i dette huset.

Kan ha sine fordeler så lenge de som skal (fra gangen) til kjøkkenet styres gjennom kjøkkendøra og de som skal til stua ledes gjennom stuedøra.

For ikke å snakke om når de som skal fra stua til kjøkkenet slipper å gå gjennom gangen men bruker døra mellom stua og kjøkkenet.

Endret 30. januar 2006 av el-asso

[Anders Jensen]

ok... her er dealen:

 

Når GPU skal hente data fra RAM så går kommunikasjonen slik på et FSB system:

 

GPU -> NB -> RAM -> NB -> GPU

 

Som dere ser er ikke FSB inne i bildet her. Jeg trodde dette var trivielt...

 

Siden FSB ikke er inne i denne forenklede kommunikasjonslenken så kan den heller ikke være en flaskehals slik påstått:

 

"3) FSB er en flaskehals for kommunikasjon fra GPU og I/O til RAM."

 

Siden I/O er koblet til NB eller SB få blir kommunikasjonen slik:

 

I/O -> NB -> RAM -> NB -> I/O

 

eller

 

I/O -> SB -> NB -> RAM -> NB -> SB -> I/O

 

Der "I/O" her vil være DMA kontrolleren til en I/O enhet. En DMA kontroller er egentlig en mikroprosessor det også, så alle systemer med DMA er egentlig multiprosessor systemer. Det er altså ikke noe nytt for den gjengse desktop bruker eller det gjengse desktop OS at en jobber mot en multiprosessor maskin, men det er kanskje ikka alle som er like klar over det.

 

Det er riktig at CPU vil være involvert til tider for å gi kommandoer til DMA kontrollerne, men dette er optimalisert til å være så skjelden som mulig i den hensikt å spare CPU tid. Derfor er også FSB veldig lite involvert i dette kommunikasjonssenariet selv når en utvider det til virkelige eksempler. Dermed er FSB per definisjon ikke en flaskehals for denne typen kommuniksjon. Den kan ha noe invirkning på ytelsen, men dette faller utenfor definisjonen på flaskehals som er det leddet med høyest utnyttelsesgrad. I praksis er nok dette per i dag PCIe svitsjen i tilfelle GPU-> RAM og I/O i seg selv i tilfellet I/O -> RAM. Med forbedringer i PCIe svitsjene vil flaskehalsen bli forflyttet til enten PCIe linken eller minnebussen da det er lite sannsynlig at GPU i seg selv vil gå i metning med det første.

 

QED

Endret 30. januar 2006 av Anders Jensen

[ATWindsor]

Høres ut som alt for mye dører i dette huset.

Kan ha sine fordeler så lenge de som skal (fra gangen) til kjøkkenet styres gjennom kjøkkendøra og de som skal til stua ledes gjennom stuedøra.

For ikke å snakke om når de som skal fra stua til kjøkkenet slipper å gå gjennom gangen men bruker døra mellom stua og kjøkkenet.

5522160[/snapback]

 

Hehe, jeg vet ikke helt om alt dette dørsnakket egentlig er så oppklarende for oss som ikke har så stor kjennskap til en PCs arkiktektur.

 

AtW

[el-asso]

Høres ut som alt for mye dører i dette huset.

Kan ha sine fordeler så lenge de som skal (fra gangen) til kjøkkenet styres gjennom kjøkkendøra og de som skal til stua ledes gjennom stuedøra.

For ikke å snakke om når de som skal fra stua til kjøkkenet slipper å gå gjennom gangen men bruker døra mellom stua og kjøkkenet.

5522160[/snapback]

 

Hehe, jeg vet ikke helt om alt dette dørsnakket egentlig er så oppklarende for oss som ikke har så stor kjennskap til en PCs arkiktektur.

 

AtW

5522428[/snapback]

Var vel en heller dårlig analogi, men tanken var som følger:

Gang = FSB

Kjøkken = GPU

Stue = RAM

[Anders Jensen]

Beklager så meget at jeg dro inn denne dør analogien, den var aldri ment som oppklarende jeg bare tenkte at her er det noen som møter ett eller annet i døra og dermed assosiasjonen...