Link alla notizia: http://news.hwupgrade.it/12836.html

MSI annuncia il primo lettore ottico CD/DVD con interfaccia Serial ATA. Certificato solo per Southbridge ICH5

Click sul link per visualizzare la notizia.

Speriamo che presto tutti i dispositivi ottici passino al Serial ATA, come anticipato da Plextor col suo masterizzatore DVD 12X.
Più che una questione di banda, si avrebbe finalmente un bus più efficiente (l'EIDE da questo punto di vista fa schifo), oltretutto con cavi di segnale e di potenza più piccoli e ordinati.

pero' strano che sia cosi' lento in scrittura!

Le nuove schede madri dovranno avere piu' di due attacchi S-ATA.

ciao ciao

Originariamente inviato da gnoppi
Speriamo che presto tutti i dispositivi ottici passino al Serial ATA, come anticipato da Plextor col suo masterizzatore DVD 12X.
Più che una questione di banda, si avrebbe finalmente un bus più efficiente (l'EIDE da questo punto di vista fa schifo), oltretutto con cavi di segnale e di potenza più piccoli e ordinati.

é probabile che è compatibile solo con i chip intel.


La compagnia taiwanese Micro-Star International, ha annunciato il primo lettore di DVD e CD di tipo Serial ATA con supporto alla tecnologia NCQ (Native Command Queuing):

Il modello XA52P è dotato delle seguenti caratteristiche tecniche:

* Lettura CD-R a 52x, DVD-ROM a 16x;
* Interfaccia Serial ATA;
* PIO Mode 4, DMA Mode 2, UDMA Mode 2;
* Buffre di 2MB;
* Supporto per media da 870 MB ed 800 MB CD-R;
* Supporto Mount Rainer;
* Installazione anche in verticale;
* Disc-at-Once, Track-at-Once, Session-at-Once, Multisession, Packet Writing, RAW Mode;
* Dimensioni pari a 145.8x41.4x170.8mm;
* Peso pari a 1.0kg.


Da notare, comunque, che MSI parla di compatibiità del suo prodotto con i soli chipset Intel 875P / 865PE / 865G / 865GV / 865P / 848P e non con controller SATA PCI. Il DVD-ROM è compatibile RPC-II, cioè sono possibili solo 4 cambi del "regional code".

Fonte: Digit Life

Originariamente inviato da KAISERWOOD
é probabile che è compatibile solo con i chip intel.


La compagnia taiwanese Micro-Star International, ha annunciato il primo lettore di DVD e CD di tipo Serial ATA con supporto alla tecnologia NCQ (Native Command Queuing):

Il modello XA52P è dotato delle seguenti caratteristiche tecniche:

* Lettura CD-R a 52x, DVD-ROM a 16x;
* Interfaccia Serial ATA;
* PIO Mode 4, DMA Mode 2, UDMA Mode 2;
* Buffre di 2MB;
* Supporto per media da 870 MB ed 800 MB CD-R;
* Supporto Mount Rainer;
* Installazione anche in verticale;
* Disc-at-Once, Track-at-Once, Session-at-Once, Multisession, Packet Writing, RAW Mode;
* Dimensioni pari a 145.8x41.4x170.8mm;
* Peso pari a 1.0kg.


Da notare, comunque, che MSI parla di compatibiità del suo prodotto con i soli chipset Intel 875P / 865PE / 865G / 865GV / 865P / 848P e non con controller SATA PCI. Il DVD-ROM è compatibile RPC-II, cioè sono possibili solo 4 cambi del "regional code".

Fonte: Digit Life

è probabile "CHE SIA" :p :)

... che pian piano soppianteranno quelli su bus UDMA, i produttori di chipset si dovranno dare una mossa per implementare il supporto a più porte SATA.

Almeno 6 o 8

Bye

Posso fare una domanda?
Se il serial ata ha una bandwidth cosi alta e performante e' possibile che in futuro sia implementata come una porta USB o FireWire esterma, magari per periferiche che necessitano di alimentazione da rete come masterizzatori o HD?
Sarebbe comodo collegare un raid esterno al server con solo qualche cavetto.

E' gia disponibile un bay enermax che tra le altre cose ha 2 porte s-ata esterne.
C'è una rece nella sezione modding...
Ciao.

Anzi, addirittura un Barebone ha l'attacco sata esterno.

Comunque :( se è compatibile (certificato) solo per intel.

Va beh, è certificato intel, se lo tengono, io non lo compro ;)

la mia mobo, una Gigabyte Sinxp con SiS655 (quindi non recentissima, ha 2 anni) ha la staffa per connettere unità sata esterne. Credo che ce l'abbiano anche tutte le altre gigabyte di fascia alta.

Un prodotto inutile come inutile e' la transizione a sata, che ha l'unico vantaggio di avere cavi sottili ma molto piu' fragili e delicati dei pata. Il bus ha vantaggi irrilevanti rispetto al pata in generale per tutte le periferiche, ma per questo tipo il vantaggio e' proprio inesistente. Un altro inutilware insomma.

Era anche ora che qualcuno si decidesse a farlo.... SATA & NCQ è un'accoppiata vincente anche e sopratutto per i drive ottici... Cavi più piccoli, pratici e sottili (= maggiore semplicità di montaggio, più ordine nel case e meno ostacoli alla circolazione dell'aria), mentre il CNQ quando sarà sfruttato a dovere porterà a tangibili miglioramenti senza bisogno di aumentare i regimi di rotazione delle unità!!!!

