Condividi:        

Problema flusso dati LAN

Se il modem non funziona, hai problemi con la scheda video o non sai che processore scegliere entra qui!!

Moderatori: m.paolo, Caffey

Postdi verbal666 » 07/02/04 07:59

pjfry ha scritto:io una prova con l'mtu la farei :D


l'ho già fatta pj... non te l'ho postato, ma è stata la prima prova prima di cambiare la nic su linux e fare tutti i vari "straslochi" descritti nell'ultimo mio post qua :(

ho provato con valori bassi, poi ho alzato fino a 1500, ma nisba...... non cambia proprio NULLA!!! c'è sempre quel blocco che si disattiva non appena collegato il portatile sullo switch.... assurdo, ma vero!!! :eeh:
!sto con Windows, ma amo Linux! ;)
Immagine
http://www.verbal.it
verbal666
Utente Senior
 
Post: 693
Iscritto il: 27/12/02 12:13

Sponsor
 

Postdi pjfry » 07/02/04 14:38

ah ok... allora non c'è altro da fare che lanciare lo switch da una finestra :diavolo: :D
Avatar utente
pjfry
Moderatore
 
Post: 8240
Iscritto il: 19/11/02 17:52
Località: terni

Postdi piercing » 07/02/04 15:15

prova a utilizzare le porte dello switch in tutte le combinazioni possibili... magari è ancora salvabile...

ne ho qualcuno molto lowcost da 8 porte in cui ancora 2 o 3 funzionano perfettamente...
Avatar utente
piercing
Moderatore
 
Post: 7569
Iscritto il: 10/04/02 10:34
Località: Roma

Postdi pjfry » 07/02/04 15:31

e se prendi un hub e lo attacchi allo switch al posto del terzo pc, tanto per terminare il circuito?

(se ti interessa un pò di mtu qui trovi qualche spiegazione in +)
Avatar utente
pjfry
Moderatore
 
Post: 8240
Iscritto il: 19/11/02 17:52
Località: terni

Postdi verbal666 » 07/02/04 22:34

Ragazzi, clamoroso, ma vero.... trovato il colpevole!
A fronte di tutte le manovre fatte, mi restava un'unica, ultima, decisiva prova prima di riportare lo switch (povero, è sanissimo) a far sostituire..... l'unica prova che ancora non avevo fatto, fidandomi al 100%! E invece proprio lì casca l'asino........

Realtek RTL8139/810x Family Fast Ethernet NIC

integrata sulla mobo (ECS K7VTA3 v3) di PC2 (XP, driver aggiornatissimi al 15/01/04)

dopo il malfunzionamento della rete mi sono limitato ad aggiornare agli ultimi driver, mai mi è venuto in mente potesse avere qualche problema.. invece.........

ora ho installato una ibm su pci.... risultato: nessun delay e pacchetti che vanno e vengono (ping <1ms regolare)........

non mi do per spacciato, nei prox gg provo a cambiare l'irq della lan integrata (ora sull'11, lo provo a portare sul 5)... è un peccato non poterla recuperare!!!
!sto con Windows, ma amo Linux! ;)
Immagine
http://www.verbal.it
verbal666
Utente Senior
 
Post: 693
Iscritto il: 27/12/02 12:13

Postdi kadosh » 07/02/04 23:01

Ho letto ora tutto di un fiato il Topic....avvincente direi :D

Mi pare chiaro ci fosse un problema HW in qualche apparato di rete. Approfitto per postarvi un pezzo di un articolo che ho scritto per una rivista informatica, parla di ADSL, MTU e roba utile, ho visto che non avete le idee chiare :P

------------------------------------------------------------------------------------

