sslug-teknik team mailing list archive

[Mogens Valentin <monz@xxxxxxxxx>]

Efter køb af nForce2 baseret HW, har jeg brugt noget tid på at finde ud
af om jeg turde satse på stadset eller ej.
Lyder måske ubehageligt, men vi blev fine venner tilsidst :-

HW: Asus A7N8X Deluxe rev2 (nVidia nForce 2 Ultra400), bios 1007
    AMD Barton 3200+, Mist Frostbite cooler med Pabst lownoise 75mA fan
    2x Corsair 512MB 3200LL 2,3,2,6 ram
    Asus V8200 nForce VGA 64MB
    2x Seagate 7200.7 160GB SATA. Box med 2x 120mm Pabst fans.
OS: Slackware 9.1 som host OS, VMware + div. client OS..


Jeg ville køre raid1 (mirror) på de to sATA diske.
Install gik fint, alting virkede. Men maskinen fik solid lockup's med
hdparm -t og ved større/længere localnettransfers.
Mange steder på nettet pegedes fingre ad Seagate's 7200.7 SATA diske.

For nylig stod en nVidia gut frem og indrømmede at alle nForce2 har et
APIC problem (C1 error), som AFAICT bevirker at nForce2's I/O-APIC ikke
kan få afsluttet en interuptsekvens ligeså hurtigt som cpu'ens
local-APIC.

Kort forinden havde jeg fundet en patch til /usr/src/linux/pci/fixes.c,
med en workaround. Patchen var til en noget tidligere 2.6.0-xxx kerne,
og kunne ikke problemfrit lægges ind i 2.6.4 eller 2.6.5, så jeg
kopierede ændringer ind med med religiøse favoriteditor (vi).
Derefter nici o problema med SATA; Seagate 7200.7 er aldeles ok.

Kerne 2.6.6 har nu patchen med, så ingen problemer længere.
Bortset fra hvis man har installeret et system baseret på det 'gamle'
IDE SATA interface. Nu om dags bruger man libata, som hører under scsi
laget.
Derved ændres disk ID's fra /dev/hde og hdg til /dev/sda og sdb.
Det løses ved at ændre alle /dev/hdX til /dev/sdX i /etc/fstab, og
reboote med root=/dev/sda?, hvor '?' er partitionsnummer på
rootpartitionen, hvilket man huskede at checke inden reboot!
Efter boot editeres tilsvarende i /etc/lilo.conf. Husk at køre
/sbin/lilo.

Der er ikke korrekt raid support i Linux for disse fake-raid chipsets.
Raid1 opsat på Sil3112a virker skam, men fra Linux kan man se begge
diske.
Det kan man så vælge at være ligeglad med; jeg brøs mig nu ikke om det.
Simple tests viste at diskperformance var en smule dårligere med RAID1
end for hver enkelt disk. Kan man ozze vælge at være ligeglad med.. 
Til raid 0 (striping) findes et-eller-anden patch fra en tysker.

Bem: Efter at have gennemlæst 60+ tests af mobo's, chipsets og diske på
nettet, vil jeg vove den påstand at raid0 på fakeraids giver
fortræffelig burst-read, og dermed væsentlig hurtigere opstart af
programmer, samt væsentlig hurtigere load af objekter til spil. But
that's about it!


Videre til Linux support af nForce chipset features:
Med Slack 9.1, kernel 2.4.22, virkede alt: alsa, nVidia og 3com net.
Vil man bruge nyere kerner, er netdevices og lyd en anden snak.
nVidia har dog stadig ikke leveret nForce2 drivere til kerne 2.6.x ...
AT kigge i 2.4.x driveren, hvor der et-eller-andet sted står hvilke
moduler man skal have med i /etc/modprobe.conf. Så virkede det igen.
3C920B virker med 3c59x driveren; nVidia's PHY virker med forcedeth, som
er en reverse-engineered OSS driver.

nVidia har derimod en finfin uniform Linux driver til alle deres
videkort.
Der er en overordentlig fyldig REAME, som bør læses og forståes.
Man skal sige Yes til nVidia's eget OpenGL stads for at få 3D
acceleration.
Og huske at hvergang man har kompileret kernemoduler og installeret dem,
er nVidia's videodriver 'nvidia' s'fø'li' væk, og må geninstalleres. No
sweat.


