TLB-bugg i Core 2 och Core i7

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av echo
Fasst som jag skrev, oavsett om fixen behövdes eller ej så drabbades de flesta av den. Bara för att ett fåtal personer kunde gå förbi prestandaförsämringen så försvann ju inte direkt problemet med att den absoluta majoriteten fortfarande led av prestandaförsämringen (för det var ju det som blev problemet, och inte själva buggen i sig - beroende på hur man ser på det). Det är det som är skillnaden.

Men som sagt, om det visar sig att intel kräver en liknande patch så spelar de plötsligt i samma liga. Men att spekulera i att så är fallet nu och i samma mening anklaga swec och andra sidor att intel kommer för lätt undan jämfört med AMD är ju om något obefogat.

Ska som sagt bli intressant att se hur detta utvecklar sig, men tills dess så är det lite för tidigt att dra slutsatser, anser jag.

Eftersom du är den första som har några siffror på prestandaförsämringen (och först att påstå att intels fix ö.h.t. ger någon prestandaförsämring) så antar jag att du har källa på det också.

Att säga att en fix som gör att man går runt en bugg inte ger prestandaförlust är ju bara önsketänkande. Anklagar jag SweC för att Intel "kommer lätt undan"... vet inte vad du baserar det påståendet på, men det är inget jag kommer bry mig om.

Intel säger att buggen är temporär, tillfällig, provisorisk eller vad du nu vill kalla det. Men de som har köpt en Nehalem-prolle kommer buggen alltid vara permanent. Sänkt prestanda för att bandbredden och kommunikationen mellan kärnorna blir lidande - kanske kommer många inte uppleva frysningar eller kraschar ofta. Frågan är hur ofta de kommer, för de försvinner inte sådär utan en fix.

TLB buggen är ingen bugg orsakat av ett litet mjukvaru-fel du kan flasha om genom micro-code uppdateringsfunktionen. Det är en designmiss som enbart går att ändra på ritbordet, inte i koden. Buggen är inte lika omfattande som Phenom och Barcelona hade, men fixen kommer minska prestandan. Nehalem är skeppad med gamla buggar som C2D hade och det är ju inte särskilt respektgivande att inte ha fixat dem ens.

Man behöver inte källa för att förstå att en prestandaförlust finns med fixen, frågan är hur omfattande den blir.

Citat:

Ursprungligen inskrivet av KimTjik
Du kanske missförstod det en aning. I Linux visade det sig direkt att någon AMD fix behövdes inte, eftersom det inte var allvarligare än att det löstes på mjukvaruinvå.

Vad gäller Intels bug får vi väl se. Att Intel säger att deras bugg inte är lika allvarlig väger inte särskilt tungt, om man nu inte blint litar på Intels objektivitet.

Hursom blir det intressant att följa upp den här historien.

Hur som helst så kommer man inte kunna använda Nehalem utan fix i OpenBSD - kommer inte fungera som önskat.

Visa signatur

Knowledge is not achieved until shared.

Permalänk
Medlem

lite OT men när jag testade en dator med core i7 på DH nyss så fick jag bluescreen när jag drog igång 3dmark. Det ger bra förstaintryck

Visa signatur

Core 2 Duo 8400@3.6GHz, Asus Extreme Rampage, 2x DDR3 corsair 4GB, AMD R9 280x 3GB

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Domifuling

Hur menar du att något som är dåligt dokumenterat blir en bugg?

Det är precis så majoriteten av alla buggar på hårdvarufronten fungerar. De stämmer inte med dokumentationen eftersom tillståndet är okänt, det vill säga en bugg. Ibland "bygger man bort" buggen helt enkelt genom att dokumentera den.

Citat:

Ursprungligen inskrivet av ZecretW
Det är ju ingen "bug" det är ett oaccepterat tillstånd som kan provoceras fram om man inte känner till hur den reagerar i speciella händelseförlopp. Precis som alla system krashar vid x/0 så får man skriva regler för att undvika detta. Det är inget konstigt.

