Newsgroup: it.comp.hardware.overclock
Titolo: hard disk

per tutti quelli che si lamentano della scarsa velocità dell'hdd è
assolutamente normale
infatti i 66mb/sec SONO LA VELOCITà DELL'INTERFACCIA NON DEL DISCO
infatti il disco trasferisce i dati al buffer ad una certa velocità molto
bassa, POI DAL BUFFER ALLA RAM VANNO A 66MB/S (O 33 O 100) (il discorso è
molto più lungo ma non mi dilungo)
per questo da ata 33 a 66 o 100 NON CAMBIA UN CAZZO LA VELOCITà ATA E SEMPRE
MOLTO PIù GRANDE DELLA VELOCITà REALE DEL DISCO, è L'ENNESIMA TROVATA PER
INGANNARE I POVERI UTENTI CHE CI CREDONO (COME L'AGP4X, IL FAST WRITE, IL
T&L, L'FSB 133, CONTINUATE VOI LA LISTA

, CONTINUATE VOI LA LISTA
Continuala tu, ma dicendo un po' meno caxxate ;-) !

 ha scritto nel messaggio
news:39af6.98449$ew1.5...@news.infostrada.it...

La prima osservazione è: che bisogno c'è di urlare per dire delle cose così
banali, oltre che molto imprecise?
La seconda è: all'epoca dell'UDMA33 le testine dei dischi avevano una
velocità di trasferimento di circa 5-6MB/s, e una cache di 512 KB e la
velocità di 33 MB/s era tarata per questo genere di prestazioni. Ora, un IBM
DTLA ha una velocità di trasferimento che varia tra i 37 MB/s (all'esterno)
e i 23 MB/s all'interno e una cache di 2 MB. Se venisse usato con un
controller UDMA33 che ha una velocità di trasferimento reale di circa 20-24
MB/s praticamente sarebbe sembre sottoutilizzato. Inoltre, la cache da 2 MB
non è lì tanto per fare numero, ma perchè contiene i dati che la logica del
disco ritiene probabile vengano richiesti nel prossimo futuro, ed in questo
caso, il trasferimento avviene a 100 MB/s. Che la velocità debba essere più
grande di quella del disco è una cosa naturale per due motivi: uno, che se
dico 100 MB/s nominali, in pratica, a causa dei vari tempi morti la velocità
reale è inferiore (sugli 80 MB/s può essere una stima attendibile), secondo,
se creo uno standard da 50 MB/s con i dischi che vanno già a 40 MB/s dopo
due settimane sono già indietro.
E' chiaro che se ho un disco UDMA33 e lo monto su un controller ATA100 il
vantaggio sarà minimo, dovuto essenzialmente ai migliori tempi di risposta
del controller più moderno.
Per quelli che si lamentano della scarsa velocità del loro disco (ammesso
che sia un disco veloce), consiglio di installare i driver corretti e
aggiornati, di verificare la qualità del cavo e in caso di dubbio di
sostituirlo, di aggiornare bios della scheda madre e dell'eventuale
controller ATA100, e alla fine di fare defrag. Un IBM DTLA deve trasferire
un file di 600 MB in non più di 50 secondi ad un altro disco di pari
prestazioni o anche ad un disco ATA66. In condizioni ideali (disco
abbastanza vuoto) è lecito attendersi anche i 18-20 MB/s reali (100 MB in 5
secondi) e posso garantire che un disco UDMA33, 100 MB, se va bene, li
trasferisce in 25-30 secondi.
Spero di averti chiarito un po' le idee.
Ciao
Massimo

 ha scritto nel messaggio
news:95jeba$h34o5$1...@ID-60218.news.dfncis.de...

[CUT]

 Hei io monto un DTLA da 15Gb su una mobo con controller UDMA33 :-))))
Cosa posso dirti: tanti auguri di poter presto acquistare una motherboard
con ATA100 e vedere veramente che mostro di disco ti sei comprato -:))))
Ciao
Massimo

 wrote in message
95jeba$h34o5$1...@ID-60218.news.dfncis.de...

Aggiungo solo una cosa , quando una periferica IDE è in funzione (scrittura
o lettura) occupa il bus ide a cui è collegata e perciò una eventuale altra
periferica sullo stesso canale deve aspettare che la prima abbia finito ,
perciò + alta è la veocità di trasferimento del canale prima esso si libera
.
In oltre nella fase di trasferimento dei comandi ATA il processore (e il
controller) sono in attesa di una risposta dall'interfaccia del disco (o
cd-rom ecc..) che ovviamente è + veloce su un ATA-100 piuttosto che su un 33
, sommate il tutto e vedrete che a parità di disco è cmq preferibile andare
a 100 piuttosto che a 33 ...

 per questo da ata 33 a 66 o 100 NON CAMBIA UN CAZZO
__________________________________________________
Vogliamo provare a fare,che sò,un defrag con un
sistema ATA100 ben implementato,tipo Cusl2
e confrontarlo con un'altra bella scheda tipo,che sò
una P2b??

 L'FSB 133
In effetti cambia poco o niente rispetto a 100,
poi diminuisce anche la possibilita' di overcloccare :-(
Ciao by Ferro


Beh, in effetti anche avere un Athlon 1200 non è poi molto diverso
dall'avere un Duron 700. E volendo, si può anche dire che avere un Duron 700
non è poi molto diverso dall'avere un Pentium 133. Come disse qualcuno,
tutto è relativo!!!
ROTFL ROTFL ROTFL
Ciao
PS: Comunque, è evidente per tutti che le prestazioni di un bus a 100
overcloccato a 115 sono decisamente migliori di quelle di un bus a 133!!!!
Ri - ROTFLT, ROTFL ROTFL

 Ri - ROTFLT, ROTFL ROTFL
Abbattiamolo rotfl rotfl ( e non rotflT )
Ciao by Ferro

 Abbattiamolo rotfl rotfl ( e non rotflT )
