NF3, K8T8X0 + Linux?

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/nf3_k8t8x0_linux_135553/page_1 - zur Vollversion wechseln!

COLOSSUS schrieb am 28.01.2005 um 21:01

Ich überlege einen Plattformwechsel zu einem Athlon64, weil mir mein P4 zu stark heizt. Da ich Linux einsetze, ist die Frage der Mainboard- und Chipsatzwahl nicht einfach mit der Performance geklaert... Ich will fuer jede Onboardkomponente einen brauchbaren, stabilen und performanten Open Source Treiber verwenden koennen, und nicht auf proprietäre Software angewiesen sein.

Jetzt stellt sich für mich die Frage, wie es mit dem nF3-250GB aussieht - das GBit-Networking des nf3 klingt interessant; überhaupt alles an dem Chipset ist sehr, sehr verlockend, weil die wichtigen integrierten Controller nicht via PCI an die NB gebunden sind - was bei VIA afaik ja nicht der Fall ist. Nur wie sieht's aus mit NIC, Audio und SATA-Controller; werden die in von mir gewünschter Form unterstützt? Und vor allem: Brauche ich einen Sounddaemon, um mehrere Streams glztg. wiedergeben zu können, oder können die Treiber für gängige nf3/K8T8X0-Onboardsoundlösungen mehrere Streams in Hardware mixen? Kann mir jemand ein konkretes Mainboard empfehlen? (Ja, ich werde auch Overclocken, und das nicht allzu zahm )

Danke für Input im Voraus!

SYSMATRIX schrieb am 28.01.2005 um 21:23

Also wenn du ein stabiles performantes source based system unter linux willst:

folgende HW is atm richtig gut supported:

R2x0 GFX (DRI Xorg mit render extensions, hw-acceld composite)[r200 DRM, hw-acceld mesa r200 treiber]
Intel EE NIC [laut Donald Becker _the_ NICs to choose]
Envy24 basierten Sound [ALSA mit enycontrol, windows like qualty]
Promise TX2/4 SATA controller (open source treiber, jedoch von Promise commited)

den ganze onboard crap ist kaum bis gar nicht bis _broken_ supported oder du hast nicht ansatzweise die qualität und die features die dir die windows treiber bieten.

das konkrete board sollte deshalb so wenig wie möglich onboard haben, sprich so simpel wie es nur geht sein und als direkte konsequenz dessen ist es obendrein auch noch billig. (den onboard shit alles disabeln)

und ja: du brauchst einen snddeamon da das sndcard file ja geöffnet ist, somit gelockt, also kann nicht mehr als ein prozess darauf zugreifen.

damit schlägst du mehrere fliegen mit einer klatsche:
*du hast hardware die du in dein nächstes system mitnehmen kannst

*du hast hardware die unter linux wirklich on par performance bietet wie unter windows

*du bist source only und kannst unter gcc3.4.x -mreg-params verwenden

overclocken jedoch würde ich unterlassen da ein ~x86 profile sowieso unstable ansich ist; mit overclocking dann oben drauf weiß du gar nicht mehr wer den crash jetzt wirklich zu verantworten hat. außerdem sind die paar prozent mehr cpu power die du dir mit 20-30% mehr clock erkauft hast, es dann nicht wert da du dann dann erst recht im thermal envelope eines P4s liegst, von dem du ja eigentlich wegkommen wolltest.

Ringding schrieb am 29.01.2005 um 01:07

Zitat von SYSMATRIX
overclocken jedoch würde ich unterlassen

Blasphemie auf oc.at!

COLOSSUS schrieb am 29.01.2005 um 01:16

Zitat von Ringding
Blasphemie auf oc.at!

Bitte keine Untertreibungen

@SYSMATRIX: Welche Vorteile haette ich mit der erwaehnten Soundlösung gegenüber einer mit emu10k1?

Grafikkarte wird meine GF4Ti bleiben - ich vermeide proprietäre Software wo es geht, aber ich bin nicht bereit, auf 200% Performancezuwachs in 3D-Anwendungen zu verzichten, UND mich zusätzlich nach so einer Karte auf ebay deppertsuchen zu müssen.

Das Problem bei GBIT-NICs via PCI ist halt, dass dann ALLES zu ist. Und wenn ich einen Promise-SATA-Controller nehme, der auch noch via PCI am BUS hängt -> bybebye, Thruput.

Wie sieht's eigentlich mit C'n'Q-Support unter Linux aus?
acpid, richtige Kernelconfig, und fertig? Oder muss man extremfrickeln?

Das mit dem in's nächste System mitnehmen ist zwar eine nette Möglichkeit, aber beim nächsten wirklichen Upgrade wird PCI wohl keine allzu bedeutende Rolle mehr spielen...

Besonders würde mich die Qualitaet des forcedeth-Treibers interessieren, und die von sata_nv. Ich plane nicht, den PseudoRAID-Modus des Controllers zu nutzen, da ich sowieso eine Uniboot-Konfiguration fahren werde, und RAID ggf. via md-Support im Kernel realisiere.

that schrieb am 29.01.2005 um 09:47

Zitat von COLOSSUS
Wie sieht's eigentlich mit C'n'Q-Support unter Linux aus?
acpid, richtige Kernelconfig, und fertig? Oder muss man extremfrickeln?

"emerge cpudyn", ein paar Minuten Docs lesen, fertig.

emStone schrieb am 29.01.2005 um 11:10

Zitat von COLOSSUS
Besonders würde mich die Qualitaet des forcedeth-Treibers interessieren

ich hab ein nf2 borad und muss sagen das ich mit dem forcedeth treiber noch keine probleme hatte.

ich pers. würde noch nicht auf a64 umsteigen.

Viper780 schrieb am 31.01.2005 um 17:24

ich würde bei Linux eher auf am via brettl zugreifen