Test prestazionale SerialATA con Native Command Queuing

be certo è che i seagate partono da una meccanica e delle prestazioni di base leggermente migliori.

In ogni caso siamo sempre punto e a capo perche' come anche il raptor inizia a supportare il NCQ fa pure lui un balzo in avanti quindi.......
in ogni caso sembra un'ottima cosa....piu' intelligenza nel controllo e meno forza bruta non puo' che fare bene...

in Primis :condivido tutto ciò che ha detto erpazzo, con un unico appunto ,forse il maxtor non è dei mogliori ma forse non è neanche schifoso data la capacità. L'ultimo che ho preso era un 40GB che frulla ancora, non se quelli successivi fan schifo come affidabilità.

A parer mio NCQ = DEO GRATIAS ,non so se vi siete accorti , è quasi come dire "tecnologia SCSI su disco IDE" e potrebbe migliorare fino a equipararla (a parità di giri).
Come potete notare gli SCSI ai raptor gliene danno ancora di pasta ........senza guardare i 15k.

Per chi dice che è inutile comprare hd piu veloci .....:
A parte che io ho un server Oracle da circa 500 k record per auto-know, il fatto di avere dischi piu veloci (intendo giri\tecnologia e non ATA 100/ata133/SATA) lo noti eccome e in qualunque programma che necessito di quei tot secondi per aprirsi .
In questo momento penso che si possa affermare di spendere 5 volte meglio i soldi per uno SCSI che per comprarsi un A64FX o un prescott nuovi di zecca (e venitemi a dire che gli utonti non lo fanno!!!)

Per Nox : Trovami un disco attuale che spara 150MB/s anche leggendo in sequenza e ne compro 2 (1 per te 1 per me ).
Non diciamo fesserie attualmente SATA150,ATA133 e anche SCSI320 sono quasi inutili a meno del 0,005% delle prestazioni o di config. in raid.
Che poi un produttore abbia lievemente migliorato la meccanica quando ha fatto uscire il suo SATA migliorandolo dell'1% è un altra cosa... poi se ci volete cascare ....cascateci...basta guardare i test del Maxtor 15K SCSI ...intorno ai 75MB/s.
E'un po come mettere un treno a vapore sulle linee ad alta velocità del pendolino/TGV

Forse diventerà lievemente utile l'ATA133 se mettono l'NCQ sui raptor(che sono già su SATA ) in caso di congestioni momentanee dei dati sul disco (per qualche motivo anomalo, BOH)

Azz Cionci che passaggino
INVIDIA

Ops Cionci dopo sto postone pensavo avessi preso il 15K...


Niente INVIDIA

Attenzione, qui nessuno (io per primo) ha mai detto che dischi veloci sono inutili; si è solo fatto notare che a meno che uno debba gestire applicazioni tali da giustificare un sistema di dischi corazzato (vedasi appunto l'esempio del db oracle con miliardi di record), l'acquisto di un raptor è estremamente sproporzionato rispetto alle esigenze medie dell'utente (per quanto possa essere appassionato o 'smanettore').
Che poi, tra i tanti che sembrano voler partecipare alla gare del "io ce l'ho più ", ci possa essere qualcuno che ha queste reali esigenze non lo metto in dubbio.
Anch'io sulle mie macchine in server farm che devono far grattare quantità industriali di db domino tutti indicizzati, con annesso db2 udb, ho degli scsi da 10k e 15k rpm con controller Serveraid...

Tasslehoff, condivido ,non avevo piu voglia di scrivere ieri...

Il fatto che volevo far notare è che ci sono utonti che acquistano processori da 500€ e HD da 80€ ,mentre ora come ora se si fa l'inverso penso che il PC ottenga prestazioni migliori anche per utilizzi da utonto.
Questa cosa è anche spinta dalle catene.
E penso che più andiamo avanti (il disco farà sempre più da collo) più varrà la regola da me citata.
Nulla da dire a chi si compra una CPU da 100€ e un disco da 80€ poiché coscente delle proprie necessità, anzi sui PC su commissione che facevo tendevo a consigliare conf di questo tipo (di solito persone che usavano il PC per la prima volta)

Hanno installato Lotus da me ,sono curioso, mi dici quanto ciuccia di risorse Domino con un tot di utenti BOh.

Secondo me non è nulla di nuovo!!!!!!!Gli algoritmi dell'ascensore sono vecchi come me...e sono 3: 1)SSTF(Shortest seek time first) prende la traccia più vicina
a quella dove sitrova. 2)SCAN(politica dell'ascensore ed evoluzione di SSTF)La selezione viene fatta basandosi sul tempo di seek minore , mantenendosi però nella direzione corrente della testina, che non viene cambiata fino a quando non si raggiunge l'estremità della superficie del disco.3)La C-Scan francamente non me la ricordo.

Pienamente d'accordo, pensa che proprio ieri sera ho fatto un'offerta ad un parente che voleva un laptop, esigenze: navigare, usare office e posta elettronica.
Gli propongo un celeron (ovviamente thinkpad) e mi sento rispondere che pensava almeno ad un P4...
non faccio commenti...

Eh dipende parecchio da che uso ne fai, come server di posta per es a me con 160 utenti circa con mailbox notes, domino web access (le nuova webmail della ver 6.5, obbiettivamente la migliore webmail che tu possa trovare sul mercato), server ldap e ovviamente http server, occupa circa 350MB di ram complessivamente di media, compreso anche il servizio di indicizzazione dei db.
Dal pdv di un web & application server invece tieni presente che su un xSeries 345 con 2 GB di ram e 2 xeon da 3Ghz sguazza tranquillo e beato uno dei più grossi portali della PA lombarda, con una media di 18000 accessi unici giornalieri e una schiera di qualche centinaio di redattori che ci lavorano dietro.

Quando faranno dei test con hd aventi la STESSA meccanica, ma con interfaccia diversa (SCSI, SATA, PATA), ne riparliamo.

Condivido l'intervento.

Inoltre, parlando di database, alla resa dei conti risulta di gran lunga più critico il disegno fisico dei dati che non la potenza dei dischi che stanno sotto.

E' ovvio che dischi potenti possono ovviare ad un design del data model non particolramente efficace, ma alla lunga le prestazioni saranno sempre non ottimali e comunque un fattore di criticità sempre maggiore.

Io non conosco Oracle, ma conosco bene DB2 UDB, e posso assicurare che vi sono (specie con la versione 8.1) una serie di regole per l'allocazione dei tablespaces, dei loro containers e dei bufferpool associati che non sono uno scherzo.

Ho visto applicazioni prendere letteralmente il volo, una volta ridisegnati i tablespace ed i buffer.

Non dimentichiamoci poi di un'altra attività critica di ogni DBMS che gratta non poco i dischi: il logging. Anche lì, ci sono mille e mille accorgimenti per ottimizzare l'accesso del logger ai dischi.

clap clap clap clap clap
come sempre recensioni ai massimi livelli
stupendo
mi sto stampando le pagine..ihhihhihi