Mi è scappata una L su sei volte, mi sembra molto puerile la tua
sottolineatura (quanti anni hai? 10?). Abbattiti le mani da solo che è
meglio.
Ciao
Massimo


a parte il fsb, che effettivamente da un grosso incremento, il resto
e' molto utile se non viene sfruttato...
posso farti sorridere con un proverbio in trentino?
gaverla e no'usarla, le tant che non gaverla

cx di quasi 3 anni fa
Scusa la la serie LCT non è una serie performante.. è indirizzata a pc
da ufficio in cui è + importante al sicurezza che non le
performance... confronta un LM con il CX, anche se il confronto
sarebbe impari visto che l'LM è un 7200....
Ciao
Alex77
Alex77*****************************************
Ford Mondeo 1.8ie 16V SW 94' - Eibach - Driver
www.digital-sat.it
***********************************************

 e' molto utile se non viene sfruttato...
Credo che qui tu volessi dire "...non è molto utile..." e sono d'accordo:
l'esempio che hai fatto con il disco in questo senso è perfetto: sparare il
nome ATA100 e poi fare tutto il possibile per avere basse prestazioni è il
massimo. Ma se si prende in considerazione un disco serio (tipo il solito
IBM DTLA 30 o 45 GB) la musica cambia in modo impressionante. Aprire un file
word da una dozzina di MB in meno di un secondo, o aprire una trentina di
foto digitali da 600 KB l'una in qualche secondo, posso garantirti che ti fa
godere anche se stai usando delle applicazioni da ufficio. Stesso discorso
per Excel: salvare un file di qualche MB in un attimo, invece che in
quindici o venti secondi, nell'arco della giornata fa la sua differenza, non
solo in termini di tempo risparmiato, ma specialmente in termini di quella
sensazione indescrivibile di piacere che deriva dal non perdere tempo o dal
non dover aspettare che il PC macini e rimacini.
Ciao
Massimo

 ha scritto nel messaggio
news:95jve0$hc4h6$1...@ID-60218.news.dfncis.de...


 madness2, puoi scegliere d3d o d3d con T&L, sono identici!!!!!!!!!!)
Io credo che gli utenti più inesperti di tutti siano quelli che si
costruiscono il loro quadretto più o meno filosofico e poi cercano di
adattarvi i dati tecnici che possono leggere più o meno malamente in giro,
salvo naturalmente ignorare tutto ciò che è in contraddizione con il loro
quadretto.
Comunque, contento tu, contenti tutti, solo cerca di non sbandierare le tue
fissazioni come se fossero vangelo. Il 5% di incremento di prestazioni
globali non è il 20% ma non è nemmeno 0%. Come ho detto prima significa un
incremento di 50 Mhz alle frequenze attuali delle CPU, incremento che poi
offre lo spunto per un overclock, come sottolineato anche nelle conclusioni
di hwupgrade.
Certo che se il tuo unico problema è quello di giocare a midtown madness2,
probabilmente devi concentrarti solo sulla scheda grafica, ma non tutto il
mondo degli utilizzatori di PC gioca solo a midtown madness2.
Ciao e auguri per i tuoi studi
Massimo

 ha scritto nel messaggio
news:39af6.98449$ew1.5...@news.infostrada.it...


 ha scritto nel messaggio
news:jAbf6.99112$ew1.5...@news.infostrada.it...


 ...e quindi sostenere che non serve a nulla aumentarla è del tutto insensato.
Certo sono d'accordo anche io, quello che volevo solo dire e'
che poi l'aumento di prest non era cosi' grande.
Cmq ciao by Ferro

 trasferisce in 25-30 secondi.
Certo. Perchè il disco UDMA33 è più lento di suo. Lo stesso hd, con un canale
dedicato, avrà le stesse identiche prestazioni sia con un controller ATA100 che
con un controller UDMA33. Non vedo per quale esoterico motivo dovrebbe andare
più piano. E questo è quello che si asseriva GIUSTAMENTE nel post di Cesco.
Non ingrossiamo la categoria degli info-creduloni che spendono mezzo-milione in
più per prendere un P3 che va una manciata di mhz più veloce (su 800 o 900,
cos'è un 20% di velocità in più? Ho i brividi...) e poi si comprano magari un
monitor sfigato o il mouse a due tasti della microsot da 8.000 lire....

 transfer-rate più alto.
Cito solo la stronzata più grande di tutte (tranne quella della velocità):
in EIDE i comandi vengono eseguiti uno per volta, se una periferica sta
facendo un trasferimento, le altre aspettano (nel senso che sono costrette
ad aspettare). Questo invece non è vero per SCSI, che utilizzando un
protocollo molto più sofisticato (e purtroppo anche piuttosto "pesante")
permette di eseguire i comandi in parallelo. I dischi che posso collegare su
un bus SCSI 50 pin sono 8, mentre sono 16 (in teoria) su un bus SCSI wide
(connettore 68 pin).
Ripeto: prima di intervenire come se fossi il figlio di Bill Gates, studia:
dire, "16 o 32 non ricordo", fa semplicemente pena, perchè se non sai quanti
sono i dischi su un bus SCSI non sai nemmeno perchè sono 8 o 16, e quindi
tanto meno puoi permetterti di dissertare sulle velocità di trasferimento
dei bus.
Chiedo scusa al ng per il linguaggio non propriamente da educanda, ma credo
che in un caso come questo mi sia concesso di rispondere a tono.

 > T&L, L'FSB 133, CONTINUATE VOI LA LISTA
Allora qui bisogna fare un po' di chiarezza....La velocita' di trasmissione
dei dati da un disco rigido si divide in due grandi blocchi:
1) la cosiddetta "burst" (a raffica) con cui la cache fisica del disco (oggi
i moderni 7200 giri EIDE ne hanno 2Mb) "spara" i dati al computer, e per
esempio IBM DTLA ha un transfer di questo tipo superiore agli 80MB/s (almeno
a quanto dice il test HDtac)
2) il "sustained trasfer rate" e cioe' la capacita' della meccanica del
disco di rifornire la cache interna. Ovviamente questo e' il collo di
bottiglia di tutto il sistema considerando che gli IBM hanno una capacità di
fornire circa 38 MB/s nelle tracce piu' esterne e sensibilmente inferiore su
quelle interne.
E' ovvio che se il sustained trasfer rate non riesce a rifornire la cache,
esauriti i 2Mb di dati presenti nella memoria del disco, la velocita'
ovviamente si abbassa fino a raggiungere quella strettamente "meccanica" con
cui l'HD provvede a riempire nuovamente la cache interna.
Quindi la modalita' ATA33 e' comunque insufficiente ad esprimere al massimo
la velocita' dei nuovi dischi da 7200 giri visto che la velocita' (del tipo
2) che riescono a sprigionare e' di circa 35-38 Mb/s nelle tracce piu'
esterne, la modalita' ATA66 andrebbe bene ma non per quei pochi attimi in
cui la cache lavora in modalita' burst verso il PC, l'ATA100 anche se
sfruttato allo 0,05 % (in termini di tempo) e' l'unico che comunque permetta
lo smaltimento della cache a velocita' piena.
Il problema e' che avendo a che fare con file piuttosto grossi (bastano piu'
grandi di 2Mb) la maggior parte del tempo la cache interna dell'HD lo passa
ad aspettare i dati dalla meccanica del disco e quindi la velocita' "pura"
e' proprio data, a parte qualche frazione di secondo, proprio dal sustained
trasfer rate.
In modalita' RAID 0 la cosa e' diversa, li' le meccaniche dei dischi
lavorano in parallelo e, mentre l'accesso al disco risulta piu' o meno pari
a quello di un disco solo, il sustained trasfer rate quasi raddoppia. Nel
caso dei moderni dischi quindi si passa ad una velocita' esterna di circa
70-75Mb/s e quindi finalmente si rende necessario al 100%  il protocollo
ATA100.....
Quindi non sono assolutamente d'accordo con te! ;)))

 (connettore 68 pin)............................
