Newsgroup: it.lavoro.informatica
Titolo: [ot] velocità di lettura del disco

E' giusto questo ragionamento ?
In rete LAN viaggio a 100Mbps  , per cui se chiamo un file di excel  via 
rete ci metto X secondi ad es.per aprirlo .
In locale la velocità di interrogazione del disco fisso quant'è ?
Dicono 400 Mbps circa , per cui ci dovrei mettere circa  x\4 secondi per 
aprire\consultare lo stesso  file di excel in locale.
Ciao e grazie .

 E' giusto questo ragionamento ?
sbagliato.


Ovviamente no, perché sulla LAN i Mbps comprendono tutti gli overhead 
dei protocolli che ci viaggiano sopra (e se è il TCP/IP, ce ne sono un 
bel po' di overhead...), mentre dal disco leggi soltanto il file.
Cordiali saluti
-- 
Marco Ermini
http://www.markoer.org
http://www.marcoermini.com/

 aprire\consultare lo stesso  file di excel in locale.
Quando fai click sull'icona di un file Excel per aprirlo, il grosso del 
tempo che passa il computer lo usa per avviare il programma Excel e per 
elaborare il file e visualizzarlo sullo schermo; leggerle materialmente i 
dati è solo una piccola parte del problema.
In ogni caso, poi, quando accedi ad un file via rete lo stai comunque 
leggendo dal disco di un altro computer, quindi i 100 MBps sono condizionati 
sia dall'occupazione della rete che dalla velocità con cui l'altro computer 
riesce a leggere i propri dati e a spedirteli, oltre che, ovviamente, dal 
carico che c'è sul server in quel momento.
Infine, il tuo disco locale può avere velocità molto differenti a seconda 
del tipo di controller e del tipo di disco; 400 Mbps comunque non mi risulta 
li abbia mai toccati nessuno, i più veloci dischi SCSI in commercio, quelli 
usati sui server, arrivano al massimo (teorico) a 320; il disco IDE di un 
normale computer client si posiziona un bel po' più in basso nella 
classifica.
Massimo

 quelli usati sui server, arrivano al massimo (teorico) a 320
ma sono MByte  oppure Mbps  ?
ciao 

 non mi risulta li abbia mai toccati nessuno,
Sei rimasto indietro!
Ecco i risultati di alcuni test, molto poco scentifici ma comunque 
indicativi, che ho fatto utilizzando alcune macchine apple e scrivendo 
un file di una data lunghezza. Testo la velocità di scrittura, compresa 
l'efficienza del file-system. Notare che non sono test diretti della 
velocità di trasferimento in quanto la "crescita" del file implica 
letture/scritture multiple dei metadati del filesystem. Il file system è 
sempre quello journaled di Mac OsX tranne quando indicato. Velocità 
espresse in milioni di bit al secondo di velocità media di scrittura 
vista dall'applicazione.
Accesso a singolo SATA interno (maxtor) con un G5: 492 Mb/s
Idem ma G5 server e accesso da pBook via ethernet gigabit: 484 Mb/s
Accesso a RAID 0 su due SATA interni (maxtor) con un G5: 983 Mb/s
Idem ma G5 server e accesso da pBook via ethernet gigabit: 500 Mb/s
Idem ma ethernet 100 Mb/s: 87 Mb/s
Idem ma wireless: 13 Mb/s
Accesso a disco esterno firewire 800 con un G5: 381 Mb/s
Idem ma G5 server e accesso da pBook via ethernet gigabit: 361 Mb/s
Idem ma ethernet 100 Mb/s: 87 Mb/s
Accesso ad un disco firewire400/USB2 via firewire400: 319 Mb/s
Stesso disco ma via USB 2.0: 149 Mb/s
Stesso disco, sempre via USB 2.0 ma file system FAT: 92 Mb/s
Accesso a disco interno del PowerBook: 270 Mb/s

 Sei rimasto indietro!
Temo di aver confuso megabyte con megabit :-)
Massimo

 aprire\consultare lo stesso  file di excel in locale.
Beh, se il transfer rate di un disco fosse di 400 Mbit/s, sarebbe
tanto, ma tanto, ma tanto lento.
-- 
Ciao!
Luca

 po' più in basso nella classifica.
A parte che oggi come oggi hanno ottimi transfer rate anche i dischi
SerialATA (ci son rimasto di sale), aggiungo una cosa che a mio avviso
non è irrilevante. Il transfer rate di una rete si misura in Mbit/s,
non in Mb/s, e son comunque abbastanza teorici; il che implica che,
tolti incapsulamenti vari, se prendi il transfer rate teorico della
rete e lo dividi per 15 grosso modo sei alla velocità in Mb/sec della
rete. Ribadisco, comunque, si tratta di una velocità mooolto teorica.
-- 
Ciao!
Luca

 un bel po' di overhead...), mentre dal disco leggi soltanto il file.
