ETH0 : Collisioni e errori durante UPLOAD e DOWNLOAD sincroni - Pagina 3

AnonimoVeneziano · 11-10-2003, 14:56

Ao, ho sparato a caso

Comunque usando la velocità minima di 10Mbit in Half duplex, secondo te se piazzassi il tutto a 100Mbit in FUll Duplex che cosa otterrei?

Ciao

Mason · 11-10-2003, 15:42

Secondo me ha ragione vicius.
Nel protocollo ethernet supporta le collisoni, ovvero i segnali sul cavo possono interferire.
e del tutto normale per ethernet, ma le collisioni non dovrebbero presentarsi nei casi di connessione full duplex:

2 comonenti in rete con connessione fullduplex: ci sono 2 canali separati per ricevere e per trasmettere, le collisioni non accadono in quanti si usano prorpio fili spearati(infatti di solito il cavo si incrocia per far concidere trasmissione id 1 con ricezione dell'altro e vicecersa).
connessioni tramite switch. qui dovrebbe essere lo switch che si occupa di gestire i canali verso i vari comunicanti, gestendo una coda, e non dovrebbe floddare su tutte le porte(mi pare), sempre che le connessioni alle singole porte siano in full duplex.

Le collisioni sono invece inevitabili su halfduplex, in quanto il protocollo non ha possibilita' di sapere qaundo uno dei 2 partecipanti decidera di spedire,e disponendo di un solo canale magari i due pacchetti cocciano generando una collisiione,a quel punto i 2 rilevano la collisone e decidono di ritrasmettere il pacchetto dopo un certo tempo t(detto semplicisticamente).

Se la il tuo collegamento rimane half duplex penso che gli "errori" rimangano.

AnonimoVeneziano · 11-10-2003, 15:47

SI, ma con certi kernel non avvengono , mentre con certi altri avvengono (con tutti i VANILLA avvengono per esempio , con il nuovo 2.6.0-test7 e con il 2.4.21-Gentoo no ) .

Questa è la cosa strana . Inoltre ogni tanto mi ritrovo degli errori (ogni 100000 pacchetti circa) anke questo è normale?

Sembra che tu di ethernet te ne intendi (al contrario di me che ,devo ammetterlo , sono un po' a digiuno di connessioni di rete

) , secondo te su 630000 pacchetti ricevuti è normale la comparsa di 6 errori?

Ciao

VICIUS · 11-10-2003, 16:01

Quote:

Originariamente inviato da AnonimoVeneziano
SI, ma con certi kernel non avvengono , mentre con certi altri avvengono (con tutti i VANILLA avvengono per esempio , con il nuovo 2.6.0-test7 e con il 2.4.21-Gentoo no ) .

Questa è la cosa strana . Inoltre ogni tanto mi ritrovo degli errori (ogni 100000 pacchetti circa) anke questo è normale?

Sembra che tu di ethernet te ne intendi (al contrario di me che ,devo ammetterlo , sono un po' a digiuno di connessioni di rete

) , secondo te su 630000 pacchetti ricevuti è normale la comparsa di 6 errori?

Ciao

forse è solo un caso che su alcuni kernel tutto funziona oppure è questione di timings o chissa cosa. se hai voglia di sbatterti prendi il 2.4.21-gentoo e il 2.4.21-vanilla e fai una bella diff poi ti diverti a cercare qualcosa che interferisca con la rete o il tuo driver

secondo me 1.4 errori su 1 _MILIONE_ di pachetti è un errore piu che accetabile

se vuoi approfondire un po la tua conoscenza della rete e ethernet qui c'è il sito del libro del mio ex-prof di sistemi: http://www.ingmonti.it/libri/ -> Parte 4: "Reti di computer" -> "8 Ethernet".

ciao

AnonimoVeneziano · 11-10-2003, 16:05

Quote:

Originariamente inviato da VICIUS
forse è solo un caso che su alcuni kernel tutto funziona oppure è questione di timings o chissa cosa. se hai voglia di sbatterti prendi il 2.4.21-gentoo e il 2.4.21-vanilla e fai una bella diff poi ti diverti a cercare qualcosa che interferisca con la rete o il tuo driver

secondo me 1.4 errori su 1 _MILIONE_ di pachetti è un errore piu che accetabile

se vuoi approfondire un po la tua conoscenza della rete e ethernet qui c'è il sito del libro del mio ex-prof di sistemi: http://www.ingmonti.it/libri/ -> Parte 4: "Reti di computer" -> "8 Ethernet".

ciao

Ehm , guarda che 100000 non è un_milione , ma Centomila, è accettabile ankora?

CIao

PS= Grazie per il link , ci vado subito!

Mason · 11-10-2003, 16:05

diciamo che le ho studiate.

Per il kernel, controlla nel dmesg come si settano le varie connessioni

eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.

magari qualche kernel ha un supporto migliore per le possibilita della tua scheda.

a quanto pare il modem puo supportare il full duplex in quanto su alcuni kernel funge.
Probabilmente e il supporto per la tua scheda.
se guardi nei changelog magari trovi qualche patch per apliare le possibilita della tua realtek

AnonimoVeneziano · 11-10-2003, 16:11

La scheda si setta in Half-Duplex automaticamente con questo modem , e inoltre se la piazzo in Full-Duplex le collisioni si trasformano in errori

(anke se comunque gli errori sono molti meno delle collisioni , ma si alzano molto velocemente per essere errori) . A 100Mbit non va ne in Half ne in Full Duplex con questo modem .

Ovviamente ho già fatto Diff e controllato i Changelogs dei vari drivers, ma il Diff da driver a driver è veramente grosso , e in questo momento ho un mal di testa galattico

, e il change log non mi sembra dire niente di interessante per quel che riguarda il mio problema...

VICIUS · 11-10-2003, 16:11

Quote:

Originariamente inviato da AnonimoVeneziano
Ehm , guarda che 100000 non è un_milione , ma Centomila, è accettabile ankora?

CIao

PS= Grazie per il link , ci vado subito!

questa volta ho caziato io

in ogni caso sopra a ethernet ci sono sempre ip e tcp. non dovresti perdere alcun dato.

ciao

AnonimoVeneziano · 11-10-2003, 16:17

Quote:

Originariamente inviato da VICIUS
questa volta ho caziato io

in ogni caso sopra a ethernet ci sono sempre ip e tcp. non dovresti perdere alcun dato.

ciao

Si , ma in genere come dovrebbe essere ? insomma, io non ho ankora capito se la mia situazione è :

1-Normale

2- Così Così

3- Un disastro totale

Insomma, è questo che non ho capito, perchè non ho esperienza di reti Ethernet

Ciao

AnonimoVeneziano · 11-10-2003, 16:40

I 2 diff (2.4.22-bk33 e 2.6.0-test7) sono + simili di quanto pensavo :

Codice:

112a113
> #include <linux/suspend.h>
131c132
< /*#undef RTL8139_DEBUG*/
---
> #undef RTL8139_DEBUG
134c135
< /*#undef RTL8139_NDEBUG*/
---
> #undef RTL8139_NDEBUG
716c717
<       kfree (dev);
---
>       free_netdev(dev);
762a764
>       SET_NETDEV_DEV(dev, &pdev->dev);
1583,1591c1585,1586
<       daemonize ();
<       reparent_to_init();
<       spin_lock_irq(&current->sigmask_lock);
<       sigemptyset(&current->blocked);
<       recalc_sigpending(current);
<       spin_unlock_irq(&current->sigmask_lock);
<
<       strncpy (current->comm, dev->name, sizeof(current->comm) - 1);
<       current->comm[sizeof(current->comm) - 1] = '\0';
---
>       daemonize("%s", dev->name);
>       allow_signal(SIGTERM);
1596a1592,1594
>                       /* make swsusp happy with our thread */
>                       if (current->flags & PF_FREEZE)
>                               refrigerator(PF_IOTHREAD);
1600d1597
<                       spin_lock_irq(&current->sigmask_lock);
1602d1598
<                       spin_unlock_irq(&current->sigmask_lock);
2152c2148
<       synchronize_irq ();             /* racy, but that's ok here */
---
>       synchronize_irq (dev->irq);     /* racy, but that's ok here */
(END)

Io però non vedo roba che centri molto con le collesioni , sembra tutto riferito agli IRQ...

Qualcuno vede qualcosa che non ho visto?

AnonimoVeneziano · 11-10-2003, 17:40

Ecco un esempio di errore .

Come vedete non è sempre preciso , è più è meno 100000 :

eth0 Link encap:Ethernet HWaddr 00:40:F4:55:9D:95
inet addr:192.168.254.1 Bcast:192.168.254.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:90327 errors:1 dropped:0 overruns:0 frame:0
TX packets:97820 errors:0 dropped:0 overruns:0 carrier:0
collisions:2328 txqueuelen:1000
RX bytes:32692035 (31.1 Mb) TX bytes:65225918 (62.2 Mb)
Interrupt:17 Base address:0x8f00

Ciao

VICIUS · 11-10-2003, 18:35

Anonimo alla fine se rimani con half-duplex avrai sempre il rischio di collisioni con qualsiasi kernel tu usi, è una conseguenza dell'architetura di ethernet. anche gli errori sono previsti e in caso di pachetto dannegiato il modem te lo rispedisce.

certo che se gli errori e le collisioni superano una certa soglia forse è il caso di incominciare a preoccuparsi.

quindi metti il cuore in pace e lascia stare i poveri sviluppatori del kernel.

ciao

AnonimoVeneziano · 11-10-2003, 19:12

Quote:

Originariamente inviato da VICIUS
Anonimo alla fine se rimani con half-duplex avrai sempre il rischio di collisioni con qualsiasi kernel tu usi, è una conseguenza dell'architetura di ethernet. anche gli errori sono previsti e in caso di pachetto dannegiato il modem te lo rispedisce.

certo che se gli errori e le collisioni superano una certa soglia forse è il caso di incominciare a preoccuparsi.

quindi metti il cuore in pace e lascia stare i poveri sviluppatori del kernel.

ciao

Si , ma perchè con certi si e certi altri no!!!!! Io li ammazzo tutti!!!!!!

Scoperchiatore · 11-10-2003, 19:30

Quote:

Originariamente inviato da VICIUS
Anonimo alla fine se rimani con half-duplex avrai sempre il rischio di collisioni con qualsiasi kernel tu usi, è una conseguenza dell'architetura di ethernet. anche gli errori sono previsti e in caso di pachetto dannegiato il modem te lo rispedisce.

certo che se gli errori e le collisioni superano una certa soglia forse è il caso di incominciare a preoccuparsi.

quindi metti il cuore in pace e lascia stare i poveri sviluppatori del kernel.

ciao

veramente se è in ethernet 2.0 o csma/cd lo standard non prevede ritrasmissione dei pacchetti danneggiati (danneggiati nel senso che il fcs non corrisponde, non nel senso della collisione)...

ma vai oltre i 16 tentativi "critici"? (sottolineo, non ho letto il thread, quindi se gli standard non sono quelli, (csma/cd o ethernet / fast ethernet etc..) le cose saranno diverse!

AnonimoVeneziano · 11-10-2003, 19:33

Quote:

Originariamente inviato da Scoperchiatore
veramente se è in ethernet 2.0 o csma/cd lo standard non prevede ritrasmissione dei pacchetti danneggiati (danneggiati nel senso che il fcs non corrisponde, non nel senso della collisione)...

ma vai oltre i 16 tentativi "critici"? (sottolineo, non ho letto il thread, quindi se gli standard non sono quelli, (csma/cd o ethernet / fast ethernet etc..) le cose saranno diverse!

Ma vaffanc.... Tutto il lavoro persuasivo di VICIUS l'hai distrutto in 1 millisecondo , sei un demone!

Scoperchiatore · 11-10-2003, 21:29

Quote:

Originariamente inviato da AnonimoVeneziano
Ma vaffanc.... Tutto il lavoro persuasivo di VICIUS l'hai distrutto in 1 millisecondo , sei un demone!

vabbè, se stai con l'ADSL magari non utilizzi proprio quello standard....

anzi, è probabile...

VICIUS · 11-10-2003, 22:30

Quote:

Originariamente inviato da Scoperchiatore
veramente se è in ethernet 2.0 o csma/cd lo standard non prevede ritrasmissione dei pacchetti danneggiati (danneggiati nel senso che il fcs non corrisponde, non nel senso della collisione)...

ma vai oltre i 16 tentativi "critici"? (sottolineo, non ho letto il thread, quindi se gli standard non sono quelli, (csma/cd o ethernet / fast ethernet etc..) le cose saranno diverse!

si ethernet ritrasmette solo i pachetti che vanno in collisione. ma nei frame ethernet ci viaggiano dei pachetti tcp/ip. se succede un errore ci pensa lui a richiedere la trasmissione.

ciao

AnonimoVeneziano · 11-10-2003, 22:37

Quote:

Originariamente inviato da VICIUS
si ethernet ritrasmette solo i pachetti che vanno in collisione. ma nei frame ethernet ci viaggiano dei pachetti tcp/ip. se succede un errore ci pensa lui a richiedere la trasmissione.

ciao

Comunque , guarda un po'

Sembra che sia un momento fortunato questo , sto scaricando e inviando a pala con questi risultati

Codice:

eth0      Link encap:Ethernet  HWaddr 00:40:F4:55:9D:95
          inet addr:192.168.254.1  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:231670 errors:0 dropped:0 overruns:0 frame:0
          TX packets:239952 errors:0 dropped:0 overruns:1 carrier:0
          collisions:877 txqueuelen:1000
          RX bytes:107386093 (102.4 Mb)  TX bytes:131993742 (125.8 Mb)
          Interrupt:17 Base address:0x6f00

Nessun errore e solo 877 collisioni su 249952 inviati

Mha , mistero del Caos...

AnonimoVeneziano · 11-10-2003, 22:39

Comunque credo che le collisioni siano causate dall' Half-Duplex , per quanto riguarda gli errori... bho, sono moooolto sporadici ultimamente , comunque non vedo l'ora esca il 2.6.0.... mi sa che c'è qualcosa di diverso proprio nella gestione del protocollo , non solo nel driver in se...

VICIUS · 11-10-2003, 22:47

Quote:

Originariamente inviato da AnonimoVeneziano
Mha , mistero del Caos...

Una farfalla sbatte le ali a New York ed il modem di AnonimoVeneziano genera un errore...

non ti resta che uccidere la farfalla.

ciao

11-10-2003, 14:56	#41
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	Ao, ho sparato a caso Comunque usando la velocità minima di 10Mbit in Half duplex, secondo te se piazzassi il tutto a 100Mbit in FUll Duplex che cosa otterrei? Ciao __________________ GPU Compiler Engineer

11-10-2003, 15:42	#42
Mason Senior Member Iscritto dal: Nov 2002 Città: Morbegno (SO) Messaggi: 1410	Secondo me ha ragione vicius. Nel protocollo ethernet supporta le collisoni, ovvero i segnali sul cavo possono interferire. e del tutto normale per ethernet, ma le collisioni non dovrebbero presentarsi nei casi di connessione full duplex: 2 comonenti in rete con connessione fullduplex: ci sono 2 canali separati per ricevere e per trasmettere, le collisioni non accadono in quanti si usano prorpio fili spearati(infatti di solito il cavo si incrocia per far concidere trasmissione id 1 con ricezione dell'altro e vicecersa). connessioni tramite switch. qui dovrebbe essere lo switch che si occupa di gestire i canali verso i vari comunicanti, gestendo una coda, e non dovrebbe floddare su tutte le porte(mi pare), sempre che le connessioni alle singole porte siano in full duplex. Le collisioni sono invece inevitabili su halfduplex, in quanto il protocollo non ha possibilita' di sapere qaundo uno dei 2 partecipanti decidera di spedire,e disponendo di un solo canale magari i due pacchetti cocciano generando una collisiione,a quel punto i 2 rilevano la collisone e decidono di ritrasmettere il pacchetto dopo un certo tempo t(detto semplicisticamente). Se la il tuo collegamento rimane half duplex penso che gli "errori" rimangano. __________________ e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it."

11-10-2003, 15:47	#43
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	SI, ma con certi kernel non avvengono , mentre con certi altri avvengono (con tutti i VANILLA avvengono per esempio , con il nuovo 2.6.0-test7 e con il 2.4.21-Gentoo no ) . Questa è la cosa strana . Inoltre ogni tanto mi ritrovo degli errori (ogni 100000 pacchetti circa) anke questo è normale? Sembra che tu di ethernet te ne intendi (al contrario di me che ,devo ammetterlo , sono un po' a digiuno di connessioni di rete ) , secondo te su 630000 pacchetti ricevuti è normale la comparsa di 6 errori? Ciao __________________ GPU Compiler Engineer

11-10-2003, 16:05	#46
Mason Senior Member Iscritto dal: Nov 2002 Città: Morbegno (SO) Messaggi: 1410	diciamo che le ho studiate. Per il kernel, controlla nel dmesg come si settano le varie connessioni eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. magari qualche kernel ha un supporto migliore per le possibilita della tua scheda. a quanto pare il modem puo supportare il full duplex in quanto su alcuni kernel funge. Probabilmente e il supporto per la tua scheda. se guardi nei changelog magari trovi qualche patch per apliare le possibilita della tua realtek __________________ e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it."

11-10-2003, 16:11	#47
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	La scheda si setta in Half-Duplex automaticamente con questo modem , e inoltre se la piazzo in Full-Duplex le collisioni si trasformano in errori (anke se comunque gli errori sono molti meno delle collisioni , ma si alzano molto velocemente per essere errori) . A 100Mbit non va ne in Half ne in Full Duplex con questo modem . Ovviamente ho già fatto Diff e controllato i Changelogs dei vari drivers, ma il Diff da driver a driver è veramente grosso , e in questo momento ho un mal di testa galattico , e il change log non mi sembra dire niente di interessante per quel che riguarda il mio problema... __________________ GPU Compiler Engineer

11-10-2003, 17:40	#51
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	Ecco un esempio di errore . Come vedete non è sempre preciso , è più è meno 100000 : eth0 Link encap:Ethernet HWaddr 00:40:F4:55:9D:95 inet addr:192.168.254.1 Bcast:192.168.254.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:90327 errors:1 dropped:0 overruns:0 frame:0 TX packets:97820 errors:0 dropped:0 overruns:0 carrier:0 collisions:2328 txqueuelen:1000 RX bytes:32692035 (31.1 Mb) TX bytes:65225918 (62.2 Mb) Interrupt:17 Base address:0x8f00 Ciao __________________ GPU Compiler Engineer

11-10-2003, 18:35	#52
VICIUS Senior Member Iscritto dal: Oct 2001 Messaggi: 11471	Anonimo alla fine se rimani con half-duplex avrai sempre il rischio di collisioni con qualsiasi kernel tu usi, è una conseguenza dell'architetura di ethernet. anche gli errori sono previsti e in caso di pachetto dannegiato il modem te lo rispedisce. certo che se gli errori e le collisioni superano una certa soglia forse è il caso di incominciare a preoccuparsi. quindi metti il cuore in pace e lascia stare i poveri sviluppatori del kernel. ciao

11-10-2003, 22:39	#59
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	Comunque credo che le collisioni siano causate dall' Half-Duplex , per quanto riguarda gli errori... bho, sono moooolto sporadici ultimamente , comunque non vedo l'ora esca il 2.6.0.... mi sa che c'è qualcosa di diverso proprio nella gestione del protocollo , non solo nel driver in se... __________________ GPU Compiler Engineer

Strumenti
Mostra una versione stampabile Invia questa pagina per email