Visto che mi pare che ci capisci potresti rispondere ad una domanda che ho
postato un po' di tempo fa a cui nessuno mi ha dato riposta?
Ho notato che il controller Promise ATA100 sfrutta un solo IRQ per tutti e
due i canali EIDE a differenza di quello onboard del chipset.
Ho 2 IBM DTLA ATA100 su  un canale e un Quantum AS sul master del secondo
canale tutti comunque sul Promise. Ho notato trasferendo un file di 1Gb dal
primo IBM al secondo e, sempre dal primo al Quantum che la velocita' e' la
stessa piu' o meno 16Mb/s. Mi sarei aspettato che il trasfer rate sullo
stesso canale (IBM1 a IBM2) avvenisse in modo sensibilmente piu' lento
invece che dal primario al secondario (IBM1 a Quantum).
Non e' che quei diavoli della Promise hanno implementato una sorta di
gestione  elettronica piu' efficiente che di fatto annulla il gap
prestazionale di scambio dati tra periferiche presenti sullo stesso canale e
tra canali diversi?
Bye
Alberto

 transfer-rate più alto.
Appunto solo gli SCSI hanno il "disconnect", le periferiche EIDE se montate
sullo stesso canale sfruttano un IRQ solo, quindi una richiesta di dati o di
scrittura puo' essere assolta solo quando la precedente e' terminata....La
faccenda migliora se sono connesse su canali diversi ma non raggiunge
sicuramente l'efficienza di un BUS SCSI, se no a quest'ora quella tecnologia
sarebbe morta soppiantata dall'EIDE molto piu' economico....
Bye
Alberto

 quelle interne.
Ovviamente io parlo di valori di picco, ad abbassare ulteriormente le
velocita' intervengono moltissimi altri fattori che di fatto limitano le
velocita' medie di trasmissione dati a valori mooolto piu' bassi....
Bye
Alberto

 ATA100.....
Purtroppo con i controller RAID EIDE attuali (l'ADAPTEC AAA-UDMA č forse il
migliore) non si riescono a raggiungere questi livelli, nemmeno lontanamente
(leggiti, se puoi, l'articolo di PC-Professionale di Agosto2000 a pagina 102
e seguenti). In pratica, anche con questo controller non si riesce a
superare quello che č un limite dell'architettura EIDE, e cioč
l'impossibilitŕ di parallelizzare i trasferimenti. I piccoli vantaggi che si
ottengono sono dovuti alla capacitŕ di parallelizzare i comandi (e non i
trasferimenti) ai due dischi sui quali si trovano spalmati e dati, ma il
tutto si ferma lě (in certe condizioni l'insieme risulta piů lento del disco
singolo DTLA). Questo tipo di controller, secondo me, č meglio usarlo in
RAID1, cioč per fare una copia continua di un disco sull'altro per avere un
ottimo livello di affidabilitŕ sui dati, ma, visto il costo (oltre il
1.000.000), non č consigliabile per ottenere un aumento delle prestazioni
(quasi nullo).
Ciň non toglie che l'ATA100 č sicuramente molto valida se usata su una
motherboard moderna, con una CPU potente e con un disco ATA100 di alte
prestazioni. Il problema č sempre quello dell'equilibrio: avere un
controller ATA100 con disco LCT (a 5400 giri e 128 KB di cache) naturalmente
serve a poco. Lo stesso dicasi se metto controller ATA100 e IBM DTLA su una
motherboard di tre anni fa con un Pentium II 300 Mhz.
Ciao
Massimo

 tra canali diversi?