Emh.... incapsulamento e overhead sono due concetti parecchio
differenti... ;-)
-- 
Ciao!
Luca

 ha scritto nel messaggio 
news:e3hhgh$ego$1...@area.cu.mi.it...

Beh, che l'incapsulamento *provochi* overhead mi pare innegabile, però ;-)
Massimo

 rete e lo dividi per 15
cioč consideri che  15 bit  fanno un byte , giusto? 

 aprire\consultare lo stesso  file di excel in locale.
Giusto per precisare: le interfacce Serial ATA permettono transfer rate 
di 3 Gbyte/sec, ma anche i meno performanti Parallel ATA arrivano a 133 
Mbyte/sec. Quindi prestazioni di 1/2 ordini di grandezza superiori.
Basta fare una provettina stupida per farsene un'idea. Prendi un file di 
una certa dimensione e lo copi, prima sulla stessa macchina e poi su 
un'altra macchina in rete.

 cioè consideri che  15 bit  fanno un byte , giusto? 
Non tirare conclusioni balorde.
Sta parlando di transfer rate.

 Sta parlando di transfer rate.
Beh, pero' non ha detto una bischerata grossa. Conti fatti a spanne
dicono che per ricevere un byte devi movimentare sulla rete, con
protocollo di alto livello, mediamente una quindicina di bit. E' una
cosa molto empirica, sia chiaro, però in base a misure fatte è una
buona approssimazione.
-- 
Ciao!
Luca

 ;-)
Si e no. Mi spiego.
In qualche maniera overhead implica spreco di risorse inutili a causa
di ridondanza. Se hai presente lo stack OSI/ISO (superato nei fatti ma
da un punto di vista scolastico interessante) scopri che di sprechi non
è che ce ne siano poi tanti.
Ciò a livello generale, ovviamente. Se poi mi vieni a dire che per
movimentare un singolo byte c'è bisogno di un datagram intero, allora
la questione cambia (ma mi pare non fossimo arrivati a questo livello
di dettaglio).
-- 
Ciao!
Luca

 rete. Ribadisco, comunque, si tratta di una velocità mooolto teorica.
Giusto, quindi basata sul principio che sullo stesso canale non ci sia 
altro traffico. Il che significa sia che la rete sia fatta bene (almeno 
che le due macchine siano collegate direttamente allo switch, il che non 
lo darei per scontato) e che le stesse macchine non generino altro 
traffico di rete di altro tipo.

 grandezza superiori.
Mi permetto di completare (giusto per dare un quadro ancora più
generale). Il tr è sempre una misura assai teorica, perché tiene conto
sempre di 'quanta acqua può passare per il canale' ma non tiene conto
di 'quanta acqua è disponibile'; in realtà, vi sono parecchi fattori
che influenzano le performances di trasferimento di un disco
(frammentazione, rapporto fra spazio occupato e spazio libero sul
disco, dislocazione dei files, dimensione dei files). Gli attuali
sistemi di caching hanno ovviato parecchi di questi problemi,
avvicinando (ma non rendendo uguali) le due misure.
-- 
Ciao!
Luca

 generino altro traffico di rete di altro tipo.
Grande verità. Ma mi sa che ci stiamo addentrando troppo... ;-)
-- 
Ciao!
Luca

 sbagliato.
Scusi signore ,ma lei non è un po' troppo sintetico ? 


era una tema ? :-P

 rete. Ribadisco, comunque, si tratta di una velocità mooolto teorica.
Occhio però che ci sono grosse differenze a seconda della velocità. Su 
una etherent 100Mb è più facile avvicinarsi ad avere 2 stream da 50 o 4 
da 25 che uno da 100. E le cose peggiorano se sei in gigabit. E ancora 
di più se fra sorgente e destinazione hai un paio di router (= maggior 
latency).
Sono limiti intrinseci al TCP (e anche per questo il TCP è stato più 
volte esteso ed aggiornato e i sistemi moderni non usano praticamente 
più nulla di meno di un Vegas).

 
Guarda che fino a pochi anni fa non ci si arrivava.
E anche oggi non è che sia poi molto ma molto più veloce.
Direi che un buon SATA in scrittura potrebbe arrivare fra i 500 e i 600.

 Mbyte/sec. Quindi prestazioni di 1/2 ordini di grandezza superiori.
Quello è il transfer rate dell'interfaccia. Non quello del disco, che è 
MOLTO inferore.