Molta gente si chiede se il contratto sottoscritto con il proprio Provider Internet per la linea ADSL rispecchi i vincoli posti nell'offerta, e principalmente che le velocità dichiarate, sia in download che in upload, raggiungano quelle dichiarate nel contratto. Però forsesolo in pochi sanno che le velocità descritte nel prospetto informativo sono esclusivamente teoriche, e la differenza non è così sottile come si vorrebbe far credere. Varrebbe a dire che il moto di caduta di una goccia di pioggia, teoricamente dovrebbe essere rettilineo, ma praticamente è soggetto all'attrito dell'aria, alla rotazione terrestre, alla sua gravità e a tanti altri fattori fisici che per integrarli tutti occorre un'equazione matematica di non facile risoluzione.
La fisica entra anche in questo campo dell'informatica con una ben precisa legge, enunciata nel 1948 da Claude E. Shannon: la capacità di un canale di comunicazione dipende dalla sua ampiezza di banda (lo spettro di frequenze che usa) e dal suo rapporto segnale/rumore (dipendente dalla qualità della connessione). Tradotta in formula si scrive C=BxLogbase2(s/r+1) dove B è l'ampiezza di Banda in Hertz ed s/r il rapporto segnale/rumore. E' fisicamente impossibile superare questo limite.

La tecnologia DSL (Digital Subscriber Line) non è altri che una comune linea telefonica usata come canale a grande ampiezza di banda, sul breve percorso tra l'utente finale e la centralina. Viene inoltre fatta una codifica multilivello del segnale per migliorare ulteriormente le prestazioni.
In quel che ho detto c'è però il nodo centrale di tutta la questione, cioè il "breve percorso fra l'utente e la centralina". L'ISP infatti garantisce la sua offerta nel tratto di linea a lui competente, tutto il resto, quella "piccola" rete che è Internet quindi, è al di fuori delle garanzie.

Per cercare di capire meglio la questione occorre accennare ad un minimo di teoria del Routing (Instradamento), ovvero di quel processo che permette alla centralina dell'ISP (Internet Service Provider), solitamente un Router o un PC che agisce da tale, di andare su di un sito Internet compiendo il percorso minore. Ogni volta che fate una richiesta di un sito internet(URL), la vostra richiesta viene indirizzata attraverso un Router, apparecchio che si occupa di smistare il traffico della rete e reindirizzarlo verso la meta richiesta, il quale fa un controllo al suo interno sulle cosiddette tabelle di routing (un Tuttocittà se vogliamo), fra gli indirizzi che conosce, se può inoltrarvi direttamente lui alla pagina che chiedete oppure rimandarvi ad un Router che conosce la locazione esatta della risorsa cercata; questo si ripete fino a che non venga completata la vostra richiesta.
Come ben immaginate, i tratti di rete che la vostra richiesta ha affrontato possono essere davvero parecchi. Dunque la velocità con cui la pagina vi torna indietro dipende dalle singole velocità dei tratti superati, i quali non sempre sono la via più breve ma solamente quella più "scarica" di segnali e richieste, e non sempre i percorsi sono tutti connessi ad una velocità superiore a quella con cui inoltrate la vostra pagina.

Detto ciò, misurare la velocità di una connessione Internet significa misurare la connessione di ogni singola tratta affrontata, per poi dividerla per i vari tratti superati. In pratica questo fanno i migliori Tools disponibili online per calcolare la vostra velocità di connessione.
Tra questi mi piace segnalare:

http://help.virgilio.it/velox/

e

http://www.bandwidthplace.com/speedtest/

Il risultato che infine otterrete sarà molto vicino alla vera natura della vostra connessione, ma non terrà mai conto dei vari fattori perturbanti che esistono ed esisteranno a lungo nelle linee di comunicazione dati, come il traffico dei pacchetti, la ridondanza degli stessi, il carico subito dai router e la portata delle connessioni del vostro stesso ISP.

Vediamo ora come implementare la nostra connessione ADSL per collegarsi ad internet.
E' necessario che prima di entrare nel dettaglio delle configurazioni, accenni brevemente due concetti fondamentali nel trasporto dei dati: MTU e RWIN.