Per quel che riguarda la velocità di trasferimento, sicuramente il
controller Promise è più efficiente di altri controller standard montati su
motherboard, che poi anche per questioni di driver più o meno ottimizzati
possono presentare problemi diversi in situazioni diverse, ma da un punto di
vista strettamente teorico, non c'è molta differenza tra trasferire dati tra
due dischi sullo stesso canale o tra dischi che si trovano su canali
diversi. Il percorso è comunque lo stesso: si legge un blocco dal primo
disco e lo si mette in RAM, si scrive lo stesso blocco sul secondo disco
leggendolo dalla RAM, si legge un altro blocco... etc. etc.. Naturalmente,
la velocità di 16 MB/s è tutt'altro che disprezzabile, perchè siccome sto
parlando di una copia, ciò significa fare due operazioni (lettura e
scrittura) quindi vuol dire che i due dischi in realta stanno viaggiando sui
32 MB/s (cioè leggo un pezzo a 32 MB/s, mi fermo, mentre scrivo lo stesso a
32 MB/s sull'altro disco, poi riparto col primo .... e così via).
Quindi il gap prestazionale di cui tu parli funziona al contrario: le minori
prestazioni sono probabilmente dovute a delle pecche del controller (o del
suo driver software) sul quale lo avevi rilevato, mentre il Promise funziona
come sarebbe giusto che funzionasse.
Ciao
Massimo

 leggendolo dalla RAM, si legge un altro blocco... etc. etc..
Pero' scusa per come dici tu, ammettendo le due situazioni in cui:
1) Dischi su canali separati (IRQ diversi)
Il disco in lettura occupa l'IRQ n°1 e lo manda in RAM, da quest'ultima il
blocco viene spedito sull'altro disco occupando l'IRQ n°2, mentre cio'
accade pero' l'IRQ n° 1 comunque e' a disposizione del primo disco per
leggere un altro blocco, quindi teoricamente mentre il disco in scrittura
procede a registrare il primo blocco, contemporaneamente, data la
disponibilita' di due IRQ, il disco in lettura puo' leggere il secondo
blocco in una sorta di parallelismo...
2) Dischi su stesso canale (stesso IRQ)
Il disco in lettura occupa l'unico IRQ disponibile e lo manda in RAM, da
quest'ultima viene spedito sul secondo disco occupando cosi' il medesimo IRQ
e quindi lasciando in "standby" il disco in lettura che non avendo l'IRQ
libero non puo' andare a leggere il secondo blocco fin quando il disco in
scrittura non ha terminato di scrivere il primo...E cosi' via...
Secondo me ci dovrebbe essere un indubbio vantaggio nell'avere i dischi su
canali diversi...Tu che dici ti ho convinto? ;))
Bye
Alberto

 trasferimenti) ai due dischi sui quali si trovano spalmati e dati,
Non avendo un controller RAID non posso esserne assolutamente sicuro
comunque ho letto una recensione del sito 
http://www.hwupgrade.it
 che
testava proprio i controller RAID EIDE adesso piu' diffusi e cioe' il
FASTTRAK100 della promise e l'HOTROD100 della Abit, a parte che l'Abit da
una pista al Promise con tutto che costi un terzo, i benchmark indicavano in
modalita' stripe il quasi raddoppio del transfer rate dei dischi, che erano
i soliti velocissimi IBM, producendo una banda di 70Mb/s.
Puo' darsi che mi sbagli, se ti interessa vai sul sito e controlla....Adesso
mi vado a rileggere l'articolo sulla Bibb...Ehm su PC Professionale!
:)))))))
Bye
Alberto

 sia la stessa cosa.
Si' si' adesso e' chiaro.....
Bye
Alberto

 l'irq e di conseguenza essere servita.
Si hai ragione credo, e' dello stesso parere anche Massimo. L'unica cosa
positiva che con la penuria che c'e'  di IRQ in questo modo ce ne e' un
altro libero per qualche altro device....
Bye
Alberto

Faccio un esempio che forse chiarira' le cose: il BUS e' come un grosso tubo
No, mi spiace, non e' cosi'... Ora purtroppo devo scappare, appena
posso ti spiego meglio.. Sempre che qualcuno non l'abbia fatto
prima di me :-) 
Simone

 te, naturalmente).
Ma sei proprio patacca. Talmente patacca che non sono riuscito a non
risponderti.
Te ne tiro fuori uno a caso:
http://www.pcguide.com/ref/hdd/if/ide/unstd_Ultra100.htm
l'ultimo paragrafo e sempre sullo stesso sito:
http://www.pcguide.com/ref/hdd/perf/perf/spec/trans_Interface.htm
il quarto paragrafo:
"As I've mentioned before, transfer consists of two steps, internal and
external. For typical transfers, the net speed of the transfer cannot be any
higher than the slower of these two components. Since the external transfer rate
of a drive is usually much higher than its internal sustained transfer rate,
that means that the STR will be the bottleneck, and thus the factor that limits
performance; the high transfer rate of the interface is mostly wasted. As an
analogy, suppose you have a 1/2" garden hose connected to a 3/4" pipe. The 1/2"
segment will be what limits the flow of water; increasing the 3/4" pipe to 1" or
even higher won't make a difference in how much water you get at the end of the
pipe. "

 ha scritto nel messaggio
news:3A81667C...@libero.it...

Scusa il linguaggio, ma o sei bastardo o sei scemo, tre righe più sotto il
discorso continuava così:
There is one area where the interface speed is very important to pay
attention to: you do not want it to be too low or performance will suffer.
If you take the 3/4" pipe mentioned above and reduce its diameter to 1/4",
suddenly it becomes the bottleneck, not the 1/2" diameter hose. If the
interface does not have enough speed to allow the hard disk to run at its
full STR, then performance can be substantially degraded. Since interfaces
are relatively inexpensive this is a situation you generally want to avoid:
instead, upgrade the interface. This issue occurs only when putting a new,
fast drive into a rather old, slow system.
Che è esattamente quello che ho detto io nella mia precedente risposta.
Ma chi vuoi prendere in giro? Cosa credi? di essere l'unico che parla
inglese? O forse non lo capisci e non hai capito che l'1/4" pipe corrisponde
esattamente a UDMA 33, un'interfaccia più lenta del full STR. C'è scritto
"then performance can be substantially degraded". Se in grado di capire cosa
significa? E poi c'è scritto "This issue occurs only when putting a new,
fast drive into a rather old, slow system": ripeto, cosa significa secondo
te?
C'è una cosa che non riesco a capire: perchè ti ostini in modo così polemico
e in malafede soprattuto a difendere un assunto indifendibile? Cosa te ne
viene in tasca? Capirei se stessimo discutendo della tua pensione, o della
demolizione della tua casa abusiva in Sicilia, ma per questo?? Boh, non
capisco proprio e sinceramente mi fai sempre più pena.