Så ett "oaccepterat tillstånd" som kan "provoceras fram om man inte känner till hur den reagerar i speciella händelseförlopp" är inte en bug?

Jösses! Det är urtypen för en bugg. Det är precis så buggar i komplexa system ter sig. Din text är rena rama ordboks-definitionen av en bugg!

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av KimTjik
Du kollar på fel erratum. Hela den långa listan är alla olika buggar. Den det uppenbarligen handlar om är AAJ42. Den kan vid speciella scenarier orsaka "unpredictable behaviour", vilket kan tolkas som allt mellan att applikationen som kör instruktionen kraschar till ren katastrofal krasch.

Lösningen som anges är en BIOS fix. Om den orsakar försämrad prestanda vet jag inte, men det borde väl också snart bli känt.

Aj som fan... Jag va lite snabb... Läste Errata AAJ1 skulle ju ha förstått att Errata AAJ1 inte var ihopkopplad med AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS, Utan det var AAJ42... Klart som korvspad Lustig samman träffande att både AAJ1 och AAJ42 hade med TLB att göra bara.

My bad..

Visa signatur

2x E5-2690 | Supermicro x9dri-ln4f+ | 128GB 10600R Samsung ddr3 | 500GB 850 Evo | Asus R9-290x Matrix | Corsair RM1000i | Corsair Carbide AIR 540 | Intel X5650 | ASUS PT6-Delux OC-Palm | 12GB | 500GB Samsung 850 EVO + 400 GB Intel 910| Asus 7850 | Corsair Carbide 400Q |Supermicro X8DTI-f | 2x Intel Xeon X5650 | 96GB ECC RAM | 2x 250 GB Samsung 850 EVO | UNRAID 6.2.2 | Corsair Graphite 600t

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Voltage
lite OT men när jag testade en dator med core i7 på DH nyss så fick jag bluescreen när jag drog igång 3dmark. Det ger bra förstaintryck

Haha, verkligen

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av Tette
Aj som fan... Jag va lite snabb... Läste Errata AAJ1 skulle ju ha förstått att Errata AAJ1 inte var ihopkopplad med AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS, Utan det var AAJ42... Klart som korvspad Lustig samman träffande att både AAJ1 och AAJ42 hade med TLB att göra bara.

My bad..

OK, jag förstår ironin och tar tillbaka det jag skrev. Du har rätt och jag har fel. Det handlar alltså om den gamla Errata AAJ1 även nu i den här nyheten. Jag kollade runt och ser inget annat än att det hänvisas till just AAJ1. Jag ber om ursäkt.

Eftersom det här handlar om risker vid användning framför allt i servrar undrar jag vad AAJ42 döljer för TLB problem.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Nyarlathotep
Amd gick ut med phenombuggen då den var allvarlig nog för att de skulle riskera gigantiska skadestånd utifall att den upptäcktes. Amd är inte idioter som öser ut milljarder för att vara snälla. Men många vet ju förstås bättre än Amd och säger att den aldrig kunde hända. Det går liksom inte ihop.

Det gör det nog, gissningsvis så har både AMD och Intel rätt rejäla test för sina processorer, säkerligen testar man även saker som är otroligt ovanliga. kanske saker som aldrig kommer och hända. Råkar något dyka upp vid deras test som de missat så är det förmodligen bäst och ta det säkra föret det osäkra och informera om det.

Har själv en phenom med tlb buggen men har aldrig sett den och vad jag vet har ingen annan heller träffat på den, möjligen var det så att många använde den som argument för att förespråka annan processor (de som har intresse av att man inte köper amd) när AMD gav en sådan julklapp.

De flesta som pratat om TLB buggen för phenom tror jag aldrig vet vad det handlat om.

Visa signatur

Programmerare med C++ som huvudspråk.

Permalänk

Kan man inte säga att den stora skillnaden mellan AMDs och Intels TLB buggar är att AMDs bugg framträder ifall man använder processorn hårt och fullt ut men trots allt använder korrekt kod medans intels bugg framträder ifall man gör något man ändå inte borde göra.

