Da MSI lettore combo Serial-ATA

[sinadex]

ma perchè serve il ncq per un lettore ottico?

[DioBrando]

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)...

[cdimauro]

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 ) potrebbe dare conferma/smentire?

CIAO!

E' esattamente quel penso io...

[cdimauro]

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...

[Ginopilot]

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.?

[cdimauro]

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.

[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.

[Ginopilot]

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

[cdimauro]

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. )).

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!

[Ginopilot]

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.

[cdimauro]

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...

[Ginopilot]

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.

[cdimauro]

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?

[shodan]

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!

[cdimauro]

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.

[shodan]

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

Grazie!

[cdimauro]

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

Grazie!

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

[shodan]

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


CIAO!