(Sottotitolo: Tutto quello che avreste sempre voluto sapere sui modems e che non avete mai osato cercare.. ma che faccia di bronzo che c’hanno ‘stì grandi sfaticati!)
(Uao, sono stato incaricato! > ;-D < Ecco qui un nuovo lavoro per il wannabe mum_laris!!!)
Di Pierino Lariccia, ma voi continuate pure a chiamarmi Pierino, la peste!
mailto: pierino.lapeste@usa.net
(ma ci guardo una volta la settimana, più o meno, per cui se non vi rispondo immediatamente.. abbiate pazienza, è perché non ho ancora avuto modo di leggere il motivo per cui mi scrivete.. prometto che lo farò al più presto, poiché è mio preciso impegno cercare di rispondere a tutti.. Altrimenti che razza di peste sarei.. ;-D)
(benché non si tratti di una purga!)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Copyright (c) 1999 Pierino Lariccia. Tutti i diritti sono riservati.
E’ possibile ridistribuire su Internet questo documento, a patto che non sia modificato o cambiato in alcun modo e che ne sia data notizia all’autore preventivamente.
Le notizie, istruzioni e consigli forniti nella presente faq sono da considerarsi del tutto generali e forniti a solo scopo informativo, per cui la loro messa in pratica è da ritenersi interamente a vostro rischio e pericolo. L’autore declina ogni responsabilità in caso vengano prodotti danni o avvengano perdite di dati di qualunque tipo a causa di informazioni contenute nella presente faq o di operazioni in essa citate e consiglia caldamente di effettuare sempre un backup dei dati importanti presenti sul vs. hard disk prima di effettuare una qualunque operazione.
I dati e le informazioni fornite sono state verificate per essere le più accurate possibili, ma Internet ed il mondo dell’informatica evolvono molto velocemente, per cui alcune delle notizie riportate, o tutte, potrebbero essere divenute vecchie, inattuali o non più riscontrabili sui moderni pc e periferiche; me ne scuso fin d’ora.
Il fine per cui nasce questo documento non è lucroso, ma puramente educativo.
Se però siete stati capaci di fare denaro sfruttando questo documento, in qualsiasi modo, siete caldamente invitati a farmelo sapere e possibilmente a dividere equamente i ricavi con me! L’autore.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Argomenti da svolgere:
Penso che sarebbe utile chiarire come configurare nelle proprietà del modem
compressione, correzione d'errore, parametri della seriale, ecc.
Mi piacerebbe però che non venissero semplicemente elencate le opzioni ma
che venisse anche fornito un minimo di spiegazione tecnica riguardo alla
natura ed agli effetti delle impostazioni.
Dopo che ho potuto verificare che anche le pagine di aiuto ai clienti di TIN
omettevano di precisare la necessità di attivare controllo d'errore e
compressione mi è parso doveroso valutare l'inclusione nella FAQ del
significato delle proprietà di connessione e di connessione avanzate
presenti in Win95.
Secondo me non basta, ad esempio, scrivere di settare l'opzione per il
controllo d'errore ma è opportuno spiegare quale è lo scopo del controllo
d'errore e che è una funzione del modem.
Così per il controllo di flusso sarebbe necessario fornire qualche dettaglio
dell'interfaccia seriale RS-232 in modo da giustificare i vantaggi del
controllo hardware.
Ok! Cercherò di fare del mio peggio, ehm, volevo dire del mio meglio.. sai come sono queste pesti.. tutte col refuso facile e soprattutto rompono in un modo.. ;-)))
Va bene, ora basta giocare.. forse..
Tralascio, al momento, il discorso sulla impossibilità, o meglio remota possibilità di viaggiare a 56k reali sul nostro bel doppino di rame e trasmissione analogica, rimandando i più curiosi che abbiano voglia e tempo di vedersi il perché (in inglese, of course!) all'url: http://www.k56.com/modems/56kfaq.htm o sui vari altri link presenti nella home page del ns. ottimo Lorenzo Colò.
Per i meno curiosi, tratteremo in volata parte dei motivi.. gli approfondimenti però danno maggiore soddisfazione! ;-)
Per cominciare direi di partire dall'uovo, piuttosto che dalla gallina, benché sia irrisolta la querelle su chi dei due sia nato prima.. al momento ci disinteressiamo di questo aspetto particolare (ma vi prego scrivetemi pure se avete voglia di fornirmi la vs. versione dei fatti.. sto preparando un database sull'argomento con le opinioni di tutta usenet.. o meglio, di quella parte che ha voluto comunicarmele..;-D) e passiamo a vedere come è fatto il collegamento pc-modem, partendo dal pc ed andando verso il modem.
A dire il vero, prima di arrivare a questo argomento, faremo prima un bell’excursus su tutto ciò che ci serve, al fine di comprendere meglio il discorso, ma poi fidatevi che si tornerà a parlare di questo.
Per inciso, questa parte di comunicazione pc/modem è normalmente trascurata, perché viene ritenuto in genere, che il collegamento modem-pc sia sempre più veloce di quello modem-rete, o che quanto meno modem e pc comunichino più o meno alla stessa velocità e pertanto si punta tutto sulle capacità del modem, che devono essere fantascientifiche, in modo che questo non rappresenti il collo di bottiglia nella comunicazione. Bene è mia intenzione sfatare questa convinzione, essendo questa parte di collegamento altrettanto importante, se non di più, di quella di avere un super modem 56k o più! Infatti se il pc non è in grado di elaborare tutti gli input che gli provengono dalla rete, o peggio, se lo è ma la comunicazione col modem è lenta, si ha che è completamente inutile avere un super pentium da un lato ed un 56k megagalattico dall’altro; il flusso dei dati che transiterà sarà sempre quello di un "33.6k equivalente" (se va tutto bene!), elaborato da un "486 equivalente" (questo sempre nella migliore della ipotesi!). Con ciò non voglio dire che fate bene a collegare il vs. modem alla presa Telecom con un cavo da 100 metri, e che sia sana l’abitudine di tenere trentasette doppi e tripli spinotti, nonché ulteriori derivazioni varie, sulla stessa presa sulla quale è attaccato il modem e che magari non è nemmeno quella principale, ma al momento non è questo l’argomento che dobbiamo affrontare!
Per inciso, di tanto in tanto troverete una sequenza di dati tecnici, che non sono proprio fondamentali alla comprensione, ma che aiutano a comprendere il senso di alcune informazioni, nonché a tenere viva l’attenzione di chi non è proprio un newbie.. Ho fatto comunque in modo che figurino in trafiletti isolati, tali da poter essere facilmente individuati e saltati da chi i dati tecnici aborra!
Ed allora diamo inizio alle danze!
<excursus>
Il MODEM è uno strumento che ha come funzione quella di MOdulare/DEModulare i dati che vi transitano attraverso, ovvero trasforma il segnale digitale del pc in segnale analogico, in modo che possa essere trasmesso lungo la linea telefonica; questo successivamente verrà riconvertito in segnale digitale dal modem remoto, dall’altra parte della linea (tralascerò in attesa di tempi migliori di considerare tutte le conversioni/deconversioni intermedie che si hanno lungo il percorso, nel caso in cui ci siano passaggi per linee o centralini digitali e non). La trasmissione si basa su un segnale vettore, che come dice il termine stesso, "trasporta" i dati. Il trasporto avviene modulando e variando le dimensioni stesse del vettore.
Ora affinché sia possibile che tutti i modems possano comunicare tra loro bisogna evitare che ogni produttore di tali periferiche elabori uno standard proprio che risulti poi completamente diverso dagli altri; pertanto tale operazione di codifica dei bits digitali in segnale analogico viene eseguita sfruttando una precisa sequenza di operazioni detta protocollo di modulazione. Ciascuno di tali protocolli, standardizzati in tutto il mondo da un ente specifico, come vedremo in seguito, definisce il modo di codifica corretto e la velocità di trasferimento dei dati. I modems in commercio supportano generalmente più protocolli di modulazione. La velocità netta di un modem, ovvero la velocità massima supportata per il trasferimento, senza che i dati vengano compressi, è determinata dai protocolli di modulazione. Ora la velocità con cui avviene questo trasferimento di dati, è possibile valutarla sia in termini di "cicli di trasporto", sia, equivalentemente con quanti bit per ogni ciclo vengono trasmessi.
Si è soliti indicare col termine baud i cicli di trasporto.
Il numero di bit trasmessi per secondo da un ciclo (o da più cicli, nello stesso secondo) è detto bps.
Da come sono stati definiti è evidente che non sono la stessa cosa, benché normalmente vengano trattati come tali.
Infatti è pur vero che originariamente esisteva una differenza esile tra i due, perché i modems, una volta, trasmettevano solo 1 bit per baud. Ma ora che i bit sono compattati perché ne entrino molti di più in un baud, la differenza comincia ad avvertirsi ed ad essere sostanziale! Infatti un vecchio modem che lavora a 9600 bps trasmette a soli 1200 baud, perché riesce ad "impaccare" fino 8 bit in un baud. Facendo i conti, si comprende come mai oggi si tenda ad indicare tutte le velocita' di trasmissione in bps (bit per secondo) o, meglio, in Kbps (Kilo bit per secondo dove 1000 bps = 1 Kbps) oppure per maggior chiarezza e soprattutto a livello dei protocolli superiori in cps (caratteri o Byte per secondo) o KB/s (1024 Byte al secondo).
Ora poiché le cose si susseguono un po’ troppo velocemente, mi sembra giusto ricordare che le trasmissioni tra modems sono "normate" da un istituto, lo ITU-T (International Telecommunication Union - Telecommunications, ex CCITT), l'ente internazionale preposto alle standardizzazioni nel campo delle comunicazioni. Gli standard (o meglio le raccomandazioni) relativi alla trasmissione su normali linee telefoniche sono quelli caratterizzati dalla lettera V; partendo dai protocolli di comunicazione veri e propri che specificano modulazione, handshake e velocita' consentite [vedremo in seguito per l’handshake di che si parla], abbiamo senza risalire troppo indietro nel tempo il V.32 fino a 9600 bps, il V.32bis fino a 14400 bps e il V.34 fino a 28800bps. Bisogna poi aggiungere degli standard proprietari sviluppati dai produttori per sopperire alla lentezza dell'ITU-T nell'approvazione di protocolli piu' veloci: il V.32terbo fino a 19200 sviluppato da AT&T come evoluzione del V.32bis e presente quasi solamente sui suoi chipset da 19200 e superiori e sugli U.S. Robotics Courier V.Everything; il V.Fast Class (V.FC) fino a 28800 bps sviluppato da Rockwell e supportato sui suoi diffusissimi chipset 28800 e superiori e sul solito Courier.
U.S.Robotics ha sviluppato
successivamente un'estensione a 33600 bps del V.34, denominata V.34+, distribuita
dopo poco anche su tutti gli altri modem con chipset Texas Instruments,
che e' stata ratificata successivamente dall'ITU-T
mantenendo il nome V.34. Come tutti i protocolli soffre di qualche problema
di giovinezza che porta soprattutto a una non perfetta interoperabilita'
con connessioni a velocita' inferiori, soprattutto fra modem con chipset
diversi, in particolare fra Rockwell e Texas Instrument anche recenti sono
piu' comuni i collegamenti a 31200 bps. In ogni caso comunque la maggior
raffinatezza del protocollo esteso a 33600 bps e' di aiuto anche nel caso
di linee disturbate; e' comune infatti che dove prima si registravano solo
collegamenti a 24000 e 26400 bps questi incrementino almeno a 26400 e 28800bps.
Oltretutto essendo un'estensione
della stessa tecnologia e' spesso possibile effettuare un upgrade dei modem
con velocità originale di 28800bps, aggiornando il codice contenuto
nella ROM del modem, con la sostituzione del chip nella maggior parte dei
casi o un semplice aggiornamento software nei modelli dotati di FLASH ROM.
Tra i modems di provenienza asiatica, di vecchio stampo, bisogna prestare attenzione anche ad alcuni modelli bacati che circolano con tale configurazione che non funzionano correttamente oltre i 28800 bps e non connettono praticamente mai a piu' di 31200 bps, persino nei test con Local Analog Loopback che vi consiglio di effettuare e che e' quasi sempre documentato sui modem economici asiatici. Per verificare la velocita' massima fate in modo che il messaggio CONNECT indichi la velocita' DCE del modem e non il DTE della seriale (AT\V2 per il DCE dettagliato sui Rockwell) ed eseguite il Local Analog Loopback con timer (ad esempio sempre per i Rockwell AT\N1 seguito da ATS18=30&T1) – per maggiori info, riguardatevi la parte di faq sviluppata al proposito dal nostro Lorenzo Colò; per controllare il corretto funzionamento almeno interno invece e' opportuno eseguire il Local Analog Loopback with Self-Test che riporta il numero di errori che deve essere 0 (ancora per i Rockwell AT\N1 e ATS18=0T8 per iniziare e AT&T0 per terminare, meglio se dopo qualche minuto).
Trovandoci a parlare di protocolli di trasmissione, ecco che viene utile definire anche i protocolli supplementari definiti dall’ITU-T che accompagnano i nuovi protocolli di trasmissione sviluppati.
Infatti fondamentali sono i
protocolli di correzione e compressione, rispettivamente V.42 e V.42bis
(che incorporano e migliorano i vecchi, ma ancora utilizzati protocolli
Microcom MNP4 e MNP5 – rispettivamente Microcom Networking Protocol per
la correzione di errore e per la compressione dei dati), ormai onnipresenti
sui modem e quasi sempre abilitati di default nelle impostazioni del modem.
La correzione V.42 (o la vecchia MNP4) si occupa ovviamente di garantire
l'affidabilita' della trasmissione utilizzando di default il protocollo
LAPM (Link Access Procedure for Modems), o in alternativa, il protocollo
MNP-4; tale sistema si occupa di ritrasmettere eventuali pacchetti errati
rilevati con dei CRC (Cyclic Redundancy Check): quello che non tutti sanno
e' che la sua abilitazione porta anche un aumento della velocita' del modem;
la trasmissione normale diffusa oggi 8N1 (8bit dati, Niente bit di parita',
1 bit di stop) infatti spreca un bit di stop e uno di start per ogni 8
bit trasmessi riducendo di fatto le prestazioni di 1/5 mentre attivando
la correzione i codici di CRC sprecano solo circa 1/10 dei dati.
VELOCITA' CONNECT (bps) | PROTOCOLLO | PRESTAZIONI MASSIME
CON V.42 (cps) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
La compressione V.42bis invece effettua trasparentemente una compressione fino a un massimo di 4:1 dei dati non gia' compressi (nel qual caso si disabilita per non causare un rallentamento come faceva il vecchio MNP5, che poi arrivava solo a 2:1); utile ad esempio quando si naviga e quindi si scaricano sorgenti html, javascript, ecc. NON può essere utilizzata se non è attivata anche la correzione d’errore; è possibile utilizzare sul proprio modem la sola correzione senza compressione, ma non il viceversa. Tornando alla compressione comunque, in realta' anche con i file di testo l'efficienza non arriva mai al limite massimo e si attesta su un 2-2,5:1 a causa della compressione effettuata necessariamente in real time ed esaminando gruppi di dati molto ridotti; questo fattore puo' poi calare ulteriormente in caso di trasmissione bidirezionale se il controller non e' troppo potente: un compressore di tipo zip, arj o rar sugli stessi tipi di file arriva tranquillamente a fattori di 3-5:1 o anche oltre con delle tecniche piu' sofisticate ma piu' lente, quindi quando possibile trasferite sempre dati gia' compressi. Legato alla velocita' massima del collegamento alla compressione massima dei dati c'e' il tipo della porta seriale e la velocita' a cui va impostata per non agire da collo di bottiglia per le prestazioni del modem, in teoria almeno 4 volte quella della connessione ma in pratica viste le prestazioni del V.42bis bastano anche 2,5-3 volte.
L'ultima novita' in campo di velocita' nei modem e' la nuova generazione da 56 Kbps rappresentata in realta' da 2 standard distinti: X2 sviluppato da U.S.Robotics e Texas Instrument e licenziato da Cirrus Logic e K56Flex realizzato da Rockwell e Lucent come unione dei loro precedenti progetti distinti K56Plus e V.flex 2. I due standard distinti anche se non sono assolutamente compatibili sono in realta' molto simili ed infatti è stato possibile all’ITU-T realizzare un protocollo unico, il V.90, l’ultimo prodotto degli standard di comunicazione, che consente il dialogo tra questi 2 tipi differenti di protocolli utilizzati dai 2 leader del mercato.
Per ottenere i 56 Kbps in realta' si e' dovuto scendere a compromessi rispetto allo standard V.34 che come protocollo full-duplex sfrutta gia' al meglio il canale analogico limitato in banda (in un intervallo all'incirca fra 230 e 3670 Hz) della rete telefonica da cui in condizioni ideali non si puo' ottenere piu' di circa 35 Kbps bidirezionali. E' necessario quindi per sfruttare tale velocita' che le centrali telefoniche interessate da tutte le tratte intermedie siano completamente digitali senza conversioni: questa è una condizione peraltro comune da noi nei centri urbani; non altrettanto comune risulta pero' quella che anche il modem all'altro capo sia connesso su una linea digitale, condizione questa comune solo fra i grandi provider Internet e alcune aziende; ed in ogni caso questa velocita' e' possibile solo in download mentre in upload si ricade nei limiti attuali. Il convertitore Digitale/Analogico con codec PCM della rete telefonica lavora a una frequenza di 8 KHz e adopera una quantizzazione non uniforme a 8bit (256 intervalli) con un transfer teorico massimo di 64 Kbps; in realta' invece si usano solo 7 bit (128 valori) perche' su alcune reti telefoniche l'ottavo bit e' sfruttato da servizi telefonici supplementari e si scende quindi a una velocita' di 56 Kbps.
In upload invece (o nel caso di qualsiasi conversione intermedia) si ha invece un errore di quantizzazione nella conversione Analogica/Digitale della rete telefonica di circa 36dB che riporta al limite dei tradizionali modem analogici.
Giusto a conclusione voglio chiarire che: chi ha un modem a tecnologia k56flex o X2 può benissimo fare a meno di eseguire l’upgrade a V.90, nel caso in cui il proprio ISP non utilizzi l’altra tecnologia e quindi fino ad ora i propri collegamenti non siano stati realizzati, a causa della differenza di caratteristiche, in ripiego su V.34. Infatti se il vs. ISP supportava una delle due e ha aggiornato lo standard per consentire anche a chi possedeva l’altra tecnologia, di collegarsi a velocità superiori a quelle del V.34, non vuol dire che non supporti più la vecchia ed anzi il cambiamento per voi non comporta nulla, se non qualche piccolo disservizio durante l’aggiornamento dei modem. L’upgrade deve essere effettuato soltanto da chi ha intenzione di cambiare ISP e sa che il prossimo non supporta la tecnologia attuale del proprio modem (k56 o X2 rispettivamente!).
</excursus>
Torniamo allora alle nostre porte seriali ed alla velocità di trasmissione dati che lega modem e pc.
(Visto? Ve l’avevo promesso che ci saremmo tornati sopra.. ;-D)
Tale velocità viene chiamata DTE (Data Terminal Equipment), ed è quella velocità che è strettamente legata al tipo di porta seriale a disposizione, al chip ed ai driver che la controllano ed al modem col quale è collegato il cavo, perché come abbiamo visto la velocità della trasmissione dati in questo settore deve essere adeguata a quella del modem.
E’ opposta a DCE (Data Control Equipment), che è la velocità con cui il modem locale comunica col modem del ns. Internet provider.
Vedremo ora meglio quanto è stato accennato.
Indubbiamente si parte, in questo nostro viaggio nel mondo dei dati, dalla porta seriale (ma anche porta isa/pci), del vs. pc (a seconda che il modem collegato sia esterno/interno rispettivamente), e si prosegue con un cavo chiamato null-modem (correggimi se sbaglio, Lorè..), che porterà i vs. dati fino alla porta corrispondente del modem (questo se il modem è esterno, per gli interni si sfrutta il bus dati, per cui i possessori di modem interni possono saltare questo pezzettino di faq..). Generalmente le porte di comunicazione tra questi due elementi, e che assumono il nome di porte COM (o comm) o porte seriali o anche adattatori di comunicazione asincrone, usate in questo giro di dati, sono le interfacce seriali RS-232. Possono essere a 9 o a 25 pin (dietro il pc) e generalmente a 25 pin dietro il modem (ma anche qui possono valere eccezioni). Affinché possano funzionare, ci sarà il driver relativo (che è un software), che si incaricherà di interpretare i segnali che fluiscono dalla porta e provvederà ad avvisare il sistema ricevente, che dei dati sono arrivati; se invece i dati sono da lui trasmessi, si occuperà di avvertire il pc/modem ricevente, dall’altro lato del cavo. Inoltre esistono diversi tipi di porte seriali; sia per il pc, che per i modem, sono comandate da un controller, da un chip, chiamato UART (Trasmettitore/Ricevitore Asincrono Universale), che ha il compito di convertire, per l’appunto, i dati che fluiscono dal pc in dati di tipo seriale che possono essere trasmessi dalla nostra porta e viceversa. Questo chip può essere di tipi differenti e a seconda delle sue caratteristiche, varia in particolare la velocità con cui la porta comunica col nostro pc/modem. Diciamo che possiamo ricordare che si dividono principalmente in UART non dotate di buffer dati (ormai non più prodotte, ma potrebbero essere ancora presenti su qualche pc..) e UART bufferizzate. Queste ultime partono dalla 16550A ed arrivano (almeno a mia conoscenza!) alla 16750. Esistono poi altri tipi di connessioni equivalenti che possiamo riassumere ancora una volta in Porte Seriali Compatte e Seriali Integrate. Non scenderemo in dettagli ulteriori (magari in faq future..), ma tutto questo per dire che a seconda della quantità di dati che il pc deve gestire, migliora o peggiora la sua comunicazione col modem. Il buffer a disposizione, serve per dare al pc la possibilità di gestire i dati secondo i "suoi" tempi e non quelli della rete (esistono ancora utilità in giro che sincronizzano i pc ai due estremi della comunicazione, nel caso in cui non ci sia la possibilità di avere un buffer a disposizione.. e lo stesso modem ha un’opzione che attiva un risultato simile!), migliorando e velocizzando la gestione dei dati. In caso in cui questo non sia possibile, il pc deve fare fronte agli input che gli giungono in tempo reale, cosa che diciamo non preferisce ed ecco che escono fuori gli overrun errors (errori di sovraccarico). Vediamo brevemente di cosa si tratta: si perde lungo la strada che collega il modem col pc, uno o più bit. Il software di controllo della comunicazione è così costretto ad intervenire e per risolvere il problema sarà probabilmente costretto a chiedere il ritrasferimento dei dati, quindi si avrà un rallentamento della vostra connessione rispetto a quanto dovrebbe essere veloce! Infatti, se il modem resta inattivo per un periodo e poi improvvisamente scarica una mole di dati al pc e tutta insieme, è possibile che questo non abbia il tempo necessario per gestire tutte le info giunte, da cui l’errore di sovraccarico! Ad esempio un lento modem di 2400bps che opera senza compressione dei dati (quindi in ogni baud entrano bit non impaccati!), sarà in grado di scaricare soltanto 240 caratteri per secondo, quindi il computer avrà più di 4 millisecondi per gestire ogni carattere che gli giunge dalla porta seriale (e questo è un tempo ben lungo per un pc!). Viceversa un modem di 28800bps (che oggi non è che sia il massimo della velocità consentita..), che usa la compressione dei dati, è in grado di trasferire fino a 5760 (o più a seconda della compressione!), caratteri per secondo, nella nostra seriale! Questo secondo modem è più veloce del primo quindi di più che 20 volte e richiede che il pc legga i dati in meno di 2/decimillesimi di millisecondo! Ecco perché il secondo modem crea errori di sovraccarico molto di più del primo.. Chi mi sta leggendo in questo momento avrà almeno un 56k a disposizione, nel 60% dei casi (anche stavolta i dati provengono dal mio database personale.. se volete aggiornarlo, siete i benvenuti!). Siete proprio sicuri che sia colpa della rete, se ci mettete un tempo considerevole per scaricare questo documento? ;-)
Potete operare in più modi per ridurre gli errori di overrun intervenendo sull’hw e i passaggi necessari sono tutti descritti ad esempio nella faq all’url: http://www.comminfo.com/pages/ctsfaq01.htm
Per quanto mi riguarda posso consigliarvi di seguire le raccomandazioni dei costruttori di modem e già riportata in precedenza, secondo le quali sarebbe buona norma settare la velocità della propria porta seriale almeno di 4 volte più veloce della velocità alla quale il vs. modem può mandare dati. E’ comunque possibile operare diversamente in caso di necessità; infatti tale raccomandazione è basata sul fatto che è possibile comprimere un dato fino ad una ragione massima di 4 a 1, ma abbiamo visto, ad esempio che un documento di testo non può essere compresso per una ragione superiore a quella di 2 a 1, per cui diciamo che una piccola deroga è possibile. Sappiamo ad esempio che su dati già compressi, non è possibile operare alcun trattamento ulteriore, ed anzi che la precompressione permette di risparmiare tempo, risorse e danaro (poiché gli algoritmi di compressione dei moderni software sono molto più efficienti dei corrispondenti algoritmi dei modems, che sono invece costretti ad operare in tempo reale e su dati di cui non conoscono esattamente quale sia la dimensione)! Tutto questo per dire che tutto sommato se avete errori di sovraccarico, è possibile rallentare la velocità di trasmissione dati della vostra seriale! In tal modo il vs. pc avrà un tempo maggiore per effettuare il trattamento dei dati che gli giungono. Inoltre questo tipo di soluzione, riducendo gli errori di overrun e quindi il ritrasferimento dei dati potrebbe paradossalmente velocizzare e rendere più stabile la vs. connessione! Come sempre bisogna provare, provare, provare ed ancora provare e solo allora si avrà la certezza di aver fatto tutto il possibile e che meglio di così la mamma Telecom non ci permette di fare! La ricetta universale per tutti i mali, come la pietra filosofale o la lampada di Aladino, purtroppo non esiste.. forse nel giardino del re c’è qualcosa (mi dicono!), ma io non ci guarderei: il re è un permaloso di quelli.. ;-D
Quindi viste le velocita' fisse e limitate della porta seriale per un modem 14.4 Kbps bisognerebbe settarla a 57.6 ma anche 38.4 va bene, un 19.2 avrebbe bisogno di 115.2 ma 57.6 va largamente bene e 28.8 invece e' al limite; un 28.8 richiederebbe infatti 115.2 mentre con 57.6 e' al limite, un 33.6 infine avrebbe bisogno di 230.4 ma in pratica non ci sono differenze con 115.2. Le porte seriali "normali" (abbiamo visto cosa significa!), accettano rate fino a 115200 bps, oggi con i sistemi operativi multitasking e i modem veloci e' d'obbligo una UART di tipo 16550 che ha un buffer di 16 byte, le vecchie 8250 e 16450 (non bufferizzate), in pratica sono usabili solo fino a 38400 o 57600 bps. Fra le novita' +o- recenti ci sono le UART di tipo 16650 con un buffer raddoppiato a 32 byte che pero' deve essere supportato dal driver (altrimenti si comporta come una 16550) e quelle con moltiplicatore di clock 2x o 4x che aumentano la velocita' effettiva rispetto a quella impostata ottenendo quindi come massimo 230400 e 460800 bps, devono pero' essere supportate dal modem.
Per sfruttare al massimo questi standard bisogna pero' tenere bene in considerazione la velocita' della seriale in presenza di compressione; 115,2 Kbps infatti e' esattamente il doppio della velocita' di collegamento ed e' quindi al limite con il V.42bis.
Ora già lo so che i più di voi, vecchi utenti DOS, si staranno già strappando i capelli perché nel passaggio da MS-DOS x (o Win 3.x) a Win9x, non hanno avuto la prontezza di spirito di salvare da qualche parte il programma MSD.EXE, fornito con tali s.o.! Ebbene a salvaguardia dei capelli rimasti (pochi per quanto mi riguarda!), vi dirò, nel caso in cui non ve ne siate già accorti, che in win9x è ugualmente presente. Per chi non lo conoscesse, questo programma dava la possibilità di determinare (tra le altre cose), che tipo di controller UART si avesse a disposizione sulla propria macchina.. seppure ogni tanto prendesse cantonate! Ora, semplicemente, non è più un elemento separato ed eseguibile singolarmente, ma fa parte di win9x. In particolare aprendo il pannello di controllo/modem/diagnostica/informazioni (avendo avuto cura di selezionare preventivamente la porta seriale a cui è connesso il vs. modem e ad averlo acceso, prima di cominciare il test), si otterranno le stesse informazioni, ovviamente ristrette alla seriale ed al modem. In particolare per questo ultimo, se a chipset Rockwell, le voci ATI3,4,6 forniscono rispettivamente la versione del firmware della rom, il modello del modem e la versione del data pump. Per i modem U.S.R., invece della ATI6, dovranno guardare la ATI7 per avere la versione del data pump.
Tornando all’uso che si può
fare delle nuove tecnologie, bisogna anche notare che nel caso di U.S.Robotics
l'uso del DSP programmabile consente facilmente l'upgrade dei modem attuali
a 28.8 Kbps o 33.6 Kbps e soprattutto di quelli dei provider Internet,
riuniti insieme in costose apparecchiature spesso con montaggio rack, condizione
fondamentale per avere una grossa base installata e imporre lo standard.
L'upgrade di questi apparecchi carica pero' notevolmente il non potente
controller x86 sia pur ampiamente adeguato per le velocita' attuali; e'
probabile quindi che ci siano perdite di efficienza soprattutto nella compressione
(ben piu' pesante della decompressione) a 57.6 Kbps e maggiormente in caso
di traffico bidirezionale.
I primi test effettuati sugli
U.S.Robotics X2 hanno evidenziato collegamenti compresi fra 44 e 52 Kbps
con prestazioni in navigazione non brillantissime ma comunque visibilmente
migliori di un modem a 33.6 Kbps e quindi sicuramente raccomandabili vista
la piccola differenza di prezzo, a patto ovviamente di essere nelle condizioni
di sfruttarli.
A questo punto qualche "tipo" un po’ saccente (e ce ne sono, ve l’assicuro!), dopo tutta questa bella tiritera, alzerà la manina e con fare compito dirà: scusa "peste", ma il controllo d’errore del modem non dovrebbe prevenire i problema dei sovraccarichi? NO!
Il controllo d’errore (che magari vedremo un po’ meglio in seguito!) serve per verificare i dati e correggere i problemi che occorrono sulla linea telefonica, ma tra i due modem collegati, mentre assolutamente non si preoccupa se i dati giunti siano correttamente trasmessi al pc! Paradossalmente, se dall’altro capo del cavo non ci fosse nulla, i protocolli di correzione d’errore implementati sugli standard V.42 o MNP non sono nemmeno in grado di accorgersene! Infatti questo compito è delegato ad altri protocolli, tipo l’FTP (file transfer protocol), che è sempre meglio usare nel trasferimento dati, per consentire al sistema di individuare gli eventuali dati corrotti, anche se si sta già usando il protocollo di controllo degli errori. Tra l’altro l’uso di questi protocolli ha anche gli altri risvolti vantaggiosi che abbiamo già visto. Per ora vorrei soffermarmi su un altro importante sistema per prevenire gli overrun errors, che è il "controllo di flusso".
Tale sistema è utilizzato dal pc per segnalare al modem, che la memoria che ha a disposizione per la ricezione dei dati, sta per essere completamente riempita e pertanto non è in grado di gestirne altri. E’ fondamentale pertanto che tale opzione sia sempre attivata affinché sia possibile proteggere i buffers di accumulo dati del pc o del modem dal sovraccarico. In alcuni casi è proprio un inadeguato o disabilitato controllo di flusso che genera i problemi di sovraccarico. Vediamo ora qualcosa di un po’ più specifico. I tipi di controllo di flusso supportati dal vs. modem/pc sono: hardware handshaking (gestito tramite CTS/RTS) e software handshaking (gestito tramite XON/XOFF). Dei due il migliore è il primo, il controllo di flusso di tipo hardware. In particolare questo controllo viene esercitato tramite due segnali che corrono nell’interfaccia seriale delle ns. RS-232 e che sono appunto l’RTS (Request To Send) ed il CTS (Clear To Send). CTS è usato dal modem per comunicare la fine di una trasmissione. Quando ad esempio il modem locale è pronto per ricevere dei dati, manda al pc il segnale CTS, per segnalare di cominciare il trasferimento dei dati. Nel momento in cui il buffer si riempie e quindi il modem non è più in grado di ricevere altri dati dal pc, ecco che disabilita tale segnale, arrestando il flusso di dati. Quando tale buffer si sarà svuotato, il segnale verrà riattivato per riprendere il trasferimento dei dati. RTS viene utilizzato dal pc per interrompere un trasferimento di dati. Se ad esempio il pc non è in grado di smaltire tutti i dati alla velocità con cui il modem glieli passa, disabilita questo segnale in modo da interrompere il trasferimento dei dati e lo riabiliterà solo quando sarà pronto a riceverne un altro carico. Il flusso di controllo software è realizzato implementando il controllo dei caratteri nel flusso dei dati. XON è anche noto come CTRL-Q o DC3 (Ascii 19), mentre XOFF come CTRL-S o DC1 (Ascii 17). E’ evidente quindi come l’uso di XON e XOFF durante il trasferimento dei dati, può creare problemi quando un file binario contiene il carattere Control-S (^S), che viene invece interpretato come controllo del flusso dati e non come dato! E’ quindi sconsigliabile usare questo tipo di controllo di flusso se vi sono i due citati caratteri all’interno dei dati da trasferire.. per evitare fastidiosi controlli con editori esadecimali di tutti i file che si vuole trasferire, è pertanto consigliabile utilizzare sempre il primo tipo di controllo di flusso!
OK! Siete ancora vivi?
E state continuando a leggere?
Allora le possibilità sono due: Siete veramente interessati all’argomento e pertanto spero che finora non vi siate completamente annoiati; anzi, magari (spero!) potreste avere appreso una piccola curiosità della quale non eravate a conoscenza, dal mio sproloquio.
Se invece non è questo il caso e sapevate già tutto e nonostante tutto continuate imperterriti a proseguire.. eh, bè, ma allora siete masochisti, vi piace soffrire.. ed allora sarete felici di sapere che non ho ancora terminato (e quindi potrete godere un altro po’!) :-]
Infatti a premio dell’interesse dei primi e della costanza (e piacere!) dei secondi, passo alla parte operativa di questo piece of faq; ci occuperemo ora di passare in rassegna i comandi utilizzabili per mettere in pratica quanto appreso sull’hardware del vs. modem e anche qualche altra cosa! Non pensate infatti che la comunicazione pc/modem sia una cosa semplice.. per interagire, questi due bei campioni, utilizzano dei programmi, e non è detto che i settaggi standard forniti dalla casa produttrice del vs. modem siano adeguati per superare anche questa seconda difficoltà! In genere vanno bene, ma le eccezioni sono sempre in agguato e pertanto bisogna essere pronti a operare sulla stringa di inizializzazione del modem!
Prima di cominciare, però, dovete superare la convinzione che le stringhe servano per velocizzare la vs. connessione alla rete.. a questo scopo in genere, è più efficace un lettera di vibrata protesta alla Telecom per le pietose condizioni della linea (e non starò qui ad elencare gli effetti che questa potrà avere sul secondo muro di gomma italiano.. il primo non lo cito per rispetto ai defunti!). Considerate le condizioni medie delle linee di telecomunicazione italiane, l’intervento sulla stringa, mira, piuttosto che a velocizzare, a rallentare il modem, in quanto i nostri doppini non sono adeguati a reggere quei livelli di transfer rate, o non lo è il modem del ns. provider! In entrambi i casi una sana riduzione di velocità è molto più efficace di strani settaggi sui registri del s.o. od operazioni alchemiche sulle prese telefoniche di casa! (Se vi può sollevare però, per questa fase ci sono passato anche io! :-D). Ad ogni buon conto diamo bando alle ciance (anche se non completamente!) e cominciamo con l’illustrazione (figurata!), degli interventi possibili!
Considerate infatti che, pur partendo dal presupposto che il modem superfantagalattico che possedete sia tollerato dall’hardware del vs. pc, questo deve poi essere ugualmente tollerato dal software di intercomunicazione posto tra i due; se anche questo avviene, potrebbe essere che il settaggio non sia stato perfettamente corretto; infine che se anche questo ostacolo viene superato, potrebbe essere che tali settaggi non valgano sempre e debbano essere adeguati a seconda dell’uso che si fa di tali programmi e del problema da risolvere! Chiarito il punto di vista, passiamo all’azione.
La prima cosa da fare è controllare che il settaggio che viene effettuato sul modem, dalla stringa prememorizzata nella rom, coincida con quanto viene poi disposto sul software che lo deve utilizzare..
In generale bisogna accertarsi, scorrendo il proprio modemlog per chi usa W.95/98 o il manuale per chi usa altri sistemi operativi che i settaggi standard della propria casa costruttrice di modem abilitino:
Protocolli di comunicazione supplementari:
CD è un segnale generato dal modem ed è utilizzato per indicare lo stato della connessione. DTR è un segnale generato dal computer ed è utilizzato per abilitare il modem ad accettare i comandi dal programma di collegamento e contemporaneamente è utilizzato dal modem per stabilire quando disconnettersi da una chiamata. Con particolari collegamenti con terminali "muti" può essere necessario settare il modem ad ignorare il segnale di invito alla disconnessione DTR, forzando il mantenimento costantemente attivo del CD, ma l’uso frequente di questa opzione (Rockwell:&C0&D0 – per U.S.R.:&C0&S0), causa problemi di comunicazione colla periferica nel momento in cui la disconnessione è realmente richiesta e può generare errori facendo credere al pc che il modem è connesso anche quando non lo è. Pertanto il settaggio perpetuo è un modo che sconsiglio di utilizzare, lasciando i comandi che vengono utilizzati di default dal modem ovvero, nel caso non lo siano, quelli suindicati. In genere infatti i programmi di comunicazione operano facendo seguire la trasmissione del modem al consenso fornito dal DTR e si aspettano che il segnale CD segua il vettore, per cui sfruttano nella maggior parte dei casi proprio la sequenza di comandi fin qui consigliata. Volendo riassumere tutta la sequenza, questa si presenta (a titolo di esempio!), come:
AT&C1&D2&K3\N3%C3 per i modem a chipset Rockwell, mentre diviene: AT&C1&D3&H1&R2&M4&K3 per modems U.S.R.
In effetti nel caso in cui il settaggio standard del modem sia differente per qualche motivo da questa stringa, questa è una sequenza un po’ lunga se la si volesse riscrivere ogni volta; per fortuna ci viene incontro windows; infatti è possibile aggiungerla nella apposita finestra delle proprietà aggiuntive del modem del pannello di controllo. Alternativamente è proprio possibile sostituire quella presente nella memoria non volatile del modem, con questa; per effettuare tale passaggio, basta aggiungere in coda alla stringa, operando ad esempio con hyperterminal, dopo aver resettato il modem, il comando &Wn con n = 0, 1; questo permetterà di registrare tale stringa nel profilo 0 o nel profilo 1 del modem; quello 0 viene richiamato di default ad ogni reset della periferica.
Ci sono poi tanti altri settaggi che è possibile modificare, aggiustare ed adattare a seconda del modem remoto con cui dobbiamo comunicare ed alle condizioni stesse della linea, ma queste non rappresentano l’argomento di questa "Piece of faq". Per i più curiosi o masochisti instancabili, rimandiamo all’abbondante messe di documenti presente in rete sull’argomento (per la maggioranza in inglese, ma tanto ormai vi sarete convinti di doverlo imparare per forza!), o a prossime produzioni degli autori.. molto meno facili da reperire, al momento, ma chissà.. ;-) Per ogni dubbio, difficoltà, ringraziamento, insulto, voglia di dirmi quello che pensate di me ed amenità simili, l’e-mail la conoscete..
Alla prossima pestifera produzione.. ;-)
Pierino, la peste.
Note a margine.
~*~
La bibliografia utilizzata per redigere questa faq è riportata nella stessa, avendo l’autore avuto cura di lasciare operativi i link ai documenti originali da lui utilizzati; (manca il solo link alla rubrica di hardware tenuta da Andrea Nenni, della quale ho smarrito il link! Anzi se lo avete, vi prego, inviatemelo.. mi manca tanto!!). Ciò nonostante le informazioni riportate sono state integrate anche con conoscenze personali dell’autore, tratte dal suo lurkaggio continuato su it.comp.hardware.modem, per cui chi volesse ampliare le basi fornite in questa faq non deve fare altro che fare riferimento a tutti i link citati nel documento ed in più sottoscrivere il newsgroup citato. Nonostante non sia intenzione dell’autore tediare più di tanto i lettori, voglio ricordare in ogni caso che sono sempre in vigore le buone maniere su usenet, come nel mondo reale! Chi pertanto non conoscesse il comportamento da tenere sulla rete, come sui ng od ovunque, è pregato di adeguarsi! Quando si entra in un posto nuovo, ci si cerca di informare preventivamente su chi lo frequenta, come queste persone si pongono di fronte alle questioni, se c’è qualcuno che tira le fila, quali sono le consuetudini e le abitudini locali. Lo stesso vale sui ng! Prima di irrompere come cicloni e fare danni o porre questioni trite e ritrite (benché nuove per chi le pone!) e irritare così chi sostiene il newsgroup interessato, siete pregati di andarvi a vedere su it.faq, quale è il comportamento da tenere: infatti vengono postate ciclicamente su tale ng tutte le consuetudini, tic e tac necessari per comprendersi sulla ragnatela mondiale! Naturalmente, dopo averle lette, le indicazioni vanno messe in pratica! (Anche perché non facendolo, dubito riceverete risposta ai vs. quesiti.. potrete invece fare recedere gli "anziani" del ng, dal proposito di continuare ad aiutare chi si trova in difficoltà.. meditare, gente, meditare!).
Ringrazio per il sostegno ricevuto
(anche se si fosse trattato di solo sostegno morale è stato gradito
e bene accetto! ;-D), i consigli e le varie modifiche nonché per
le correzioni apportate, Lorenzo Colò,
Davide Veneziano,
Gerardo Cacciari e tutti gli altri, numerosissimi, ma che qui per brevità
non riporto. A tutti grazie! L’autore.
~*~
Ah! Dimenticavo.. E’ inutile che adesso mi riempiate la casella di posta per sapere come ovviare al dubbio x o a quello y che vi sono sorti leggendo questa faq! O meglio è utile e vi invito anche a farlo, ma solo a patto che vi siate PRIMA guardati tutti i documenti a riguardo reperibili sulla rete ed ottenibili inserendo in un qualunque motore di ricerca l’argomento in questione! In particolare poi risulterebbero utili a mio avviso tutti quelli che sono agilmente reperibili grazie ai link sparsi per questa faq.. ;-)
Gli approfondimenti mi interessano e sono apprezzati.. imboccare i bimbi dell’asilo invece non mi interessa affatto! Lo lascio fare alla mia ragazza se ne ha pazienza e voglia ed altrimenti.. ciccia! ;-)
D’altra parte io sono Pierino la peste, mica la confraternita della misericordia.. ;-D
In alternativa però
potrebbe esserci sul ng (ichm), qualche volenteroso disposto ad imboccarvi..
al limite provate anche lì.. non si sa mai! ;-)))
~*~ CIAO! ~*~