MTU è un acronimo che sta per Maximum Transfer Unit, ovverosia Massima Unità di Trasferimento. Per scanbiare le informazioni da un pc ad un altro il protocollo tcp/ip prevede che le informazioni siano inserite all'interno di quelli che vengono definiti "pacchetti". Facciamo un esempio: se dovete effettuare un trasloco dalla casa X alla casa Y per trasferire gli oggetti che si trovano nella casa X questi dovranno essere imballati all'interno di scatole le quali scatole possono essere di varie dimensioni. Stessa cosa accade su internet: per trasferire informazioni da un pc ad un altro le informazioni devono essere "inserite" all'interno di una scatola ovvero di un pacchetto. L'mtu stabilisce la dimensione di questo pacchetto. Tornando al nostro esempio del trasloco è evidente che se dovete traslocare una intera casa non sarebbe comodo effettuare l'imballaggio in scatole di 10cm x 10 cm, ma è necessario utilizzare scatole di dimensioni il più grande possibile. D'altro canto è anche vero che una scatola grossa è pesante e la velocità con cui viene spostata dalla casa X alla casa Y sarà maggiore rispetto ad una scatola piccola. Stesso discorso vale anche per internet e per l'mtu. Utilizzare un mtu alto incrementa la velocità di download ma allo stesso tempo aumenta i tempi di latenza mentre un mtu basso diminuisce la velocità di download ma allo stesso tempo diminuisce i tempi di latenza. Il discorso in realtà è molto semplificato dal fatto che l'obsolescenza del protocollo tcp/ip consente oggi di fissare un mtu massimo relativamente basso ovverosia soltanto 1500 bytes. Se pensiamo che un file da 1 megabyte è composto da 1 milione di bytes possiamo capire come questo valore sia oggi decisamente inadeguato. In sostanza se avete oggi una connessione ADSL vi conviene sicuramente portare il valore MTU al massimo consentito, con un'unica eccezione che riguarda coloro che usano la linea ADSL principalmente per videogiocare: per costoro potrebbe essere conveniente utilizzare un mtu relativamente basso (576 byte), poichè le informazioni che devono essere trasmesse attraverso la rete non sono generalmente molte, mentre è fondamentale per avere una connessione di gioco veloce avere bassi tempi di latenza.

Anche RWIN è un acronimo, sta per Receive WINdow. Ancora una volta dobbiamo rifarci al TCP/IP per capire di cosa si tratta. Vi siete mai chiesti come fa il vostro computer ad assicurarsi che i pacchetti trasmessi tramite internet non contengano errori e che il file da voi scaricato non sia corrotto?

Il meccanismo funziona così: il computer A vuole scaricare un file dal computer B. I 2 computer entrano in contatto e A rivolge la richiesta a B. A questo punto B comincia a spedire i pacchetti quando A li riceve manda indietro a B una sorta di "notifica di avvenuta ricezione" (la quale notifica è chiamata pacchetto ACK (Acknowlegement packets) ). Se B dovesse aspettare ogni volta di ricevere da A la notifica prima di spedire il successivo pacchetto questo compotrebbe un sistema piuttosto inefficiente. Per questo motivo è stata implementato l'RWIN: Quando i 2 computer entrano in contatto A avverte B che anche se non riceve la notifica può continuare a spedire pacchetti finchè la dimensione dei pacchetti non ha raggiunto un certo valore rappresentato appunto dall'RWIN senza aver ricevuto alcuna notifica. Ora è evidente che una linea ADSL è in grado di spedire/ricevere un numero di pacchetti decisamente superiore a quella di un modem analogico. Il rischio, dunque, se si ha un basso RWIN è che nel tempo che il nostro computer impiega a spedire la notifica il computer B abbia già spedito sufficienti pacchetti da aver superato la soglia dell'RWIN e come conseguenza si sia fermato in attesa di ricevere la notifica ack. Al fine di evitare inutili interruzioni diventa quindi fondamentale incrementare adeguatamente l'RWIN. Questa esigenza diventa ancora più pressante se la nosta linea ADSL ha alti tempi di latenza, in tal caso vorrà dire che impiegherà più tempo a far arrivare al computer B la notifica ACK e in questo lasso di tempo il computer B, se ha raggiunto la soglia dell'RWIN, smetterà di trasferire pacchetti al computer A.

