<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Linux PCI-HOWTO: Motherboards ASUS</TITLE> <LINK HREF="PCI-HOWTO-4.html" REL=next> <LINK HREF="PCI-HOWTO-2.html" REL=previous> <LINK HREF="PCI-HOWTO.html#toc3" REL=contents> </HEAD> <BODY> <A HREF="PCI-HOWTO-4.html">Avanti</A> <A HREF="PCI-HOWTO-2.html">Indietro</A> <A HREF="PCI-HOWTO.html#toc3">Indice</A> <HR> <H2><A NAME="s3">3. <SF>Motherboards</SF> ASUS</A></H2> <H2><A NAME="ss3.1">3.1 ASUS e il NMI (Parita') -- impatto sulla Gravis-Ultrasound</A> </H2> <P>Le piu' recenti <SF>motherboards</SF> PCI Triton del 1995 non sembravano piu' supportare le SIMM con parita'. Dato che io di solito ho comprato quelle senza (che costano meno) non pensavo che questo fosse un problema fino a quando non ho inserito la Gravis Ultrasound nel mio computer.Sotto DOS il driver SBOS e la utility di setup si lamentano che la "nmi procedure disabled on this p.c." <SF>(la procedura nmi e' disabilitata su questo pc, sarebbe il Non Maskable Interrupt che DI SOLITO viene attivato da un Parity Error ma non solo come potete leggere qui N.d.T.))</SF>. Il manuale dice che dovrei comprarmi una <SF>motherboard</SF> migliore e non e' che questo sia di molto aiuto. <P>La gravis-ultrasound funzionava senza problemi sulle ASUS-SP3 e ASUS-SP4 nonostante questo problema ma la gravis ultrasound max che ho qua mi causa un kernel panic su entrambe le <SF>motherboard</SF> e talvolta, mentre ascolto files .au attraverso /dev/audio, fa strane cose, come ad esempio suonare il resto di un vecchio campione suonato prima di quello corrente. Il sound driver raccomanda un buffer di 65536 sulla GUS Max invece di quello piccolo raccomandato con la GUS e non chiedetemi il perche'. Comunque non ho piu' di questi problemi sulla piu' recente ASUS TP4XE. Entrambe sono equipaggiate con 1 MB di Ram. Questi problemi potrebbero non essere dovuti al nmi, potrebbe forse essere colpa del driver audio ? <P>Ho sentito che non solo la ASUS ma la maggior parte delle nuove <SF>motherboards</SF> PCI non hanno il supporto per la parita'/NMI. <P>Stranamente l'ASUS-TP4 (<SF>chipset</SF> Triton) funziona con la GUS Max e carica l'SBOS, lo devo ammettere, sono confuso anch'io. <P> <H2><A NAME="ss3.2">3.2 Vari tipi di <SF>motherboards</SF> ASUS</A> </H2> <P> <P> <H3>ASUS SP3 con chipset saturn I (rev. 2) per 486,</H3> <P> <UL> <LI> 2 x rs232 con 16550</LI> <LI> NCR53c810 <SF>onboard</SF>,</LI> <LI> chipset saturn I leggermente bacato (rev. 2)</LI> </UL> <P> <H3>ASUS SP3G con chipset saturn II (rev. 4) per 486,</H3> <P>come la SP3, ma chipset saturn meno bacato <P> <H3>ASUS SP3-SiS chipset, per 486</H3> <P>come la AP4, ma con : un nuovo chipset SiS, funzioni 'green' , controller EIDE, seriali 16550 e parallela <SF>onboard</SF>. Ha solo due slot per le SIMM. Sembra funzionare con gli AMD486DX4/120 ma non e' stata molto affidabile con l'NCR53c810 e vari sistemi operativi (Win-NT, Windows95, OS2); dopo essere passati a una ASUS SP4 Pentium tutti i problemi sono scomparsi e pertanto si pensa che la loro causa fosse proprio da ricercarsi nella <SF>mainboard</SF>. Sembra comunque funzionare bene con linux. <P> <H3>ASUS AP4, per 486, con PCI/ISA/VesaLocalbus</H3> <P>funzioni 'green' , 1VL, 3 ISA, 4 PCI slots, solo EIDE <SF>onboard</SF>, no controller floppy, no rs232/centronics. Molto piccola. <P>riconosce l' AMD486DX2/66 solo come DX4/100. Questo puo' essere corretto con la saldatura di un pin (quale?) a terra ma non raccomanderei comunque una <SF>motherboard</SF> di questo tipo. <P>Quella che ho provato io non andava ne' con OS/2 ne' con Linux ma alcuni dicono di usarla con entrambi. <P>Lo slot VESALB dovrebbe essere piu' lento di quelli delle <SF>motherboards</SF> vesa-lb a causa del 'ponte' PCI-VL ma non ci dovrebbero essere penalizzazioni nella sezione PCI. <P> <H3>ASUS SP4-SiS, per Pentium90, PCI/ISA</H3> <P>come la SP3-SiS, ma per Pentium90/100. <P> <H3>ASUS TP4 con chipset Triton e supporto EDORAM</H3> <P>ha il chipset Triton per migliorare le prestazioni e supporta le normali SIMM PS/2 in aggiunta al modo Fast-Page e i moduli EDO. <P> <H3>ASUS TP4XE con chipset Triton e supporto SRAM/EDORAM aggiuntivo</H3> <P>supporta le nuove EDORAM e le future SRAM. Si dice che per lo meno la SRAM dovrebbe aumentare considerevolmente le prestazioni. Per qualche oscura ragione non ha accettato le SIMM da 8MB che funzionavano benissimo sulla ASUS SP4; dopo averli cambiati con degli altri che sembravano piu' grossi ( 16 chips invece di 8 se mi ricordo bene ) ha funzionato bene. E' stata testata con un P90 e un P100. <P> <H2><A NAME="ss3.3">3.3 Benchmarks sulle <SF>Motherboards</SF> ASUS</A> </H2> <P>Ho tentato di confrontare le velocita' delle CPU in due <SF>motherboard</SF> ASUS: per il 486 ho testato la SP3 SiS (quella con uno slot VesaLB ) e per il 586 ho usato la ASUS TP4/XE: ognuna aveva 16MB RAM, per il resto e' stato usato un sistema identico. <P>Devo ammettere che non ho ancora letto la FAQ dei benchmarks e pertanto questa sezione potrebbe cambiare notevolmente presto. Se avete qualche commento da fare per piacere scrivetemi. <P>Sono specialmente confuso dal fatto che l'AMD486DX4/100 e' stato piu' veloce del 120 sui dhrystones (?!). Non ho notato di queste incongruenze comparando il P90 e il P100. <P>Probabilmente il problema era questo: quando ho messo dentro l'AMD DX4-100 avevo la <SF>motherboard</SF> settata per un DX2/66. Anche se il BIOS lo riportava come un DX4-100 la <SF>motherboard</SF> avrebbe potuto usare una frequenza di clock errata... comunque, dato che il DX2-66 usa 33MHz * 2 e il DX4-100 usa 33MHz * 3 non capisco perche' non sia corretto. <P>La <SF>motherboard</SF> che usa il DX4-120 e' settata come 40MHz * 3 = 120MHz. <P>Un'altra cosa che mi chiedo e' perche i risultati dei wheatstones su alcune macchine danno dei numeri cosi' puliti... <P> <H3>ASUS SP3 with amd486DX4-100</H3> <P> <UL> <LI> Dhrystone time per 500000 passi = 7 per 63559 dhrystones/secondo</LI> <LI> Whetstone time per 1000 passi = 5 per 200.0000 Whetstones/secondo</LI> </UL> <P> <H3>ASUS SP3 with amd486DX4-120</H3> <P> <UL> <LI> Dhrystone time per 500000 passi = 8 per 56074 dhrystones/secondo</LI> <LI> Whetstone time per 1000 passi = 4 per 250.0000 Whetstones/secondo</LI> </UL> <P> <H3>ASUS SP3 with intel486DX2-66</H3> <P> <UL> <LI> Dhrystone time per 500000 passi = 9 per 50761 dhrystones/secondo</LI> <LI> Whetstone time per 1000 passi = 7 per 142.8571 Whetstones/secondo</LI> </UL> <P> <H3>ASUS TP4/XE with intel586-90</H3> <P> <UL> <LI> Dhrystone time per 500000 passes = 4 per 101010 dhrystones/secondo</LI> <LI> Whetstone time per 1000 passes = 3 per 333.3333 Whetstones/secondo</LI> </UL> <P> <H3>ASUS TP4/XE with intel586-100</H3> <P> <UL> <LI> Dhrystone time per 500000 passi = 4 per 102040 dhrystones/secondo</LI> <LI> Whetstone time per 1000 passi = 2 per 500.0000 Whetstones/secondo</LI> </UL> <P> <H2><A NAME="ss3.4">3.4 Informazioni dettagliate sulle vecchie ASUS PCI-I-SP3 con chipset saturn da heinrich@zsv.gmd.de:</A> </H2> <P> <P> <UL> <LI> 3 PCI, 4 ISA Slots (3x16, 1x8 Bit)</LI> <LI> ZIF Socket for the CPU</LI> <LI> posto per 4 72pin-SIMMs (max. 128M)</LI> <LI> Award BIOS su Flash-Eprom</LI> <LI> <SF>Onboard</SF>: NCR-SCSI, 1par, 2ser (con FIFO), AT-Bus, Floppy</LI> </UL> <P>La <SF>motherboard</SF> si comporta come la maggior parte di quelle nella sua classe: cache write-through senza possibilita' di write-back. Non dovrebbe comunque essere importante, al massimo un 3% di prestazioni. <P>Il BIOS supporta dischi rigidi SCSI sotto DOS/Windows senza drivers aggiuntivi ma con la <SF>motherboard</SF> ci sono doi drivers aggiuntivi che dovrebbero migliorare le prestazioni sotto DOS/Windows(ASPI), OS2, Windows-NT, SCO-Unix, Netware (3.11 e 4, se ho capito bene.) <P>Gert Doering (gert@greenie.muc.de) ha detto che il driver per SCO-Unix del chip SCSI <SF>on board</SF> non funzionava correttamente. Dopo due o tre comandi del tipo "time dd if=/dev/rhd20 of=/dev/null bs=100k count=500" c'e' stato un kernel panic... <P>I guai che hanno passato alcune persone con questa <SF>motherboard</SF> potrebbero essere causati dall'utilizzo di un Controller Adaptec SCSI esterno con la "sync negotiation" abilitata. (Questo e' successo prima dell'uscita dei drivers NCR, ecco il perche' dell'uso dell'Adaptec.) Per favore controllate nel setup del BIOS dell' Adaptec-1542C se lo usate anche voi e avete problemi con occasionali blocaggi del computer. <P>C'e' una nuova versione della <SF>motherboard</SF> ASUS che dovrebbe sicuramente avere meno problemi. E' chiamata ASUS-PCI-I/SP3G, la G e' importante. Ha il nuovo chipset Saturn rev. 4 e i bugs dovrebbero essere spariti. Essi usano la variante Saturn-ZX e la nuova SP3G ha interrupt pienamente conformati PCI ( cioe' level triggered ( i.e. condivisibili ) e configurabili da BIOS). Ha una porta mouse PS/2 <SF>onboard</SF>, ha modi power-saving EPA e supporto DX4. Ha delle eccellenti prestazioni. Se potete trovare la rivista tedesca di computer C't di Luglio (?) troverete una prova in cui si dice che la <SF>motherboard</SF> ASUS e' la migliore in circolazione. <P>Ultima informazione sulla ASUS-SP3-G: potreste sperimentare dei crash di sistema se usate il PCI-to-memory-posting. Se lo disabilitate tutto funziona perfettamente. w@peanuts.informatik.uni-tuebingen.de dice di credere che questo sia un problema del corrente kernel di Linux perche' parte del sistema continua a funzionare anche dopo che il resto si e' piantato, come se ci fosse un deadlock nello swapper, e perche' OS2/DOS e WINDOWS non hanno problemi. <P> <HR> <A HREF="PCI-HOWTO-4.html">Avanti</A> <A HREF="PCI-HOWTO-2.html">Indietro</A> <A HREF="PCI-HOWTO.html#toc3">Indice</A> </BODY> </HTML>