era ora che si iniziasse, ma non capisco perchè sia compatibile solo coi chipset intel...:confused:

Sono gli unici a supportare il NCQ, attualmente...

Imo inutile...cmq prima o poi sarebbe successo

Ciao a tutti, vorrei avere un'informazione... la tecnologia NCQ ha bisogno di driver apposta? In pratica, se mondo un chipset e un HDD che la supportano utilizzando come s.o. linux, avrò bisogno di un driver IDE che prevede il supporto alla tecnologia NCQ oppure andranno bene i driver che sono già in circolazione (visto che per l'ICH6 mi sembra che non ci sia ancora nulla, i driver che ipotizzo utilizzabili sono quello IDE generico e quello IDE specifico per gli ICH, che per il momento arrivano fino alla versione 5)?

Grazie a tutti! :)

Mi riferisco a tutti quelli che non sanno altro che dire "inutile" semplicemente perchè non hanno idea di cosa sia il serial-ATA.
Cmq con il serial-ATA II non dovrebbe esserci bisogno di tante porte ... si potranno mettere periferiche tipo masterizzatori e lettori etc.. in serie sullo stesso canale a condividere la banda, tanto mica la sfutterebbero.

L'unico vantaggio è il cavo meno ingombrante. Per il resto non co sono vantaggi.

Originariamente inviato da shodan
Ciao a tutti, vorrei avere un'informazione... la tecnologia NCQ ha bisogno di driver apposta? In pratica, se mondo un chipset e un HDD che la supportano utilizzando come s.o. linux, avrò bisogno di un driver IDE che prevede il supporto alla tecnologia NCQ oppure andranno bene i driver che sono già in circolazione (visto che per l'ICH6 mi sembra che non ci sia ancora nulla, i driver che ipotizzo utilizzabili sono quello IDE generico e quello IDE specifico per gli ICH, che per il momento arrivano fino alla versione 5)?

Grazie a tutti! :)
NCQ ha bisogno di driver appositi, per cui anche sotto Linux per utilizzare questa caratteristica ti dovrai attrezzare.

Rimango, comunque, dell'idea che parte della tecnologia NCQ sia implementabile via software, a livello di s.o. e driver, e quindi per qualunque chipset e hd...

Originariamente inviato da cdimauro
NCQ ha bisogno di driver appositi, per cui anche sotto Linux per utilizzare questa caratteristica ti dovrai attrezzare.

Rimango, comunque, dell'idea che parte della tecnologia NCQ sia implementabile via software, a livello di s.o. e driver, e quindi per qualunque chipset e hd...

Già, probabilmente è così... credo infatti che già il s.o. potrebbe far molto organizzando in modo logico le richieste e accodandole secondo una logica simile a quella dell'NCQ. Qualcuno più espero di me (non ci vuole molto :p) potrebbe dare conferma/smentire?

