In che modo un disco rigido può essere un collo di bottiglia durante la masterizzazione di un CD o DVD?


2

Mi sono sempre chiesto perché le persone continuano a incolpare i dischi rigidi di causare buffer underrun durante la masterizzazione di un CD o DVD. Ho letto molte persone che dicevano di usare un disco rigido più veloce o di assicurarsi di deframmentarlo o qualcosa del genere prima di masterizzarlo.

Non ha senso per me. Non mi importa quanto velocemente si masterizza un disco, il throughput e la velocità dei dati di un disco rigido è sempre sta per essere più veloce di qualsiasi unità ottica. (Sto parlando di spinning drives, non ci preoccuperemo nemmeno di SSD!)

Ad esempio, la masterizzazione di un CD a 52x richiederebbe un flusso di dati di 7,6 Mbps. Anche un disco rigido lento (PIO2) dovrebbe essere in grado di tenere il passo (8,3 Mbps), per non parlare di qualsiasi unità UDMA (UDMA0 può gestire 16,7 Mbps) in grado di fornire facilmente un flusso costante.

La masterizzazione di un DVD anche con l'attuale 24x più veloce richiederebbe solo circa 32 Mbps, tuttavia un sistema che dispone di tale unità avrebbe sicuramente un disco rigido che è ordini di grandezza più veloce (SATA1 può fare fino a 150 Mbps, quindi anche un'unità ridicolmente frammentata dovrebbe essere abbastanza veloce).

Anche un disco Blu-ray richiede solo 54 Mbps che può fornire anche un disco rigido IDE ATA66 miseramente.

E quelle velocità dell'unità ottica sono le velocità ottimali di lettura ; le velocità di masterizzazione effettive sono in genere leggermente più lente!

Va bene, ammetto che i tempi di ricerca svolgono un ruolo e che la frammentazione aumenta i tempi di accesso, ma anche in questo caso, a meno che l'unità non sia classificata a malapena al di sopra della velocità di masterizzazione del disco (ad es. 8,3 Mbps di un PIO2 su un CD-R 52x 7.6MPbs = solo 716.8KBps più veloce), quindi le differenze dovrebbero essere abbastanza grandi da rendere irrilevanti anche i tempi di accesso (ad esempio, 150MPb di un'unità SATA1 su 32MP di un DVD 24x = 118 Mbps più veloce!)

Quindi qual è il problema? Perché le persone continuano a sottintendere che i dischi rigidi sono il collo di bottiglia durante la masterizzazione di dischi ottici? Quale potrebbe essere la causa del problema e perché il LED di attività dell'unità diventa sempre fisso quando il software di masterizzazione inizia a leggere il disco rigido anche se il trasferimento di un file gigante normalmente causa solo uno sfarfallio?

Risposte:


3

Ci sono un certo numero di cose chiave che significano che un disco rigido può essere la ragione dietro un buffer in esecuzione.

  1. Il disco rigido utilizzato per utilizzare i cavi IDE, il che potrebbe significare che su un cavo sono stati copiati dei dati dal disco rigido e quindi scritti sul disco CD / DVD. Ciò dimezzerebbe efficacemente la larghezza di banda disponibile da o verso ciascun dispositivo. Mentre questo è cambiato con SATA, c'è ancora contesa nel controller del bus SATA. Questo porta al mio secondo punto

  2. Potrebbero esserci programmi che provano a fare le cose allo stesso tempo, un altro programma che legge o scrive qualsiasi quantità sostanziale di dati può limitare nuovamente la larghezza di banda a uno dei dispositivi in ​​modo simile al primo punto. Una lettura sequenziale eccessivamente ampia potrebbe bloccare completamente l'I / O del disco rigido per secondi o più.

  3. Poiché la memoria del sistema operativo è insufficiente, sarà necessario eseguire il paging di altri programmi da o verso il disco, causando letture o scritture sequenziali di grandi dimensioni nel file di paging che possono bloccare l'I / O come al punto 2.

Tutte queste cose significano che qualsiasi larghezza di banda teorica di picco che pensi di avere non è sempre disponibile.

Il problema si presenta quando il tuo masterizzatore CD deve assolutamente garantire la larghezza di banda tra il disco rigido e il CD-ROM, se tale larghezza di banda è ridotta alla fame per più di un secondo o due (la dimensione tipica del buffer su un masterizzatore CD), quindi un buffer underflow si verificherà. I programmi o il sistema operativo che richiedono l'uso del disco rigido sono sufficienti per interrompere il flusso di dati verso il masterizzatore per il tempo necessario a far sì che ciò accada.

Il motivo principale per cui raccomandiamo dischi rigidi sostanzialmente più veloci per prevenire le esecuzioni del buffer è perché un'unità più veloce sarà in grado di superare l'I / O di blocco molto più velocemente e tornare all'attività di lettura dei dati da inviare al CD- scrittore.

- = = EDIT -

Hai ragione sul fatto che molti utenti inesperti avrebbero un gran numero di applicazioni "helper" (RealPlayer, quickstarter e altre applicazioni quasi-malware assortite), il che significa che c'era meno memoria disponibile. I sistemi per utenti domestici meno recenti in genere disponevano solo di memoria sufficiente per il sistema operativo e un programma o due per essere eseguiti comodamente, aggiungere tutti i programmi inutili di immondizia e il software di scrittura su CD che necessitava di un buffer di grandi dimensioni e di "comode" quantità di memoria diventare decisamente a disagio.