posso ti spiego meglio.. 
Eccomi qui. Brevemente. Non puoi paragonare un bus ad un tubo
nel quale circola acqua. E' sbagliato, e sbagliano di conseguenza
tutti quelli che fanno questo paragone. Tralasciando la questione
sulla velocita' "netta" i dati che attraversano la piattina eide (in fondo
il protocollo in questione e' "limitato" a questo percorso, no?) se
viene utilizzato il protocollo ata100, lo fanno piu' o meno proprio a
100MB/sec, perche' questa e' la velocita' del protocollo. Ovvio che
tale velocita' non sara' tenuta che per pochissimi millesimi di 
secondo (se devo trasferire un dato che e' presente nella cache
del disco) ma questo ovviamente e' un altro paio di maniche.
Altra questione. Ok, anche se il trasferimento avviene secondo
il protocollo DMA (richiesta, irq, trasferimento, irq, dato in memoria)
e dato che parliamo sempre di periferiche eide/atapi (fate questa
prova con un cdrom, ad esempio) allora passando da ata66 ad ata100,
pur mantenendo lo stesso disco, ho un'occupazione di cpu minore.
Simone

>>>>>>>>>>>>>>>>>>casa abusiva in Sicilia,<<<<<<<<<<<<<<<<<<<<<<<<<<<
ma per questo? Non li capisco proprio e sinceramente MI FAI SEMPRE PIU' PENA.
Infine, mio Dio, volevo scusarmi per aver occupato con questa discussione il tuo
tempo così prezioso.
Tu sei il Sommo depositario della Verità, ed io, infimo, l'ho dimenticato, e ho
osato contraddirti. Non
succederà mai più. Tu così buono, mi hai indicato la fortuna che ho a possedere
l' ATA-100, ed io,
degno di insulti e di ogni passibile sofferenza, non ho apprezzato il tuo dono.
E' che sembra che non
ci fosse poi molta differenza, ma la mia piccola mente non riuscirà mai a
comprendere i tuoi pensieri.
Nella tua immensa Magnificenza e Misericordia, perdonami e prometto che domani
uscirò subito a
comprarmi il nuovo Pentium 4, che costa un pacco di milioni e sembra che non
vada poi così più
forte di un Athlon overclocckato a 1 Ghz, esigerò un controller SCSI da più di
un milione e dopo
averci attaccato un solo hd godrò dei vantaggi che questo mi offre. Mi impunterò
per avere la nuova
memoria DDR, l'AGP 4x e tutti gli ultimi ritrovati della tecnica che Tu saprai
indicarmi.
Pretenderò anche il Millennium, che è uguale al Win98, ma sono sicuro che tu
saprai mostrarmi tutta la
mia ignoranza e farmi apprezzare tutto questo ben di Dio.
Poi comprerò una tastiera e un mouse con 10.000 che tanto sono tutte uguali, e
siccome ho già speso un
sacco di milioni, lo attaccherò al mio vecchio monitor a 14'' che arriva al
massimo ad 800x600.
Non troverò nessun applicazione che abbia bisogno di tutta questa potenza,
perchè purtroppo la schiera
dei tuoi discepoli e' ancora piccola, e chi produce applicazioni non può
permettersi di richiedere requisiti
così alti, altrimenti nessuno comprerebbe i loro programmi.
Ma non preoccuparti, lo accenderò e ci farò girare ogni tipo di benchmark, e
godrò dei 0.02 secondi di
miglioramento che l'ATA-100 mi ha concesso, e, instancabile, andrò diffondendo
il tuo verbo, finchè ogni
infedele non sarà convertito.
FBF.

 del disco) ma questo ovviamente e' un altro paio di maniche.
Uhmmmmm, no , non mi convinci! Io credo che il protocollo ATA100 di fatto
permetta una banda passante di 100MB/s e non che i dati appena "entrano"
nella piattina vengano schizzati comunque a 100Mb/s! Se no utilizzando un
disco da 1Mb/s otterrei comunque dei giovamenti (seppur minimi) a montarlo
su un controller ATA100 piuttosto che ATA33, e non mi pare che cio'
accada...
No, no, no , non ci giurerei pero' mi sa che e' cosi'..;))
Bye
Alberto

 Massimo
Io ho un DTLA 307045, e con il passaggio da ATA33 ad ATA66 ho ottenuto un
incremento di prestazioni del 7%, da ATA66 a ATA100 NESSUN miglioramento.
A conti fatti il gioco non vale la candela: chi ha una mobo che supporta
solo l'ATA33 se la tenga stretta e non spenda soldi per il controller
ATA100. Allo stato attuale delle cose, la vera differenza la fanno il tempo
d'accesso e la velocita' di rotazione: la maggioranza degli hard disk ancora
non riesce a saturare la banda di un ATA33....
SALUTONI,
WindoM

 SALUTONI,
Per dimostrarti quanto sono d'accordo con te ti allego un estratto da un mio
post in altro thread simile, dove i valori di un benchmark confermano quello
che stai dicendo tu.
-------
Qui ci sono i risultati di un test su mobo Soyo 7VDA con solo 128 MB di RAM,
non ottimizzata per ATA100 (cioè controller ATA100 con driver non
ottimizzati, quelli di Windows in pratica) con disco WD200BB (7200, 2MB, non
è certo come il DTLA, ma insomma) con disco deframmentato ma non si sa
quanto pieno. Nonostante tutto, le differenze tra ATA33 e ATA100 si vedono,
negli indici globali (sul 6%-7%) e specialmente nelle velocità di
trasferimento (circa il 33%).
Le differenze tra ATA66 e ATA100 meno (anche se il primo indice indica
comunque un distacco), però, viste le limitazioni (disco che non è il
massimo dei massimi, driver non ottimizzati) mi sentirei di sospettare
risultati ancora migliori eliminate queste limitazioni (e naturalmente
differenze ancora più sostanziali con ATA33).
Winbench 99
Business Disk
ATA33: 6010
ATA66: 6080
ATA100: 6350
High Disk
 ATA33: 18100
 ATA66: 19100
 ATA100: 19300