CIAO! :)

ma perchè serve il ncq per un lettore ottico?

cmq n è detto che questo prodotto arrivi mai da noi.

Andando a vedere per es sul sto della MSI ci sn tante cose che non vengono proprio prese in considerazione dai grossi distributori italiani perchè fondamentalmente non hanno mercato ( o cmq un mercato non abb rilevante)...

Originariamente inviato da shodan
Già, probabilmente è così... credo infatti che già il s.o. potrebbe far molto organizzando in modo logico le richieste e accodandole secondo una logica simile a quella dell'NCQ. Qualcuno più espero di me (non ci vuole molto :p) potrebbe dare conferma/smentire?

CIAO! :)
E' esattamente quel penso io... ;)

Originariamente inviato da sinadex
ma perchè serve il ncq per un lettore ottico?
Per lo stesso motivo per cui serve per gli HD: ridurre il seek-time per soddisfare le richieste. E su un lettore ottico questo fattore è ancora più critico che con gli hd: generalmente hanno seek-time di un ordine di grandezza superiore rispetto a questi ultimi...

La gestione delle code esiste da sempre in scsi e i lettori come i masterizzatori non ne hanno mai tratto alcun beneficio. Discorso ben diverso per gli hd. Ma chi ha messo in giro fesserie cosi' grosse? Qualche rivista tipo pcprof.?

Sono opinioni personali, non le ho lette da nessuna parte. Mi spieghi perché i lettori non potrebbero trarne beneficio? Con un seek-time sui 100-150ms, rispetto agli 8-13ms degli hd, mi sembra che il problema sia anche più rilevante.

Perche' il miglioramento delle prestazioni che da il riordinamento delle code non influisce sul seek. Al massimo se hai piu' richieste contemporanee al disco permette di ottimizzarle. Ma in genere su un cdrom non hai piu' accessi contemporanei e cmq provocherebbero un sensibile rallentamento. Mai provato a copiare due file contemporaneamente da un cd? Con il ncq dovresti avere un piccolo miglioramento in questo caso. Nell'uso normale il miglioramento non c'e'. Mentre negli hd dove gli accessi contemporanei sono differenti e in diverse zone del disco, il ncq puo' dare grossi vantaggi. Del resto il grosso vantaggio di scsi fino ad ora era proprio in questo senso. E' da vedere la qualita' di questa implementazione.

Il discorso di un ncq software invece credo sia da scartare. Vorrebbe dire carico maggiore sulla cpu in caso di molti accessi contemporanei.

Originariamente inviato da Ginopilot
Perche' il miglioramento delle prestazioni che da il riordinamento delle code non influisce sul seek. Al massimo se hai piu' richieste contemporanee al disco permette di ottimizzarle. Ma in genere su un cdrom non hai piu' accessi contemporanei e cmq provocherebbero un sensibile rallentamento. Mai provato a copiare due file contemporaneamente da un cd? Con il ncq dovresti avere un piccolo miglioramento in questo caso. Nell'uso normale il miglioramento non c'e'. Mentre negli hd dove gli accessi contemporanei sono differenti e in diverse zone del disco, il ncq puo' dare grossi vantaggi. Del resto il grosso vantaggio di scsi fino ad ora era proprio in questo senso. E' da vedere la qualita' di questa implementazione.
OK, adesso è chiaro. :) Dal punto di vista statistico hai indubbiamente ragione: col CD-Rom difficilmente si effettuano contemporaneamente accessi a più file/zone del supporto (io sono un caso a parte, ma sono irrilevante statisticamente. :D)).
Il discorso di un ncq software invece credo sia da scartare. Vorrebbe dire carico maggiore sulla cpu in caso di molti accessi contemporanei.
Non credo che gestire una banale lista concatenata degli accessi sia un'operazione che porti via tanto tempo a una cpu, anzi! :)

Ancor piu' banale sarebbe il raid, utilizzato massicciamente ormai in "hw" anche se in realta' tutte le operazione sono a carico della cpu e i vantaggi sono praticamente nulli o addirittura negativi in quasi tutte le condizioni. Non e' una cosa banale la gestione delle code e a meno di trucchi strani dovrebbe caricare notevolmente la cpu, un po' come avveniva quando non c'era la modalita' dma.

