Codifica Run Length Limited
Il più popolare schema di codifica in questo momento, chiamato Run Length Limited, integra fino al doppio delle informazioni rispetto a MFM e tre volte i dati di FM. Nella codifica RLL, il disco abbina gruppi di bit all'interno di un'unità per generare modelli specifici d'inversioni di flusso. Poiché la frequenza e i segnali di clock sono combinati in questi modelli, la velocità di clock si può ulteriormente aumentare mentre si mantiene la stessa distanza di base tra le transizioni di flusso sul supporto.
IBM ha inventato la codifica RLL e ha usato il metodo in molti dei suoi dischi per mainframe. Nei tardi anni '80 l'industria degli hard disk per PC ha iniziato a usare gli schemi di codifica RLL per aumentare la capacità di archiviazione, e oggi ogni disco sul mercato usa una variante della codifica RLL.
Anziché codificare un singolo bit, RLL si occupa di un gruppo di bit alla volta. Il termine Run Lenght Limited è derivato da due specifiche principali di questi codici, che sono il numero minimo (run length) e il numero massimo (run limit) di celle di transizione permesse tra due transizioni di flusso. Ci sono diverse variazioni possibili, in base alla lunghezza minima e al limite, ma solo due sono diventate popolari: RLL 2,7 e RLL 1,7.
Potete persino definire la codifica FM e MFM come una forma di RLL. FM si può chiamare RLL 0,1 perché tra due transizioni di flusso ci sono un minimo di zero a un massimo di una cella di transizione. MFM può essere chiamata RLL 1,3 perché tra due transizioni di flusso ci sono un minimo di zero a un massimo di tre celle di transizione (questi codici si possono esprimere come variazioni della forma RLL, ma non è comune).
RLL 2,7 era inizialmente la variante più popolare di RLL perché offriva un rapporto a densità elevata con una finestra di rilevamento della transizione, per dimensioni, pari a quella della codifica MFM. Questo metodo offriva una densità di archiviazione maggiore e una stabilità abbastanza buona.
Nei dischi ad alta capcaità tuttavia RLL 2,7 non sembrava abbastanza stabile. La maggior parte dei dischi ad alta capacità quindi usa la codifica RLL 1,7, che offre un rapporto di densità 1.27 volte di quello MFM e una finestra di rilevamento della transizione più ampia. La finestra di timing - o la dimensione della cella – per il rilevamento è relativamente più ampia, e di conseguenza la codifica RLL 1,7 offre una maggiore tolleranza e affidabilità . Un aspetto molto importante quando si parla di tecnologie spinte al limite.
Un'altra variante poco usata di RLL è chiamata RLL 3,9 – a volte chiamata Advanced RLL (ARLL). Questa consente un rapporto di densità persino più elevato rispetto a RLL 2,7. Sfortunatamente, con lo schema RLL 3,9 a risentirne è l'affidabilità . Questo metodo era usato solo da alcuni controller ormai obsoleti ed è quasi scomparso.
Capire come funziona il codice RLL è difficile senza un esempio. Ogni variante permette di creare tabelle di codifica per la transizione di flusso, come potete vedere in questa pagina.
Nella tabella di conversione qui hard disotto specifici gruppi di dati, lunghi 2, 3 e 4 bit, vengono tradotti in stringhe di transizioni di flusso lunghe rispettivamente 4, 6 e 8 celle di transizione. Per una particolare sequenza di bit si selezionano certe transizioni, in modo da assicurarsi che le transizioni di flusso non siano troppo vicine o lontane tra loro.
| Codifica Transizione Dati-Flusso RLL 2,7 | |
|---|---|
| Valori Bit di dati | Codifica Flusso |
| 10 | NTNN |
| 11 | TNNN |
| 000 | NNNTNN |
| 010 | TNNTNN |
| 011 | NNTNNN |
| 0010 | NNTNNTNN |
| 0011 | NNNNTNNN |
| T = Transizione di flusso, N = Assenza Transizione di flusso | |
Bisogna controllare la distanza minima tra due transizioni di flusso a causa delle capacità fisse della testina e del disco. Limitare la distanza massima invece serve a mantenere sincronizzate le operazioni.
Studiando la tabella sopra potreste pensare che codificare un valore in byte come 00000001b sarebbe impossibile perché nessuna combinazione di gruppi di bit vi rientra. Codificare questo tipo di byte invece non è un problema, perché il controller non trasmette byte individuali, ma invia interi settori, rendendo la codifica del byte possibile includendo alcuni dei bit nel byte successivo. L'unico problema reale si verifica nell'ultimo byte di un settore, se sono necessari altri bit a completare la sequenza. In questi casi l'endec nel controller aggiunge bit in eccesso alla fine dell'ultimo byte. Questi bit in più sono poi troncati a ogni lettura in modo che il controller decodifichi correttamente sempre l'ultimo byte.