Disk Transfer - Beginning
 ATA33: 24200
 ATA66: 32200
 ATA100: 32300
Disk Transfer - End
 ATA33: 24400
 ATA66: 32900
 ATA100: 32900
Cioè, il riassunto secondo me è sempre lo stesso: se uno ha già una mobo
UDMA33 e la vuole cambiare solo per avere ATA100 fa una cosa quasi inutile,
però questo è quasi impossibile, perchè se ha una mobo UDMA33 non credo
abbia un Athlon 1000, RAM PC133 CAS2 e tutto il resto.
Se uno aggiunge sulla UDMA33 un controller ATA100 e lo paga 200.000 lire, fa
una scemenza inutile,
questo è chiaro.
Ma tutto ciò non significa che ATA100 non serve a niente. Serve se lo uso
come deve essere usato: su una macchina potente, con un disco ad alte
prestazioni, con 128 o 256 MB di RAM, se ho i driver giusti (con i primi 4
in 1 io non riuscivo sulla mia A7V ad andare oltre i 10 MB/s in copia
(quindi conta per due), adesso vado a 16/17 MB/s, e anche questo (dei
driver) è un discorso che deve essere affrontato) etc..
Stanno arrivando dischi con densità di registrazione sempre superiori e i
dischi EIDE a 10.000 giri non tarderanno moltissimo, e la differenza si
vedrà sempre di più (come succede sempre in questo campo).
--------------
Ciao
Massimo

 permette (teorica)?
ATA100 permette di trasferire dati tra la cache del disco (generalmente 2MB
sui dischi attuali migliori) e la RAM. E' chiaro che se il dato non si trova
nella cache del disco ma bisogna andare a leggerlo fisicamente sul disco,
allora quello che conta è il transfer rate della testina (sull'ibm ata100
siamo tra i 22 e i 37 MB/s a seconda della traccia, più veloce all'esterno,
meno all'interno (quando il disco è già abbastanza pieno).
Il bus PCI ha un transfer rate massimo di 133MB/s, quindi nettamente
superiore alla velocità dell'UDMA 33 e un po' superiore a quella
dell'ATA100.
Allora cosa si deduce? Che con un disco come il tuo l'UDMA33 è sicuramente
un collo di bottiglia, perchè anche se il valore nominale è 33MB/s in
pratica non può superare mai i 20-25MB/s per varie "dispersioni" (tempi
tecnici e idle vari necessari al suo funzionamento). Inoltre è
un'interfaccia datata, e quindi oltre ai 33MB/s sono proporzionalmente più
lenti anche i tempi di latenza vari.
Diverso sarebbe il discorso con un UDMA66, che offre una banda ampiamente
superiore a quella della testina del disco (max 37 MB/s contro 50MB/s) e
allo stesso tempo è anche realizzata con componenti più recenti e veloci.
Per quanto riguarda l'intera banda e l'intero buffer che tu citi la faccenda
non funziona così: indipendentemente da quanti dischi hai, quando uno
funziona si becca comunque l'intera banda e il buffer è sul disco (la sua
cache) e quindi ce n'è uno per disco.
Conclusione finale: se comperi un controller ATA100 sicuramente avrai dei
vantaggi, ma quando si migliora molto una componente senza migliorare le
altre (CPU, chipset, motherboard, RAM, scheda video, ect.) di solito ci si
ritrova con un sistema sbilanciato e non è così facile vedere in pratica i
miglioramenti, cioè il tuo collo di bottiglia diventa il gruppo chipset-ram
che fatica a star dietro al disco e poi la CPU.
Io mi terrei il tutto così com'è e poi, quando possibile, cambierei
motherboard e CPU portandomi dietro questo ottimo disco.
Ciao
Massimo

incremento di prestazioni del 7%, da ATA66 a ATA100 NESSUN miglioramento.
Scusate se mi intrometto ma avrei bisogno di un vostro parere in
merito ad un problema di transfer rate con un disco identico a quello
su menzionato:
l'ho montato su un pc di un mio amico che ha una MB soltek  (FV 65+)
con controller UDMA 66, e purtroppo le prestazioni non sono quelle che
mi aspettavo. Il test Winbench disk transfer rate da' al massimo 27
MB/S, mentre su una Asus A7V riesco a fare 37 MB/S (che e' il valore
dichiarato dalla casa). L' Hd e' montato e configurato correttamente
 ( cavo 80 fili, connettore celeste sulla MB, l'altra estremita'
sull'hd impostato come master, nessun disco slave , commutato in
modalita' UDMA 66 con l'utility dell'Ibm).  Come S.O ho usato NT 4.0 e
Win98Se, entrambi con gli ultimi driver Via e con il Dma abilitato, ma
niente da fare. Il disco e' praticamente vuoto, solo il S.O
installato, sulla soltek non va, lo collego all'Asus e viaggia che e'
un piacere.
Ho aggiornato anche il bios della Soltek ma la situazione non cambia.
Sinceramente non so piu' che pesci prendere, inizio a pensare a
qualche incompatibilita' con la suddetta MB, ma sul sito non ho
trovato nulla in merito.
Non credo che la MB sia guasta, perche' i dischi Udma 66 riesce a
sfruttarli completamente.
Per caso vi viene qualche idea?
Io oramai sono alla frutta.
Grazie e scusate l'intromissione.
Ciao
Fabio
Per rispondere scambiare lino con maggio

 dichiarato dalla casa).
Non saprei cosa dire, se non che (evidentemente) il controller integrato
nella Soltek non regge il confronto con quello integrato nella A7V...
SALUTONI,
WindoM

 che stai dicendo tu.