Considera che già di suo un kernel preemptive implementa delle code (più d'una) con priorità per gestire i processi e i thread: non è che il tempo richiesto sia notevole, anzi. Secondo me l'NCQ via software sarebbe fattibile, e con un leggerissimo impatto a carico della CPU. Comunque, rimarranno tutte fantasie finché qualcuno si prenderà la briga di mettere in pratica quanto teorizzato... :p

Se fosse fattibile sarebbe gia' stato fatto qualche esperimento. Credo che le code vadano gestite a livello di controller perche' con il dma i dati non passano dalla cpu, quindi servirebbe un ulteriore flusso di dati verso la cpu per analizzarli. Non sono un programmatore, ma ho paura che questo vanificherebbe i vantaggi dell'accesso dma.

No, l'unico "intoppo" è dovuto al fatto che la CPU deve aspettare la fine di ogni operazione, per poi programmare la successiva. Ma in fin dei conti è quel che fa già adesso, senza NCQ: soltanto che per quest'ultimo, pensa a tutto il controller.
Non so perché non è mai stato fatto, ma sarebbe ora che qualcuno ci provasse, no? :)

Ciao a tutti,

una domanda: se non sbaglio per implemtare una qualche forma di NCQ software la CPU dovrebbe conoscere, quando viene richesto l'accesso ai dati, la posizione in termini di cilindro/settore dei deti stessi in modo da poterli ordinare in sequenza. Questa informazione la prende dal filesystem, vero?

CIAO! :)

Non è il filesystem che, generalmente, fornisce queste informazioni. Anzi, in teoria un fs non dovrebbe MAI fornire informazioni di così basso livello, che sono di dominio dei driver e che poi alle applicazioni non dovrebbero assolutamente interessare (le "penne" USB, ad esempio, non hanno fisicamente testine, tracce, settori, ecc.).

Comunque, per implementare questa parte di NCQ via software penso che non serva operare a livello di fs, ma di driver, appunto, perché permette di conoscere queste informazioni per ordinare meglio le chiamate. Utilizzando il solo LBA si potrebbero già ottenere dei buoni risultati, ma non si potrebbero sfruttare, ad esempio, alcuni "trucchetti", come cercare di non cambiare la testina (visto anche questa operazione porta via del tempo) fin quando è possibile.

Ciao cdmauro,

grazie per le info.

Quindi un fs non ha mai informazioni circa la posizione fisica dei dati sul HD? Però se fosse così, chi è che si occupa di "legare" tra di loro il nome logico di un file con i settore che realmente lo contengono? Mi rendo conto di essere OT, però in materia sono abbastanza digiuno :p

Grazie!

Originariamente inviato da shodan
Ciao cdmauro,

grazie per le info.
Di niente. :)
Quindi un fs non ha mai informazioni circa la posizione fisica dei dati sul HD?
Generalmente no.
Però se fosse così, chi è che si occupa di "legare" tra di loro il nome logico di un file con i settore che realmente lo contengono?
Sono i driver che hanno questa "visione" a più basso livello, e che permettono di farlo. Comunque non hanno alcuna nozione file: questa ce l'ha solamente il fs, che si occupa di gestire a più alto livello file, directory, i cluster da essi utilizzati, ecc.
Il driver viene usato "rozzamente" per sapere quanti settori ha il dispositivo che gestisce, la loro dimensione, e per fornire l'interfaccia di lettura e scrittura di essi al fs.
Hanno compiti diversi e ben definiti.
Mi rendo conto di essere OT, però in materia sono abbastanza digiuno :p

Grazie!
Nessuno nasce "imparato", non ti preoccupare. Se hai bisogno di altri dettagli, chiedi pure. :)

Nessuno nasce "imparato", non ti preoccupare. Se hai bisogno di altri dettagli, chiedi pure. :)

Ti prendo in parola! ;) Quando avrò bisogno di qualche parere, troverai un PVT
:sofico:

CIAO! :)