Så sådan blev vi altså fine venner *GG*


Ekstra om nForce2, for dem der skal ud å købe:
Der er pt. nForce2 og nForce2 Ultra400 at vælge mellem. Forhandlere har
dog næppe flere gamle nForce2 mobo's mere.
Der er et nyt Ultra400gb chipset nu. Onchip SATA, 2 xtra USB, men ikke
længere nVidia's Soundforce - som de droppede efter at fejlfortolket
hvor mange der rent faktisk *bruger* Soundforce.
Oh well, nVidia har aldrig begået Linux driver til Soundforce anyways...
Alm. lyd virker ok, og der er lige kommet bedre lyddriver med i det
mindste flere faciliteter supporteret i Linux - til kerne 2.4.x igen,
guddødme!!
Jeg mener nogle distros er kommet/kommer med diverse lyd/net/osv.. ting
og sager færdigarrangerede for folket (suse?).

nForce2 Ultra400 er et dualchannel memory chipset, dvs. FSB er
200MHurtz, og med 2x64bit memory access kalder man det så dualchannel.
Flot marketingsgimmick: Dualchannel opgives til 6.4GB/s, men Barton
3200+ kan teoretisk kun nå 3.2GB/s memory bandwidth. Mere herom om
lidt...
Der er to memory channel controllers. Alle nForce2 mobos (pånær
Gigabyte) har tre DIMM slots. To slots til den ene channel, tredje slot
til den anden channel.
Hvad kan man så putte i disse tre slots?
Een DIMM giver single channel. Dual channel kræver to DIMM's i slot 1+3
eller 2+3. Forståeligt nok. DIMM's skal være ens type og størrelse.

Men hvad hvis man vil have mere ram?
Jeg har 2x512MB, og vil måske ønske 512MB mere af hensyn til VMware...

Manualen siger ikke præsist hvilke kombinationer virker mht,
dualchannel, stabilitet og om en given kombinationen i det hele taget
virker.
Det er umuligt at få Asus eller nVidia til at sige noget entydigt:
En support kontakt hos Asus sagde 'Dualchannel only works with two
DIMM's'.
Deres websupport sagde '..three identical DIMM's should work'.
Tlf. til nVidia US of A. Teknikeren måtte ikke rigtig sige noget pga.
non-disclosure, men jeg fik da ud af ham at dualchannel kun har
betydning for IGP of Soundforce. Dvs. hvis man har integreret video
(Abit NF7-n, Kresten) og hvis man er til spil med horder af genererede
lydeffekter, er der noget at hente. Hvor meget det givet på AGP...
dunno.

Der er bred enighed om at skal man bruge tre DIMM's, skal der bruges to
lige store i slot 2+3 og een dobbelt så stor i slot 1, altså fx. 2x256MB
+ 1x512MB.
Årsagen er at slot 2+3 udgør den ene memory channel, slot 1 den anden.
For at dualchannel virker, skal der være balance i de to channels.
Andre *har* rapporteret success med tre *ens* DIMM's (altså fx. MB768
eller 1536MB). Pga. nVidia's manglende præsise dokumentation forestiller
vi os at fx. i tilfældet 3x512MB, vil man få dualchannel på 1024MB, mens
de sidste 512MB kører singlechannel.

Dualchannel og memory bandwith?
Som sagt tidligere giver det sq ikke meget:
Fem kernel/module compile loops tager omkring 25min. på min HW.
Forskellen mellem single- og dual-channel er ca 22sec - over de fem
loops.
Big deal. Folk siger man kan forvente ~3-5% bedre performance med
dualch.

Et problem mht. valg af cpu er at kun to AMD Athlon's er beregnet til
'400Mhz' bus: Athlon Barton 3000E og 3200.
Alle andre er til 333. Kun Barton 2500+ kører ok på 400 (200MHz FSB).
Med en x11 multiplier kører den 2200MHz, hvilket er ca. 20% OC i forhold
til de nominerede 1833MHz. Det kræver en god cooler og 1.7 - 1.75V core
voltage. Alle gamers gør det. Om man selv vil... well.
Bemærk at *alle* Barton's efter uge 39 2003 er multiplier locked.
Punkum.

