mboost-dp1
unknown
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Det lyder sku' da mega fedt. Så kan man da godt nok få de gamle servere til at sparke røv igen. :)
Det er dejligt at se at AMD rent faktisk ligger lidt foran Intel lige nu.
Det er dejligt at se at AMD rent faktisk ligger lidt foran Intel lige nu.
jamen vil den så i grove træk være det som Intels HT teknologi går ud på?
altså 1 fysisk CPU men 2 virtuelle? udover at her er der 2 kerner, men på 1 CPU's plads.. ??
giver mit ævl mening ?? :D :D
altså 1 fysisk CPU men 2 virtuelle? udover at her er der 2 kerner, men på 1 CPU's plads.. ??
giver mit ævl mening ?? :D :D
#4
I meget grove træk, så jo, men da der her er tale om to fysiske kerner, så er det som at få to ægte cpu'er, og ikke som den virtuelle Intels har med deres HT teknik.
I meget grove træk, så jo, men da der her er tale om to fysiske kerner, så er det som at få to ægte cpu'er, og ikke som den virtuelle Intels har med deres HT teknik.
#4
Nej, overhovedet ikke - og så er det også forkert :P
Intels HT teknologi går ud på at emulere 2 CPU'er - så styresystemet -> programmet -> programmørerne tror at der flere CPU'er.
Herved kan man bedre udnytte CPU'ens lange pipeline. Det kan give ydelsesforbedring på 10-20% ved multicpu programmering.
Ved at sætte en ekstra kerne i CPU'en får man en ydelsesforbedring på 100%.
Så hvis Intel vil lave det samme trick - får du 4 pingviner i opstart med linux med kun en CPU...
Grunden til at AMD ikke bruger HT, er at deres pipeline ikke er astronomisk lang som Intels.
Nej, overhovedet ikke - og så er det også forkert :P
Intels HT teknologi går ud på at emulere 2 CPU'er - så styresystemet -> programmet -> programmørerne tror at der flere CPU'er.
Herved kan man bedre udnytte CPU'ens lange pipeline. Det kan give ydelsesforbedring på 10-20% ved multicpu programmering.
Ved at sætte en ekstra kerne i CPU'en får man en ydelsesforbedring på 100%.
Så hvis Intel vil lave det samme trick - får du 4 pingviner i opstart med linux med kun en CPU...
Grunden til at AMD ikke bruger HT, er at deres pipeline ikke er astronomisk lang som Intels.
To Cpu-kerne vil være væsentligt mere effektivt end hyperthreading.
Hyper-threading er smart nok, men er minder mere om en slags "software" løsning. Cpu'en er ikke hurtigere, den er bare bedre til at håndtere flere tråde.
Jeg har selv en dual cpu (Athlon XP->MP) derhjemme og en HT P4 på arbejde. På trods af at P4'eren er på 2,6 Ghz og Athlon'erne derhjemme er på sølle 1,5 Mhz, så er maskinen alligevel mere responsiv.
Almindelige brugere kan nok ikke mærke forskel, men jeg laver ofte fler eting samtidigt og der kan man godt mærke forskel.
Der er desværre meget benchamrk der tager ordentligt højde for dual cpu'er / HT så det er svært at bevise
Hyper-threading er smart nok, men er minder mere om en slags "software" løsning. Cpu'en er ikke hurtigere, den er bare bedre til at håndtere flere tråde.
Jeg har selv en dual cpu (Athlon XP->MP) derhjemme og en HT P4 på arbejde. På trods af at P4'eren er på 2,6 Ghz og Athlon'erne derhjemme er på sølle 1,5 Mhz, så er maskinen alligevel mere responsiv.
Almindelige brugere kan nok ikke mærke forskel, men jeg laver ofte fler eting samtidigt og der kan man godt mærke forskel.
Der er desværre meget benchamrk der tager ordentligt højde for dual cpu'er / HT så det er svært at bevise
Det lyder til gengæld også dyrt at installere f.eks. MSSQL eller andre processor licensierede programmer på sådan en fætter.
Tror i de ændre i licenserne som de gjorde da HT kom frem, så man må havde en single processor licens kørende på en af disse nye processore?
Tror i de ændre i licenserne som de gjorde da HT kom frem, så man må havde en single processor licens kørende på en af disse nye processore?
Hvorfor er det en stor nyhed når AMD laver en dualcore CPU, da SUN lavede en for et godt stykke tid siden, var der ikke meget oppe omkring det. Det er jo det samme teknik (i grove træk) der bliver brugt.
#16
Arrg...
Du kan jeg ikke rette det mere.. :(
Hehe
AMD var et lille firma, der så vidt jeg ved, måtte spørge pænt om lov i tidernes morgen.
Der er snart ikke meget 'lillebror over dem'.. ;)
Fra et lille firma er lavede kopiprodukter, til nu rent faktisk at lave deres egne Intel-killers.
Arrg...
Du kan jeg ikke rette det mere.. :(
Hehe
AMD var et lille firma, der så vidt jeg ved, måtte spørge pænt om lov i tidernes morgen.
Der er snart ikke meget 'lillebror over dem'.. ;)
Fra et lille firma er lavede kopiprodukter, til nu rent faktisk at lave deres egne Intel-killers.
19#: [Intel|AMD]Fan , ordet er jeg modstander af. Det er stort set kun fjolser som helliger et mærke frem for et andet, så hvis du siger om en person at han er intelfan ser jeg med det samme at der står "En gut som ikke rigtig ved en skid og tror at intel er bedst fordi han har læst det nyeste alt om data".
Argumenter som 'AMD er mere/mindre stabilere/hurtigere/varmere/koldere end Intel' bunder for det meste ikke i en skid, om du bruger intel eller amd i din server er for det meste ligegyldigt.
Hvis jeg skulle samle et kraftmonster af en server i 32 bit som f.eks. skulle køre database ville jeg finde mig et godt quad-bundkort til P4 og udstykke den med en stak prescott cpu'er på 3-4 ghz, så meget ram som der overhovedet kunne være i den(som regel 4-8gb) , en stak scsi 15krpm diske i raid. Og det system ville yde fint og kunne trække den grummeste database jeg kan forestille(okay...måske ikke lige googles men ellers :P)
Om jeg skulle bruge AMD Barton 4 ghz processorer istedet ville kun give en lidt ringere ydelse(taget ud fra ydelses sammenligninger på dagens AMD processorer) , men giver jeg mig så til at renge pris/ydelse vinder AMD pludselig, for bruger jeg de samme penge på AMD udstyr står jeg pludselig med en meget kraftigere maskine.
Skulle jeg samle mig en 64 bit(ville jeg nok helst ringe og bestille en hos sun, men udover det) ville jeg uden tvivl bruge opteron primært fordi de kom først og alt der er ude i x86-64 er optimeret til opteron. Men om et par år vil jeg ikke afvise at jeg måske køber en Intel for så er forskellen måske rykket derover.
Get my point? Hvis du udstiller dig som "intel fan" smider du 50%(cirka) af mulighederne væk i og med du udelukker markedest næst største spiller.
Jeg sider og skriver det her fra en IBM T41P med en Intel Centrino processor i, inde i værelset ved siden af står der en 1.3ghz AMD maskine med 400gb harddisk i og leger filserver. Og jeg er ved at samle en amd64 maskine , i en server park "et sted i dk" har jeg en sun ultra sparc64 maskine stående, og jeg har en enkelt maskine stående "et andet sted" som er en p4 på et par gigahertz, de løser hver sin opgave og jeg har spredt mine investeringer på flere forskellige spillere og samtidig har jeg nu viden om sparc64 architechturen, intel's x86 og amd's x86 hvor jeg ellers kun ville have om en af dem hvis jeg nu havde "valgt religion".
Please get my point and stop the religionwars.
Argumenter som 'AMD er mere/mindre stabilere/hurtigere/varmere/koldere end Intel' bunder for det meste ikke i en skid, om du bruger intel eller amd i din server er for det meste ligegyldigt.
Hvis jeg skulle samle et kraftmonster af en server i 32 bit som f.eks. skulle køre database ville jeg finde mig et godt quad-bundkort til P4 og udstykke den med en stak prescott cpu'er på 3-4 ghz, så meget ram som der overhovedet kunne være i den(som regel 4-8gb) , en stak scsi 15krpm diske i raid. Og det system ville yde fint og kunne trække den grummeste database jeg kan forestille(okay...måske ikke lige googles men ellers :P)
Om jeg skulle bruge AMD Barton 4 ghz processorer istedet ville kun give en lidt ringere ydelse(taget ud fra ydelses sammenligninger på dagens AMD processorer) , men giver jeg mig så til at renge pris/ydelse vinder AMD pludselig, for bruger jeg de samme penge på AMD udstyr står jeg pludselig med en meget kraftigere maskine.
Skulle jeg samle mig en 64 bit(ville jeg nok helst ringe og bestille en hos sun, men udover det) ville jeg uden tvivl bruge opteron primært fordi de kom først og alt der er ude i x86-64 er optimeret til opteron. Men om et par år vil jeg ikke afvise at jeg måske køber en Intel for så er forskellen måske rykket derover.
Get my point? Hvis du udstiller dig som "intel fan" smider du 50%(cirka) af mulighederne væk i og med du udelukker markedest næst største spiller.
Jeg sider og skriver det her fra en IBM T41P med en Intel Centrino processor i, inde i værelset ved siden af står der en 1.3ghz AMD maskine med 400gb harddisk i og leger filserver. Og jeg er ved at samle en amd64 maskine , i en server park "et sted i dk" har jeg en sun ultra sparc64 maskine stående, og jeg har en enkelt maskine stående "et andet sted" som er en p4 på et par gigahertz, de løser hver sin opgave og jeg har spredt mine investeringer på flere forskellige spillere og samtidig har jeg nu viden om sparc64 architechturen, intel's x86 og amd's x86 hvor jeg ellers kun ville have om en af dem hvis jeg nu havde "valgt religion".
Please get my point and stop the religionwars.
#21 Du lyder heller ikke selv som om du ved hvad du snakker om.. du siger at du vil bygge en 4-vejs server med Presscott CPU'er? Good luck.. måske du får bedre held med et par Xeon CPU'er.. Og ud over det så ville det være åndsvagt at købe en 4-vejs Xeon da 4 CPU'er så vil deles om meget lidt båndbredde til RAMen, hvorimod Opteron CPU'erne har deres egen dedikerede hukommelse og et meget hurtigt link imellem hinanden..
Hvis du derimod vil have en 2-vejs server så synes JEG du skal gå efter et Xeon setup da 2 CPU'er ikke vil kæmpe så meget om båndbredden..
Hvis du derimod vil have en 2-vejs server så synes JEG du skal gå efter et Xeon setup da 2 CPU'er ikke vil kæmpe så meget om båndbredden..
#24: Meget muligt, min eneste quad server er pt en sparc64 så jeg har logisk nok ikke undersøgt forskellen mellem diverse quad og dual systemer til bunds endnu, jeg har dog undersøgt Xeon vs. Pentium 4 , ydelse ifht. pris. Og jeg kan ikke se nogen situationer hvor det for mig kan betale sig at købe xeon processorer, i alle tilfælde ville jeg kunne opnår et billigere og bedre setup med at lave noget redundant P4 (eller sågar amd xp) setup.
Men jeg vil da tage dit råd til eftermæle hvis jeg får brug for en x86 quad maskine på et eller andet tidspunkt. Selvom jeg er mere og mere tilhænger af google metoden med mange billige maskiner istedet for en stor.
Men jeg vil da tage dit råd til eftermæle hvis jeg får brug for en x86 quad maskine på et eller andet tidspunkt. Selvom jeg er mere og mere tilhænger af google metoden med mange billige maskiner istedet for en stor.
#25:
Google metoden som du kalder den, går jo ud på at de billige maskiner kan tåle at gå ned, uden at det berører systemet som helhed. Det samme gør sig nok næppe gældende hvis du vil køre en databaseserver, du kan ikke rigtigt sætte to maskiner op til at arbejde sammen om en database så de både giver superydelse og samtidigt sikrer optiden hvis den ene skulle gå ned. Skal du bruge dine maskiner til noget HPC er det selvfølgelig anderledes, men her mener jeg nu helt sikkert at AMDs cpu'er er Intels overlegne.
Angående det med at bruge Pentium 4 i en quad setup har jeg ikke hørt nogen gøre det, men hvis det er muligt er der da ingen tvivl om at en FSB800 ville gøre underværker. Intel er først inden for det sidste halve år begyndt at sælge Xeon med en 533MHz FSB, men de kan kun bruges som dual-cpu (er i hvert fald kun certificeret til det) vil du have en Xeon MP (der også kan bruges i 4 eller 8-vejs konfigurationer) er du stadigt begrænset af en 400MHz FSB. De koster også 36.000 stykket for en 2.8GHz model og det er jo til at grine en hel del af ;O)
8GB ram i 32-bit systemer koster vist også rimeligt hårdt i dit ydelsen af dit OS.
Anyway vil jeg da lige give et par links til et par artikler der er værd at læse.
Aceshardwares artikkel
Anandtechs artikkel
Hovedkonklusionen er kort sagt at i dual-opsætninger vinder AMD for det meste med et beskedent forspring, men i quad-opsætninger er de urørlig.
Jeg anbefaler normalt at man køber AMD systemer, men det er pga. deres meget gode ydelse og ydelse for pengene på de områder hvor de skal bruges. Men jeg forsøger altid at vælge det bedste værktøj til en opgave, og derfor ejer jeg da heller ikke kun AMD maksiner, men også en VIA V10000 C3-Nehemia pga. det lave energiforbrug og dermed også lave varmeudvikling. Og i den kommende uge skulle jeg også meget gerne blive ejer af en bærbar med Intels Pentium M, den er i hvert fald bestilt :D
Google metoden som du kalder den, går jo ud på at de billige maskiner kan tåle at gå ned, uden at det berører systemet som helhed. Det samme gør sig nok næppe gældende hvis du vil køre en databaseserver, du kan ikke rigtigt sætte to maskiner op til at arbejde sammen om en database så de både giver superydelse og samtidigt sikrer optiden hvis den ene skulle gå ned. Skal du bruge dine maskiner til noget HPC er det selvfølgelig anderledes, men her mener jeg nu helt sikkert at AMDs cpu'er er Intels overlegne.
Angående det med at bruge Pentium 4 i en quad setup har jeg ikke hørt nogen gøre det, men hvis det er muligt er der da ingen tvivl om at en FSB800 ville gøre underværker. Intel er først inden for det sidste halve år begyndt at sælge Xeon med en 533MHz FSB, men de kan kun bruges som dual-cpu (er i hvert fald kun certificeret til det) vil du have en Xeon MP (der også kan bruges i 4 eller 8-vejs konfigurationer) er du stadigt begrænset af en 400MHz FSB. De koster også 36.000 stykket for en 2.8GHz model og det er jo til at grine en hel del af ;O)
8GB ram i 32-bit systemer koster vist også rimeligt hårdt i dit ydelsen af dit OS.
Anyway vil jeg da lige give et par links til et par artikler der er værd at læse.
Aceshardwares artikkel
Anandtechs artikkel
Hovedkonklusionen er kort sagt at i dual-opsætninger vinder AMD for det meste med et beskedent forspring, men i quad-opsætninger er de urørlig.
Jeg anbefaler normalt at man køber AMD systemer, men det er pga. deres meget gode ydelse og ydelse for pengene på de områder hvor de skal bruges. Men jeg forsøger altid at vælge det bedste værktøj til en opgave, og derfor ejer jeg da heller ikke kun AMD maksiner, men også en VIA V10000 C3-Nehemia pga. det lave energiforbrug og dermed også lave varmeudvikling. Og i den kommende uge skulle jeg også meget gerne blive ejer af en bærbar med Intels Pentium M, den er i hvert fald bestilt :D
#26: Jeg er helt enig med din xeon konklution, og jo jeg ville godt påtage mig at kode en webportal som kørte 100% redundant op imod f.eks. 4 database servere lavet af bambus hardware, og tilsvarende 2 web og mail servere.
Distributed computer vinder så meget frem at det for det meste vil være et spm. om at være kreativ nok.
Jeg er langt hen af vejen unix-hackeren som står og kompencere på software siden for det der ikke lige blev råd til i hardware ;) Så det undrer mig ikke det fjerneste at nogen her ved mere om hardware end mig.
Og så tillykke med din centrino maskine, lad mig benytte lejligheden til at give dig et link til hvordan jeg fik gentoo til at benytte wlan kortet i min ;) http://base.fujang.dk/cgi-bin/index.pl?action=show... might be usefull :)
Distributed computer vinder så meget frem at det for det meste vil være et spm. om at være kreativ nok.
Jeg er langt hen af vejen unix-hackeren som står og kompencere på software siden for det der ikke lige blev råd til i hardware ;) Så det undrer mig ikke det fjerneste at nogen her ved mere om hardware end mig.
Og så tillykke med din centrino maskine, lad mig benytte lejligheden til at give dig et link til hvordan jeg fik gentoo til at benytte wlan kortet i min ;) http://base.fujang.dk/cgi-bin/index.pl?action=show... might be usefull :)
Husk altid på at programmer mm. skal understøtte HT for at det giver nogen effekt. Faktisk kan man øge performance ved at slå HT fra, hvis der alligevel ikke er nogen af de programmer man bruger der rent faktisk understøtter det.
#28 Husk altid på at programmer mm. skal understøtte HT
Nej, dine programmer behøver ikke understøttet det. Det er kun kernen, der har betydning. Men HT kan være lidt tricky, og en kerne, der giver god performance på et SMP system kan godt give elendig performance på et HT system. Men med en enkelt CPU med HT, burde det sjældent gå helt galt. Men hvis du f.eks. har en distributed.net klient kørende, og kernen beslutter sig for at lade den køre på den ene virtuelle CPU, som ikke har andet at lave, så bliver den virtuelle CPU, som faktisk har noget fornuftigt at lave, langsommere. Samlet set bliver performance sandsynligvis bedre, det skulle ikke undre mig om din distributed.net klient får udført flere beregninger end den ellers ville have gjort. Men det er ikke mere kernen, der afgører hvor resourcerne bliver brugt. En kerne med HT support ville sørge for, at processen med den højeste prioritet får noget tid, hvor den er alene på CPU'en, og den anden virtuelle CPU er idle.
Hvis du har to HT CPU'er og dermed fire virtuelle CPU'er kan det gå helt galt. Hvis du f.eks. har to programmer, der har brug for CPU-tid, kunne kernen sende dem ind på hver sin virtuelle CPU i den samme fysiske CPU, mens den anden fysiske CPU intet har at lave. Og så ville det være bedre at kun bruge to fysiske CPU'er uden HT.
Der er flere detaljer som kan give mindre forbedringer på et HT system. Men i første omgang er det vigtigste, at kerne designerne tænker sig lidt om, så HT aldrig forringer performance. Og med det nuværende HT design betyder det faktisk, at man nogen gange skal lade en virtuel CPU være idle selvom man har processer i run-køen.
En af de små detaljer man bør huske på, når man skriver en kernel til et multi HT system er, at der er en omkostning ved at flytte en process til en anden fysisk CPU, så man bør så vidt muligt forsøge at holde den på samme fysiske CPU. Til gengæld er der ikke nogen omkostning ved at flytte en process til en anden virtuel CPU i samme fysiske CPU. Men denne detalje gør sandsynligvis en mindre forskel i sammenligning med den performance forbedring du får fra et HT system.
Nej, dine programmer behøver ikke understøttet det. Det er kun kernen, der har betydning. Men HT kan være lidt tricky, og en kerne, der giver god performance på et SMP system kan godt give elendig performance på et HT system. Men med en enkelt CPU med HT, burde det sjældent gå helt galt. Men hvis du f.eks. har en distributed.net klient kørende, og kernen beslutter sig for at lade den køre på den ene virtuelle CPU, som ikke har andet at lave, så bliver den virtuelle CPU, som faktisk har noget fornuftigt at lave, langsommere. Samlet set bliver performance sandsynligvis bedre, det skulle ikke undre mig om din distributed.net klient får udført flere beregninger end den ellers ville have gjort. Men det er ikke mere kernen, der afgører hvor resourcerne bliver brugt. En kerne med HT support ville sørge for, at processen med den højeste prioritet får noget tid, hvor den er alene på CPU'en, og den anden virtuelle CPU er idle.
Hvis du har to HT CPU'er og dermed fire virtuelle CPU'er kan det gå helt galt. Hvis du f.eks. har to programmer, der har brug for CPU-tid, kunne kernen sende dem ind på hver sin virtuelle CPU i den samme fysiske CPU, mens den anden fysiske CPU intet har at lave. Og så ville det være bedre at kun bruge to fysiske CPU'er uden HT.
Der er flere detaljer som kan give mindre forbedringer på et HT system. Men i første omgang er det vigtigste, at kerne designerne tænker sig lidt om, så HT aldrig forringer performance. Og med det nuværende HT design betyder det faktisk, at man nogen gange skal lade en virtuel CPU være idle selvom man har processer i run-køen.
En af de små detaljer man bør huske på, når man skriver en kernel til et multi HT system er, at der er en omkostning ved at flytte en process til en anden fysisk CPU, så man bør så vidt muligt forsøge at holde den på samme fysiske CPU. Til gengæld er der ikke nogen omkostning ved at flytte en process til en anden virtuel CPU i samme fysiske CPU. Men denne detalje gør sandsynligvis en mindre forskel i sammenligning med den performance forbedring du får fra et HT system.
Det er lidt en ensidet nyhed denne her. Folk bruger megen krudt på at rose AMD, men faktum er, at det i første omgang kun bliver Opterons der kommer med dual core. - Til sammenligning er Intel ved at udvikle dual core løsninger til lap- og desktop markedet. Dvs., vi kommer til at se dual-core CPU'er i bl.a. bærbare computere.
De har iøvrigt lige fremrykket lancerings tidspunktet, formodentlig pga. AMD's udmelding
Kilde: http://www.xbitlabs.com/news/cpu/display/200404270...
De har iøvrigt lige fremrykket lancerings tidspunktet, formodentlig pga. AMD's udmelding
Kilde: http://www.xbitlabs.com/news/cpu/display/200404270...
#31 synes nu vigtigheden af dual på en server er en del større end på en laptop eller desktop-PC som de fleste brugere blot kører én krævende applikation på ad gangen...
#30 jeps, den største fordel ved HT er at man slipper for de ressourcer som spildes ved single CPU multitasking... Her skal data i CPUens registre, ALU osv. flyttes til et midlertidigt sted, hver gang der skiftes til en anden proces, på en HT maskine er dette ikke tilfældet i samme grad, derfor den ekstra smule ydelse
#30 jeps, den største fordel ved HT er at man slipper for de ressourcer som spildes ved single CPU multitasking... Her skal data i CPUens registre, ALU osv. flyttes til et midlertidigt sted, hver gang der skiftes til en anden proces, på en HT maskine er dette ikke tilfældet i samme grad, derfor den ekstra smule ydelse
#32 Et af de argumenter jeg tit har set for SMP systemer fremfor UP systemer er bedre respons. Det faktum at selvom en CPU er belastet har man stadig en CPU til at tage sig af en lille opgave, der lige skal klares, skulle angiveligt gøre systemet meget bedre at arbejde med. Jeg kan huske, at der var en person der sagde, at et dual 150MHz system var meget bedre at arbejde med end en ny computer med en enkelt 500MHz CPU. (Det kan være jeg ikke husker talene helt præcist, det er et stykke tid siden). Jeg har ikke selv arbejdet så meget på multi CPU eller HT maskiner, at jeg har grundlag for at udtale mig. Men hvis ellers argumenterne holder, så burde selv et HT system kunne gøre en væsentlig forskel. Alt andet lige burde en 2000MHz HT CPU give alle fordelene du ville have fået ud af et dual 1000MHz setup, og også bedre performance end det. En af de store fordele ved en HT CPU fremfor dual CPU er, at busywait løkker kan midlertidigt nedsætte den pågældende virtuelle CPUs prioritet, så dens sibling kan køre hurtigere. (Og det vil ikke være usædvanligt, at man faktisk venter på at siblingen skal blive færdig med noget). Selvfølgelig bør der ikke blive brugt ret meget CPU tid på busywaiting, men i multi CPU systemer vil det faktisk nogen gange være nødvendigt (uanset om det er fysiske eller logiske CPU'er). Busywaiting er vist en væsentlig årsag til, at nogle SMP kerner ikke scalerer godt til mange CPU'er. Jeg ville da gerne have dual CPU (eller mere) i min arbejdsstation, men til en laptop ville jeg gladeligt nøjes med HT. Næste gang jeg skal købe ny laptop vil jeg uden tvivl kigge grundigt på strømforbruget. Det kan godt være jeg fik meget computer for pengene ved køb af en Presario, men den bliver altså ekstremt varm, og blæseren larmer mere end min stationære computer.
#34 Jeg fik en computer, der var væsentligt kraftigere end jeg ellers ville have kunnet få for de samme penge. Jeg er glad for, at jeg ikke valgte den store udgave, hvor CPUen var 600MHz hurtigere. Den var dyrere, tungere, fylder mere og bruger mere strøm. Jeg ved da godt at Compaq kan være noget skod, men den jeg købte er altså den bedste Compaq jeg nogensinde har været i nærheden af.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.