Newsgroup: it.comp.hardware.storage
Titolo: trovato l'inghippo tra la FT66 e alcune conf HW/SW (Telstar ci sei??)

allora, come sapra' chi ha seguito i vecchi thread sulla FT66, **sembrava**
esserci una certa incompatibilita' tra la FT (e in generale le schede
Promise) i DJNA e le mobo Asus (ovvero la mia conf ;-(( per la cronaca, la
cpu e' un mendo 450)
orbene, dopo lungo ripartizionare, riformattare, reinstallare, etc etc etc,
credo di essere venuto a capo della questione.
dunque, sembra esserci effettivamente un problemino, ma che non riguarda ne'
la FT ne' la Asus, bensi' il Winbench e/o il gestore d mem di winzozz (IMHO
l'ipotesi giusta e' la seconda).
mi spiego.
con i prg "normali" si ha che la mem usata per la cache di disco puo'
raggiungere tranquillamente i 100MB su una macchina con 128Mb di ram,
soprattutto con winzozz98 che permette di lanciare i vari prg direttamente
dalla cache senza ricopiarli in ram.  se pero' si segue la procedura std
raccomandata da ZD (partenza, defrag, lancio WB) si ha che la ram usata per
la vcache e' al max ~50MB (sulla mia macchina almeno) a fronte di ben oltre
~60MB di memoria fisica libera!!!! tra l'altro per buona parte del test
vengono usati solo 24-32MB a fronte di ~80MB di ram libera!!!!!!!!!
questo per dischi con poca cache interna comporta poco e nulla, mentre per
dischi con grossa cache (tipo il djna appunto) e magari con controller in
grado di raggiungere alte velocita' di picco (UDMA66 appunto) comporta un
grosso rallentamento.
non so se la cosa e' imputabile al solo Winbench (ovvero se esiste una sorta
di "forzatura" della dim della vcache) oppure se e' dovuta ad una qualche
incompatibilita' SW, fatto sta' che con altri prg questo non si verifica.
la cosa si puo' evidenziare in questo modo:
1) partire con un winzozz "pulito" (niente systray, taskmon, etc..) e
lanciare BusDiskWMark. annotare il
risultato;
2) chiudere WB e lanciare il disk bench di Sandra (che al contrario sfrutta
a fondo la vcache. sulla mia macchina a fine test la vcache e' intorno ai
105MB, con ~2MB di mem fisica libera);
3) chiudere Sandra e rilanciare WB99;
l'aumento dovrebbe essere intorno al 25%-30% (con un djna)
con questo "trucchetto" (che in teoria dovrebbe essere sbagliato in quanto
si "sporca" la conf di winzozz e si frammenta la ram) sono passato per un
djna connesso in jbod (cioe' niente raid, una normale connessione UDMA66)
sulla FT da ~4000 (in condizioni ideali) a oltre 4700 (ancora non ho testato
in condizioni ideali, probabilmente a disco vuoto dovrei stare ben oltre i
5000). a conferma ho anche provato la procedura su un vecchio Seagate (1GB
4500RPM, 128K, ATA2) e in realta' il WinMark (come prevedibile) e' rimasto
praticamente fermo (solo un leggerissimo aumento, dell'ordine dell'1%). cmq
credo che dischi con poca cache ma + recenti potrebbero dare risultati molto
migliori.
a questo pto credo che se qlcn (senza fare nomi, HighPoint) fosse a
conoscenza del "fattaccio" potrebbe (ad es.) inserire due righe di codice
nel drv e forzare la max dim cache alla dim mem al boot di winzozz,
lasciando poi il controllo al gestore di ram. ma e' solo una ipotesi
maliziosa.........
e' ovvio quindi che i migliori risultati di questo qlcn sono da attribuire
ad una migliore ottimizzazione SW e non ad una supposta superiorita'
HW......
cmq a parte le polemiche e le elucubrazioni, la cosa importante a cui volevo
arrivare e' che a questo pto credo si possa tranquillamente dire che una
conf FastTrack66 + 2x djna e' superiore a qualunque (e vorrei sottolineare:
qualunque) disco scsi ANCHE NELLE
APPS BUSINESS. e scusate se e' poco. tralascio le ovvie considerazioni sul
prezzo.
inoltre credo che bisognerebbe riconsiderare la supposta superiorita' di
NT4/2000 sul disco. IMHO tali sistemi sfruttano completamente la mem (un po'
come linux) e quindi la maggiore velocita' nei test, sempre IMHO, e' da
ricercare + che altro nell'ottimizzazione del gestore di mem e non tanto
nella superiorita' del file system. mi sembra tanto come se MS abbia voluto
"castrare" appositamente winzozz per far risaltare le doti di NT (che se non
erro ha + patch di un pugile a fine incontro.....)
saluti, sperando di essere stato di chiarimento a qlcn (Telstar ci sei??) e
scusandomi per la lunghezza
PS va' da se' che in realta' nelle apps "vere" che sfruttano la vcache fino
in fondo il prob non si presenta. e' un prob che "tange" unicamente il
WinBench99 usato su dischi con grossa cache, e IMHO e' proprio da
considerare un bug, pero' non so se di winzozz (che per stessa ammissione di
MS e' ottimizzato per 64MB di ram) oppure di Winbench.

 MS e' ottimizzato per 64MB di ram) oppure di Winbench.