La situazione è aggravata dal fatto che il settaggio di default di Windows è particolarmente basso (8000 byte quando il valore massimo è 65.535 byte). Modificare l'RWIN diventa dunque una esigenza fondamentale per ottimizzare le prestazioni ADSL. La soluzione migliore è quella di cercare l'rwin che garantisca da un lato uno streaming continuo di pacchetti senza interruzioni per attendere le notifiche ack, e dall'altro lato che sia il più basso possibile per evitare attese troppo lunghe prima di accorgersi della necessità di dover rispedire il tutto in caso di packet loss (perdita di pacchetti).

I fattori che entrano in gioco per calcolare l'rwin sono da un lato la velocità del nostro collegamento (perchè un collegamento più veloce vuol dire spedizione di molti più pacchetti nello stesso lasso di tempo e quindi necessità di un rwin più capiente) e dall'altra la latenza della nostra linea (poichè il tempo che il nostro computer impiega per spedire le notifiche ack se maggiore comporterà anche un maggior numero di pacchetti spediti nel suddetto lasso di tempo e quindi la necessità di un rwin più capiente).

Vi consiglio di utilizzare questa equazione per calcolare l'rwin ideale:

Tempo di ping medio aumentato del 50% moltiplicato Velocita della propria connessione in kbit diviso 8.

Qual è la velocita della mia linea in kbit?
Basta controllare il contratto che si è stipulato, di solito è 640 Kilobit, ma a seconda del Provider può variare in altri valori come 256, 320 e altri ancora.

Qual è il mio tempo di ping?
Il tempo di ping o latenza varia a seconda del sito che contattate. Per sapere quant'e' nei confronti di un determinato sito fate: Menu Avvio --> Programmi --> Prompt di Msdos --> digitate ping <nome sito> ad es ping http://www.yahoo.it.

In basso troverete scritto tempo approssimativo percorsi andata/ritorno in millisecondi minimo massimo e medio. Fate un po' di prove con i siti che siete soliti visitare e calcolate il ping medio ottenuto. Aumentatelo del 50% e avrete il vostro valore.

Per modificare i valori, in ambiente Windows vi consiglio questo programma, DoctorTCP scaricabile da
http://www.dslreports.com/drtcp

Il programma in pratica va ad agire direttamente su delle chiavi di registro che per i non esperti sono difficili da trovare e modificare.
Una volta lanciato il programma cliccate nella finestrella bianca affianco a Tcp Receive Window e inserite il valore che preferite, anche se in molti consigliano di lasciare il valore 8000 in caso di ADSL con velocità inferiore a 640 kbit. Cliccate il tasto Apply e poi il tasto Exit e riavviate il computer.

E gli altri valori modificabili con DoctorTCP?

Window Scaling: va bene il settaggio di default ovvero off salvo che non vogliate settare un RWIN superiore a 65535. In quest'ultimo caso se avete Win95 o 98 dovete pure applicare una patch per il file vtcp.386

Time Stamping: in linea di massima va bene il settaggio di default ovvero off. Tuttavia se avete una linea dove la latenza può variare moltissimo oppure una connessione satellitare può valere la pena settarla su on.

Selective Acks: consente la ritrasmissione dei soli pacchetti andati perduti. Il settaggio di default è on quindi lasciatela com'è salvo che non abbiate come sistema operativo Win95 o WinNt dov'e' è settata su off in tal caso attivatela su on.

Path MTU Discovery: consente al sistema operativo di individuare da solo im migliore MTU da utilizzare. E' gia' settato su on su tutti i sitemi operativi tranne Win95. Non serve a niente se avete impostato la mtu manualmente.

Black Hole Detection: serve a far funzionare in modo ottimale la mtu discovery, di default è disattivato. Potete attivarlo ma non serve a niente se avete impostato la mtu manualmente.