Visa signatur

Belysningstekniker låter väl lagom flummigt?
signature your as this use backwards this read to enough dumb were you if

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av mortifer666
Kan man inte säga att den stora skillnaden mellan AMDs och Intels TLB buggar är att AMDs bugg framträder ifall man använder processorn hårt och fullt ut men trots allt använder korrekt kod medans intels bugg framträder ifall man gör något man ändå inte borde göra.

Nej inte riktigt. För AMDs bugg kommer inte så lätt, som sagt inte utanför AMDs laboratorier hittills. Sedan är jag inte tillräckligt insatt i Intels bugg. Det är ju lätt att bara formulera sig så att koden som framkallar buggen inte borde köras, och därmed är felaktig. De har ju lite makten att diktera vad som är rätt kod eller inte rätt kod.
AMDs bugg kan man ju undvika genom att göra koden på ett visst sätt också. Lite det linux-fixen bygger på.

Permalänk
Medlem

http://www.anandtech.com/showdoc.aspx?i=3260&p=2

Citat:

AMD gave us two confirmed situations where the TLB erratum would rear its ugly head in real world usage:

1) Windows Vista 64-bit running SPEC CPU 2006
2) Xen Hypervisor running Windows XP and an unknown configuration of applications

AMD insisted that the TLB erratum was a highly random event that would not occur during normal desktop usage and we've never encountered it during our testing of Phenom. Regardless, the two scenarios listed above aren't that rare and there could be more that trigger the problem, which makes a great case for fixing the problem

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Jones377
http://www.anandtech.com/showdoc.aspx?i=3260&p=2

Där ser man, förvisso inget att bry sig om. Men konstigt att jag missat det.

Permalänk
Avstängd
Visa signatur

Programmerare med C++ som huvudspråk.

Permalänk
Medlem

skildnaden mellan amd och intels bugg, är att amds bug var i en mer central del av området i frågan. medan intels bug inte var så central.

det är nämligen så att folk som kör stora server farmar som uptime är otroligt viktigt så vill man inte ha en bugg.

då har amd och intel fixat en fix. men vad som skiljer dom är att intels fix gick att fixa utan någon större förlust, medan amd behövde släcka ner en cach för att fixa det. deta inebär en större prestanda förlust.

för att dom som kör dessa servrar vill att buggen ska vara fixad, så patchar dom den men mjukvaran,
men i amds fall så vart det en prestandad förlust på 10-20 %, medan intel kanske 1 % förlust,
deta inebär oxå att amd inte längre blir lika konkurans kraftig efter som användarna inom server bransen i stort sätt måste patcha felet.

deta är varför amds tlb bugg är alvarligare än intels,
plus att deta gör att intels bugg inte är lika högt prioriteerat, och där med har funnits kvar från core til i7

så i intels fall, en lilten bugg fix, plus att mjukvaran måste va bra skriven, deta är genomförbart utan större problem,

i amds fall, en bugg fix, en prestanda förlust på 10-20 %.

i intels fall så är det inget större problem, medans amds fall är inte processorn lika konkurans kraftig längre. med hänsyn för pris/prestanda.

Permalänk
Citat:

Ursprungligen inskrivet av -Boris-
Nej inte riktigt. För AMDs bugg kommer inte så lätt, som sagt inte utanför AMDs laboratorier hittills. Sedan är jag inte tillräckligt insatt i Intels bugg. Det är ju lätt att bara formulera sig så att koden som framkallar buggen inte borde köras, och därmed är felaktig. De har ju lite makten att diktera vad som är rätt kod eller inte rätt kod.
AMDs bugg kan man ju undvika genom att göra koden på ett visst sätt också. Lite det linux-fixen bygger på.