Perfetto, allora siamo in sintonia! :-)
SALUTONI,
WindoM

incremento di prestazioni del 7%, da ATA66 a ATA100 NESSUN miglioramento.
http://www.xbitlabs.com/storage/hdd-roundup.html
Fatevi un girettino... interessanti prove di HD dell'ultima
generazione in DMA33, poi un UDMA66, poi in UDMA100
Sim

No, no, no , non ci giurerei pero' mi sa che e' cosi'..;))
Ascolta, il protocollo si chiama ATA100 perche' trasferisce (quasi) a 100MB/sec.
E' come dire che su una rete a 100mbit le trame non passano sempre a 100mbit....
Che il trasferimento non possa essere sempre a 100mbit sostenuto e' un conto,
ma che i dati viaggino a quella velocita... se non lo facessero non staremmo 
usando quel protocollo...
Simone

 generazione in DMA33, poi un UDMA66, poi in UDMA100
Grazie, sono proprio i dati che avrei voluto per dimostrare quanto stavo
dicendo, solo che non sono riuscito a trovarli. Il mio modesto parere è che
confermano in toto la teoria (nonostante ciò che alcuni "esperti" hanno
urlato in modo più o meno osceno) ed il fatto che la situazione cambia
moltissimo da disco a disco (dico, tra l'LCT e il Plus AS in certi indici la
differenza è del 258%!!! a parità di ATA100) e che i dischi più veloci sono
nettamente penalizzati da UDMA33 mentre per l'LCT non fa una gran differenza
perchè è già lento di suo (e via via che le prestazioni aumentano, il
divario aumenta).
Poi, secondo me, si vede anche come certi dischi si comportano in maniera
strana per certi test, evidenziando "incompatibilità" più o meno
inspiegabili o non chiarite tra fw del disco, bios di motherboard, driver
bus master, applicativo, etc., il che apre sicuramente un altro fronte di
incertezza sull'argomento, che rende ancora più assurde le dichiarazioni
dogmatiche (direi staliniane) dei nostri famosi "esperti".
Peccato che nel test non ci fosse l'IBM DTLA, sarebbe stato interessante
vedere come si comportava rispetto al Plus AS e al Seagate Barracuda ATAIII
(anche se è forse penalizzato dall'avere solo 15 GB per piatto contro i 20
GB dei dischi del test).
Grazie ancora per il link.
Ciao
Massimo

 E' come dire che su una rete a 100mbit le trame non passano sempre a
100mbit....
Credo che il discorso nel caso delle reti sia sensibilmente diverso....
Comunque anche se ovviamente c'e' una risposta giusta e una sbagliata a meno
che qualcuno non intervenga credo che ognuno di noi due rimarra' della
stessa opinione...;))))))))
Ciao
Alberto

 stessa opinione...;))))))))
Alberto, mi dispiace per te, ma temo che Simone, anche se in modo sintetico,
abbia detto cose più giuste delle tue.
Il concetto che non mi sembra ti sia del tutto chiaro, è quello della
larghezza di banda: 100 MB/s significa che in un secondo al massimo posso
trasferire 100 MB. Ma come li trasferisco? Ci possono essere infiniti modi
di trasferire 100 MB in un secondo: posso avere un clock di riferimento di
100 Mhz e trasferire 1 byte ad ogni ciclo di clock. In pratica ogni 10 ns
(nanosecondi) parte un byte dalla cache del disco verso il chipset su
motherboard, o viceversa. Oppure posso avere un clock da 50 Mhz e trasferire
2 byte ad ogni ciclo e così via (al limite potrei avere un clock da 12,5 Mhz
e trasferire 8 byte per ciclo, per esempio questo è quello che succede
sull'FSB, dove trasferisco 8 byte ad ogni ciclo, solo che la frequenza è di
100 o 133 Mhz, e mi ritrovo 800 o 1064 MB/s di transfer rate).
Nel caso in questione ho un clock da 50 Mhz, però trasferisco 1 byte sia sul
fronte di salita che sul fronte di discesa (come nelle DDR) e quindi è come
se avessi 100 Mhz. Detto questo, il clock non può cambiare, la strategia non
può cambiare, la larghezza del bus (1 byte) non può cambiare. Allora cosa
succede? Nella cache del disco ho per esempio 2 MB (che per una fortunata
quanto improbabile coincidenza) sono esattamente quelli che devo trasferire
in RAM. Allora il trasferimento parte e dura 2/100 di secondo, cioè 20 ms.
Nel frattempo il disco riempie la cache dall'altra parte, ma lui legge solo
a 37 MB/s. Allora dopo 20 ms avrà riempito solo 0,74 MB e per riempire gli
altri 1,26 MB gli ci vogliono altri 34 ms. Per questi 34 ms sul bus ATA100
non passa niente, poi fa un altro burst da 20 ms e scarica 2 MB. E la
faccenda si ripete fino ad esaurimento del trasferimento. E' chiaro che le
cose non vanno esattamente così, perchè ci sono i famosi tempi di
sincronizzazione, poi non è necessario che tutti i 2 MB siano in cache prima
di partire, ho semplificato solo per spiegare il concetto di velocità di
trasferimento dati. In pratica quando trasferisco dati lo faccio sempre a
100 MB/s perchè sono vincolato dalle caratteristiche del bus (clock e
larghezza), ma se la sorgente dei dati comunque non può fornire dati alla
massima velocità allora per periodi di tempo più o meno lunghi il bus
resterà inutilizzato, e alla fine la velocità media sarà quella della
sorgente.
Con altri test che trasferiscono ripetitivamente piccoli blocchi di dati (64
KB o 128 KB) che stanno all'interno della cache, ecco che si raggiungono
velocità vicine ai 100 MB/s, limitate solo dal famoso overhead dovuto ai
protocolli di sincronizzazione del bus.
Quindi la questione della saturazione di un bus ATA100 per adesso non si
pone assolutamente, perchè comunque anche gli ultimissimi dischi arrivano a
velocità di trasferimento (STR) massime dell'ordine dei 40-45 MB/s, ancora
ben lontane dagli 80-85 MB/s effettivi dell'ATA100.
Per quel che riguarda questa tua osservazione
------
Uhmmmmm, no , non mi convinci! Io credo che il protocollo ATA100 di fatto
permetta una banda passante di 100MB/s e non che i dati appena "entrano"
nella piattina vengano schizzati comunque a 100Mb/s! Se no utilizzando un
disco da 1Mb/s otterrei comunque dei giovamenti (seppur minimi) a montarlo
su un controller ATA100 piuttosto che ATA33, e non mi pare che cio'
accada...
---------
il problema è che se il disco è un UDMA33 (lasciamo perdere 1 MB/s!!), il
controller ATA100 si deve automaticamente adeguare alle sue massime
prestazioni (33 MB/s), e quindi trasferisce i dati ad un terzo della
frequenza. Il vantaggio sarà solo nel fatto che il chipset ATA100 sarà
sicuramente molto più rapido nella fase di riconoscimento/invio del comando
e quindi l'overhead sarà un po' minore, ma stiamo parlando di cose
infinitesime.
Stesso discorso nel caso opposto: collego un disco ATA100 ad un controller
UDMA33 e il disco trasferisce dati a 16,6 Mhz invece che a 50, e quindi
satura il bus se ha un trasfer rate superiore ai famosi 24 MB/s effettivi
dell'UDMA33. In questo caso è il disco che deve aspettare il bus, perchè la
sua cache sarà ancora piena quando lui sarebbe già pronto a metterci gli
altri dati che nel frattempo le testine hanno letto dalla superficie del
disco.
Spero di averti chiarito un po' le idee.
Ciao
Massimo

 Spero di averti chiarito un po' le idee.