Max. Duplicate ACKs: serve a stabilire quanti pacchetti di acknowledge (conferma) deve inviare il sistema al massimo per comunicare la ricezione. alzandolo consente una più rapida ritrasmissione dei pacchetti ma anche un maggiore uso della banda di upload. Se avete una linea molto stabile potresti diminuire il valore a 1 ma in linea di massima vanno bene i settaggi di default che sono 3 in Win98/98SE/ME, 2 in WinNT/2K/XP, e N/A in Win95.

TTL: il massimo numero di nodi attraverso il quale può passare un pacchetto prima di essere considerato perso. Il settaggio di default è 128 quindi va più che bene. Se avete Win95 il settaggio di default è 32.

ICS: serve per chi usa la internet connection sharing, lasciatelo vuoto.

Se volete modificare il valore di MTU a mano, potete raggiungerlo digitando Regedit da Avvio ---> Esegui ---> Regedit e quindi andate a cercare la seguente chiave di registro (per windows 2ooo/XP):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{nome_chiave_con_IP_Internet}

Se volete modificare MTU ed RWIN per Linux eccovi i modi.

PER SAPERE QUANTO VALGONO:
per l'mtu (in un terminale)
ifconfig
poi cercatelo nell'interfaccia appropriata

per l'rwin
aprite con l'editor che piu' vi piace
/proc/sys/net/core/rmem_max
/proc/sys/net/core/rmem_default


PER MODIFICARLI
premessi i soliti
"fallo a tuo rischio e pericolo"
e
"non ti prometto che funzioni"

per l'mtu (in un terminale)
ifconfig [interfaccia] mtu [valore]
esempio
ifconfig eth0 mtu 1500

per l'rwin (in un terminale)
echo [valore] > /proc/sys/net/core/rmem_max
echo [valore] > /proc/sys/net/core/rmem_default
con al posto di [valore] un numero

PRIMA di modificare l'rwin suggerirei un backup dei due file con
cp /proc/sys/net/core/rmem_max /[percorsohome]/rmem_max.bak
cp /proc/sys/net/core/rmem_default /[percorsohome]/rmem_default.bak
ovviamente con un percorso valido al posto di [percorsohome]
invertite i due percorsi per ripristinare i file



...sperando di aver scritto tutto per bene....:)

By KaDoSh
Ch®is ˜˜ www.glgroup.it˜˜ {~Up You® Life~}™ Semper Fidelis
Avatar utente
kadosh
Moderatore
 
Post: 3791
Iscritto il: 24/09/01 01:00
Località: Roma

Postdi verbal666 » 07/02/04 23:08

grazie gran mago delle reti ;)
!sto con Windows, ma amo Linux! ;)
Immagine
http://www.verbal.it
verbal666
Utente Senior
 
Post: 693
Iscritto il: 27/12/02 12:13

Postdi verbal666 » 08/02/04 09:28

mi resta solo da capire PERCHE'

:arrow: collegando un terzo pc allo switch anche la nic "difettosa" torna a funzionare :?:
:arrow: con un cavo cross (circa 1.5mt) non vi è alcun problema :?:

facendo due conti sembra che la nic integrata non vada d'accordo con lo switch...........
!sto con Windows, ma amo Linux! ;)
Immagine
http://www.verbal.it
verbal666
Utente Senior
 
Post: 693
Iscritto il: 27/12/02 12:13

Postdi pjfry » 08/02/04 16:11

azz... allora l'mtu è un parametro dell'IP :D
però mi ricordavo bene almeno una cosa, ho controllato... 1500 byte è la dimensione massima consentita da ethernet, quindi se la frammentazione avvenisse con una dimensione maggiore i pacchetti andrebbero persi, o no?? :roll:
Avatar utente
pjfry
Moderatore
 
Post: 8240
Iscritto il: 19/11/02 17:52
Località: terni

Precedente

Torna a Assistenza Hardware


Topic correlati a "Problema flusso dati LAN":


Chi c’è in linea

Visitano il forum: Nessuno e 59 ospiti