Si noti inoltre che il software antivirus può anche avere un impatto sulla larghezza di banda del disco rigido in quanto devono eseguire la scansione di ogni bit di dati provenienti dal disco rigido. Liberare risorse chiudendo quei programmi e cancellando il sistema in genere permetteva al masterizzatore di continuare il proprio lavoro.

La cosa principale che rende effettivamente un sottotitolo una cosa da evitare a tutti i costi è stato il modo in cui il masterizzatore scrive effettivamente sul disco. Il laser, durante la scrittura, è stupido: "Ho dei dati nel buffer, scrivo i dati".

Non è scritto blocco per blocco, anche se un CD è scritto in settori, il processo di scrittura è fatto come una lunga traccia e il laser emette semplicemente ciò che è nel buffer ai settori sul disco. Se il buffer sul masterizzatore CD non si aggiorna improvvisamente con nuovi dati (poiché il sistema sta facendo qualcos'altro), gli stessi dati nel buffer verranno scritti più volte, senza alcun segno dal software di controllo che avrebbe dovuto arrestarsi scrivendo dati molto tempo fa, e si finisce con immondizia sul disco. Potrebbero essere diverse centinaia di megabyte di spazzatura o potrebbero essere solo pochi kilobyte, in entrambi i casi quel disco non ha più valore in quanto è impossibile dire dove sono finiti i dati buoni e i dati cattivi sono iniziati.

Il recupero dalla spazzatura in fase di scrittura è difficile, in quanto non si ha modo di dire solo quanti dei dati scritti fossero in realtà spazzatura e quanta parte di esso avrebbe dovuto essere ripetuta. Sarebbe molto meglio se potessimo impedire che la spazzatura venga scritta in primo luogo e questo è ciò che sta facendo la protezione da sotto-corsa, osserva il buffer e quando si avvicina allo svuotamento dirà al laser di smettere di scrivere e attendere che vengano visualizzati nuovi dati prima di continuare.


Quindi sostanzialmente è un problema del passato perché la RAM era più piccola e i dischi rigidi erano più lenti (ma anche le velocità di masterizzazione). In altre parole, i buffer underrun non sono più un problema come un tempo?
Synetech,

In effetti sì. I buffer underrun sono ancora possibili poiché grandi trasferimenti di dati potrebbero ancora far morire di fame i buffer di scrittura su un masterizzatore, ma è molto meno probabile di quanto non fosse prima e quasi ogni unità negli ultimi anni è stata in grado di rilevare, proteggere e recuperare da buffer underrun. Vedi en.wikipedia.org/wiki/…
Mokubai

Ho familiarità con le tecniche di prevenzione del buffer underrun, ma non dovrebbero essere meno necessarie in primo luogo. E anche allora, mentre i vecchi dischi rigidi potrebbero essere stati più lenti e utilizzati per i file di paging e così via, i sistemi operativi più vecchi avevano comunque bisogno di meno memoria, quindi lo scambio sarebbe stato comunque meno problematico. Potrebbe essere solo che le persone tendano ad avere un mucchio di spazzatura in esecuzione che risucchia CPU e I / O durante la masterizzazione e che rendere il sistema il più inattivo possibile e liberare quante più risorse possibile avrebbe impedito il buffer underrun?
Synetech,

Non riesco proprio ad avvolgere la testa attorno al masterizzatore ottico che sta davanti al disco rigido. Suppongo che potrei concepire uno scenario in cui il masterizzatore ha un buffer davvero piccolo o assente, e il disco rigido viene così impantanato da alcune app e paging e tale che il masterizzatore alla fine esaurisce i dati, ma allora? Quando un disco rigido sta scrivendo un file e il sistema si blocca, l'unità attende i dati dal sistema fino a quando non è pronto. C'è qualcosa di inerente ai CD / DVD che li rende (o piuttosto originariamente realizzati ) richiedono di essere masterizzati continuamente in un blocco rapido senza mettere in pausa?
Synetech,

Ho aggiornato la mia risposta @Synetech
Mokubai

0

Tempo di ricerca e se l'HDD si trova sullo stesso canale del masterizzatore. Inoltre, come hai detto, quelli sono VELOCITÀ MASSIME, non minime. Anche il software potrebbe rallentarlo e il CD ha bisogno che vengano scritti dati costanti, a meno che non lo si usi come un floppy. Se il disco rigido è più del doppio, può sopportare una pausa per motivi di wahtever


0

Se hai molti file di piccole dimensioni che vengono masterizzati, il tuo masterizzatore CD sarà più veloce del tuo HDD perché i file (probabilmente) non saranno posizionati contigui sul disco, mentre il CD verrà masterizzato contiguo. Quindi confronteresti le letture casuali dell'HDD rispetto alla scrittura sequenziale su CD , quest'ultima delle quali è abbastanza spesso più veloce.


Suppongo che non sia un cattivo pensiero. Ovviamente, utilizzo una partizione dedicata da 4,5 GB (in precedenza era NTFS, ma l'ho cambiata in FAT32) per la masterizzazione di dischi in modo che tutti i file siano contigui. Non ho informazioni / dati / statistiche sulla probabilità di bruciare un sottobicchiere da un'unità deframmentata.
Synetech,

@Synetechinc .: Nota che sto non parlando di ciascun file che viene defragged - sto parlando di più file che vengono disposti in modo contiguo, e nello stesso ordine che essi saranno bruciati. Questo non è qualcosa che accade naturalmente, quindi nella maggior parte dei casi la deframmentazione non aiuta molto.
Mehrdad,

Sì, so cosa intendi; questo è quello che ho detto: l' unità viene deframmentata, non i singoli file contigui .
Synetech,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.