Vad jag förstått av Intels bugg så verkar det vara som när man bränner större skivor i nero. Det finns en spärr som hindrar en person från att bränna en 700mb iso på en 650mb skiva denna spärr har man lagt in för att inte folk ska upptäcka på fel sätt att det inte går.
I intels fall har ingen tänkt på att någon skulle vilja göra just det som den här buggen gör. Att om man tar bort eller annulerar datan i cachen på ett felaktigt sätt. Så kan cpun ge felaktiga svar eller hänga sig. När man upptäckte att något sånt här kan hända så åtgärdade man det genom att inte tillåta felaktiga borttagningar.

Amds fel inträffar vid hög användning av cpun vilket jag anser är allvarligare.
Rätt kod vid fel tillfälle kan få en AMD utan fixen att krascha.
Felaktig kod vid rätt tillfälle kan få en intel utan fixen att krascha.

Vilket är allvarligast?

Visa signatur

Belysningstekniker låter väl lagom flummigt?
signature your as this use backwards this read to enough dumb were you if

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av invztr
Att säga att en fix som gör att man går runt en bugg inte ger prestandaförlust är ju bara önsketänkande.

Möjligt, men det är enorm skillnad på prestandaförlust och prestandaförlust. I AMDs fall var det något som var ett riktigt problem. Men det behöver inte vara något reellt problem ö.h.t.

Dina siffror är du fortfarande helt ensam om och du visar inga källor för dem heller.

Och som sagts... Linux hade en fix för AMDs bugg som inte orsakade *någon* (allt är relativt) prestandaförlust.

Citat:

Ursprungligen inskrivet av invztr
Anklagar jag SweC för att Intel "kommer lätt undan"... vet inte vad du baserar det påståendet på, men det är inget jag kommer bry mig om.

Det har jag inte sagt...
Det som var riktat mot dig var det som jag skrev efter att jag citerade dig...

...

Citat:

Ursprungligen inskrivet av invztr
Intel säger att buggen är temporär, tillfällig, provisorisk eller vad du nu vill kalla det. Men de som har köpt en Nehalem-prolle kommer buggen alltid vara permanent. Sänkt prestanda för att bandbredden och kommunikationen mellan kärnorna blir lidande - kanske kommer många inte uppleva frysningar eller kraschar ofta. Frågan är hur ofta de kommer, för de försvinner inte sådär utan en fix.

Från nyheten:
"Core i7 har ett problem som gör att processorn kan krascha om TLB:n används felaktigt av operativsystemet."

Vilket i praktiken mycket väl kan innebära önsketänkandet ovan. Ingen prestandaförlust alls. Har du annnan information får du gärna dela med dig av varifrån du fått den.

Citat:

Ursprungligen inskrivet av invztr
TLB buggen är ingen bugg orsakat av ett litet mjukvaru-fel du kan flasha om genom micro-code uppdateringsfunktionen. Det är en designmiss som enbart går att ändra på ritbordet, inte i koden. Buggen är inte lika omfattande som Phenom och Barcelona hade, men fixen kommer minska prestandan. Nehalem är skeppad med gamla buggar som C2D hade och det är ju inte särskilt respektgivande att inte ha fixat dem ens.

Man behöver inte källa för att förstå att en prestandaförlust finns med fixen, frågan är hur omfattande den blir.

Vem har påstått att det går att fixa i efterhand?

Frågan är om det ens finns något egentligt behov (för kunderna) av att fixa buggen, mer än att visa dess existens.

Du behöver verkligen en källa för dina påståenden om du ska verka det minsta trovärdig. AMDs bugg som av allt att döma var betydligt allvarligare gick att lösa utan några egentliga prestandaförluster. Men du får gärna visa vaför denna bugg inte kommer att kunna lösas utan stora prestandaförluster.

Permalänk
Medlem

Men herre gud vad folk sitter och letar...

Kolla specifikationerna för Core 2 Quad så kommer ni se flera "error" och "problem". Man kan till och med hitta lite problem med TLB där också... Så alla c2d är defekta... ska vi ta och skriva detta på förstasidor över hela nätet?

Alla cpuer har fel/problem/errors. Det viktiga är hur stora de är, hur man kan gå runt dem och hur detta påverkar användaren...

Alla som kommenterar LÄS dokumentet så får ni lite kött på benen...