Barton 2500 mobile er blevet ret populær, fordi den er nøjagtig magen
til den alm. 2500+. Den er bare helt unlocked, og af AMD testet til at
kunne køre på sim nominelle hastighed ved 1.45V, mod normalt 1.65V.
AMD har altså testet en perfekt OC cpu for folket, hvis man er til
sån't.
Ærgeligt at SVJV ingen mobo's har BIOS support for mobile cpu scaling.
Ret beset er det jo noget åndsvagt at have en cpu kørende full speed,
når man nu bare sidder og skriver email, ikk'?

Valg af ram: Jo hurtigere ram, jo bedre memory bandwidth, og jo mindre
skal cpu'en vente. Fint, hvis man har brug for det, og har pengene.
Jeg har Corsair lowlatency ram. En kammerat med samme mobo/cpu valgte
DaneElec CL3 ram. Jeg har helt sikkert *meget* bedre performance :-
Jeg valgte den type ram fordi der i december 03 stadig var problemer med
DDR ram, og maskinen skulle være både rimelig hurtig, og helt stabil.

Ram timing: nForce2 kan ikke finde ud af at beregne en bestemt
parameter; sorry, jeg kan ikke huske hvilken. Derfor bør man sætte ram
timing manuelt, og sætte tRP længere end opgivet fra fabrikanten.
Der har været laaaange diskussioner på fx. Corsair's houseofhelp forum.
Generel consensus er at med nogenlunde hurtig ram bruges tRP=10; med
knap så hurtig ram bruges tRP=11.
Hastighedsforskellen er absolut ikke imponerende, men siden den er der,
er det min holdning at det har en betydning. Måske ikke ligefrem for
selve hastigheden, men nok mere for stabiliteten.
Yes, jeg testede timing en hel dag, og hvis jeg skruede bare en smule op
for FSB, kunne jeg ikke kompilere kerne/moduler uden fejl, medmindre jeg
brugte korrekt tRP. Ikke sådan at jeg OC'er min FSB; det var for at
teste hvor tæt systemet var på grænsen af stabil/ustabil timing.

Jeg vil ikke dømme ramfabrikater. Det er meget forskelligt hvilke
erfaringer man har på nettet. Stort set ingen beklager sig over Corsair.
Mange bruger Kingston, men pas på deres HyperX efter de skiftede
chipfabrikat. Mange vil sværge at OCZ's tidligere ram er noget hø, mens
deres nyeste ser ganske godt ud. Geil er der så delte meninger om, at et
er umuligt at afgøre noget.
Men bemærk her, at mange vurderer komponenter udfra om de kan OC.
Tåbeligt, vil nogen mene. På den anden side: Hvis gamers og OC'ers er
enige om at et given sæt komponenter kan så-og-så meget xtra, er det
måske rimeligt at antage, at disse så uden OC vil køre ganske stabilt.

http://www.nforcershq.com er et kanon forum for... nForce.


Nu har jeg skrefet en hel masse, som måske lyder som om man skal holde
sig fra nForce. I så fald: Læs det igen.
Stadset kører altså kanongodt. Jeg har bare været igennen en hel del
test og læseri for at sikre mig at det nu ozze var ok. Og det skyldtes
at jeg i starten kom i tvivl pga. de omtalte SATA problemer.
Det ene tog så det andet...

Som sagt: Vi blev såmænd ganske gode venner.

(Hvis nogen mener det eneste der duer er Intel, så køb et mobo der
bruger Intel ICH5 (mener jeg det hedder) til SATA, og se hvad der sker
med to WD Raptor SATA i raid under load med store filer. Hint: Læs den
store chipset sammenligningstest på techreport)

-- 
Kind regards,
Mogens Valentin
Networking, Security
www.danbbs.dk/~monz
Phone +45 32 525 878



OOUPS!: TRACEMAR SYMBOL!
After spending billions of dollars trying to persuade the world+dog that
MegahurtsMatters® Intel has now had a Damascene experience and realise
that MegahurtsDon'tMatterAtAll®.

What matters now are numbers akin to BMW model numbers, but with that
extra
je ne sais quoi to make the scheme impenetrable to anyone who hasn't got
an
INQUIRER crib sheet.
  -- theinquirer.net