Io propendo per winzozz ;) 
-- 
**************************************
Telstar
"Love Magic for itself"
IHGGer Immortal
THE SORCERER: 
http://gilda.it/telstar
 
GDR.NET
 EZINE: 
http://gdr.net/ezine
**************************************

 metterlo in una partizioncina?
no problem. attualmente la FT66 ha i drv per winzozz9x, NT e 2000 (ancora in
beta, ma perfettamente funzionanti) mentre i drv per linux sono attesi per
febbraio/marzo (cfr sito promise)
ciao

 ciao


maliziosa....
non e' che potremmo fare anche noi una cosa del genere?
magari un settaggio in qualche chiav(ica) del registry?
io ricordo che aprendo "proprieta' -sistema", tab prestazioni, bottone
file system, tab disco rigido, c'e' un menu' a tendina che dice
normalmente "computer"; c'e' un impostazione "server di rete" che
forse aumenta la cache (forse).
--
[GAP]

 win98 in C e nt5 in E? (D è per swap e dati di win98)
dove ti serve la maggiore velocita'??? ricordati che le prime partizioni
sono sempre quelle + veloci a causa del posizionamento "fisico" sul disco
(dove per "prime" intendo quelle "logicamente" prime, cioe' in pratica
quelle che fai per prime da sotto fdisk, che pero' come mi ha dottamente
spiegato chi capisce molto + di me stanno in realta' in fondo al disco sulle
tracce ext)
ciao

 ciao
Ciao e grazie! 


 forse aumenta la cache (forse).
serve ad aumentare la cache che winzozz riserva per l'albero delle
directory. serve a poco e a niente, a meno che non lavori con molti prg che
accedono al disco in contemporanea.
ciao

scusate per la spiegazione non troppo "tecnica"
non ti ringraziero' mai abbastanza invece! :-)
--
[GAP]

 troppo tardi per imparare QLCS.
mah...... ci sarebbe il solito 
www.pcguide.com
 pero' potresti trovarlo un
po' troppo tecnico.
ciao

 [GAP]
settalo senza pensarci su a Server di Rete...
probabilmente non farà molto,
ma senz'altro non fa difetto o incompatibilità o crash o ecc.ecc
io è da un paio d'anni che la setto..
va poi detto che nelle varie riviste o nei vari
Tips e Trich (come si scrive ????  :-)))      )
nei trucchi per velocizzare il Sistema consigliano sempre di settarlo
a Server
ciao

 partizione prima di creare l'array
mi spieghi una cosa?
visto che il raid 0 suddivide i dati su più drive trattandoli tutti
come una singola unità, in caso di crash di un disco si perdono tutti
i dati vero?
ma il ft va solo in raid 0? un articolo su pc professionale parla anche di
raid 1
(che e' in pratica un mirroring, seppur con qualche vantaggio) e di uno 0+1
di cui non ho trovato nessun cenno, tu che sei enciclopedico con la ram
lo sei anche per questa roba?
ho letto che nt da' problemi col controller (e visto come fa lo schizzinoso
coi dischi grandi, mi lascia piuttosto timoroso) tu hai notizie? (mi piace
smanettare ma non sono masochista...)
ciao e grazie
--
c.
http://www.blissett.com/IDF
welcome to the ox

 smanettare ma non sono masochista...)
allora, il discorso con NT e' stato un po' pastrocchiato dalla famosa prova
di PcPro. nel senso che cio' che e' stato riportato e' vero, ma non si e'
detto che in realta' il problema non e' della FT.
mi spiego: con dischi UDMA4 hai un burst TR pari a 66.6MB/s. ovviamente con
una conf raid0 hai un burst pari al doppio, ovvero 133MB/s. il problema
nasce dal fatto che la BW del PCI usata nelle conf "casalinghe" (ovvero freq
di 33MHz e ampiezza canale pari a 32bit) e' proprio pari a 133MB/s, per cui
il kernel NT (che tiene sempre sotto stretto controllo l'HW) quando ha un
accesso burst alla FT segnala una occupazione del PCI oltre il consentito
(nota che questo da' probs solo nei bench). ma questo dipende dal fatto che
la FT66 e' troppo veloce in burst per il PCI, non che esistono prob di
incompatibilita' (anzi, dato il differente file system e la differente
gestione della cache, la FT da' il meglio di se' proprio sotto NT).
tra l'altro sotto NT la FT puo' gestire array fino a 128GB, mentre sotto W9x
il singolo array non puo' superare i 64GB.
ciao

 gestione della cache, la FT da' il meglio di se' proprio sotto NT).
livello di convinzione 99,9% (natale e' vicino e un regaluccio me lo dovro'
pur fare, no?)
denghiu' so very much


 pur fare, no?)
^_________^
ciao