Grazie, grazie, adesso e' tutto chiaro, chiedo scusa anche a Simone visto
che aveva ragione lui.
Comunque ho rosicato!! ;)))
Sono sicuro di una cosa: che con queste delucidazioni potro' vincere
parecchie scommessucce anche tra i miei "colleghi" ingegneri...Non avete
idea di quanta gente la pensasse come me riguardo a questa
cosa...:))))))))))))))
Bye
Alberto

 se avessi 100 Mhz.
Scusa il commento ma a quanto dice lo schema dell'ata6 (che si riferisce al
trasferimento a 100 Mb/s) sulla piattina ide ci sono 16 bit per il
trasperimento dei dati , perciò penso siano 2 byte alla volta (sono sia di
inpunt che di output perciò penso vadano in una sola direzzione alla volta )

 inpunt che di output perciò penso vadano in una sola direzzione alla
volta )"?
Il bus è bidirezionale e a seconda se si legge dall'hard disk o si scrive
sull'hard disk, i dati viaggeranno in una direzione o nell'altra.
Il discorso DDR è un'altra cosa: in un ciclo di clock, il segnale di clock
sarà caratterizzato da una parte alta e da una parte bassa, quindi ci sarà
un fronte di salita (segnale che passa da 0V a 5V in TTL) seguito da un
pezzo a 5V (per 20 ns, se la freq. è di 25 Mhz), un fronte di discesa (da 5V
a 0V) seguito da un pezzo a 0V e qui finisce il ciclo clock. Sui bus normali
i dati vengono sincronizzati sul primo fronte (da 0 a 5V) e poi hanno 40 ns
per fare la loro strada. In DDR, un dato è sincronizzato sul primo fronte
(da 0 a 5V) e poi ha solo 20 ns per fare la sua strada e l'altro sul secondo
fronte, con altri 20 ns.
Anche questa volta spero di aver chiarito il dubbio, in caso invece tu
volessi dire un'altra cosa, riposta!
Ciao
Massimo

 cosa...:))))))))))))))
Prego, figurati, perņ adesso mi aspetto una percentuale sulle vincite!
:-)))))))
Ciao
Massimo

 wrote in message
963461$j5tgh$1...@ID-60218.news.dfncis.de...

ehm .. no ... siccome non ho letto molto bene il documento (sono solo 460
pagine) non ero certo che il bus fosse proprio a 16 bit unidirezionale
oppure fosse diviso in 2 da 8 bit in modo di poter fare in contemporanea sia
un'operazione di input che di output , ma ovviamente sbaglio stiamo parlando
di ide in fondo e 2 operazioni alla volta se li sogna ..

Grazie ancora per il link.
Figurati, io per queste seghe mentali teoriche che si
ripercuotono pero' anche sul pratico ci sguazzo... :-)
Sim

stessa opinione...;))))))))
Io piu' che dirti la verita' non so cosa farci, se non ci vuoi credere... :-))
Sim

parecchie scommessucce anche tra i miei "colleghi" ingegneri...
Ehehe... lo dico sempre, diffidate degli ingenieri... :-)) Scherzo! :-))
Simone
PS: guarda il mio email, io non faccio ingenieria, mi mancano 7
esami ed ho finito.... ma a Informatica ;-)

fronte, con altri 20 ns.
Nel QDR (come AGP4X oppure il bus del PIV) ci sono due
segnali sfasati di 90° in DDR; vero?
Sim

 segnali sfasati di 90° in DDR; vero?
Sì, è qualcosa di simile, anche se poi le implementazioni pratiche possono
variare, come puoi vedere leggendo queste specifiche per AGP
(
http://www.agpforum.org/specs_specs.htm
). In pratica, alla fine, qualcuno
deve crearsi un clock interno da 66 Mhz x 4 (AGP4x) o da 100 Mhz x 4 (PIV),
per riuscire a stare sincronizzato con i vari fronti di salita e discesa.
Nel caso di AGP4x c'è il fatto che i segnali di controllo viaggiano sempre
in AGP1x (66 Mhz), mentre i dati vanno in 4x usando questo riferimento
interno, creato con un apposito PLL. Credo che anche per il PIV debbano fare
qualcosa di simile, anche se non ho ancora avuto il tempo di studiare troppo
bene la questione.
Ciao
Massimo