erlug
[Top] [All Lists]

Re: [Erlug] (no subject)

To: erlug@xxxxxxxxxxxxxx
Subject: Re: [Erlug] (no subject)
From: Ivan Sergio Borgonovo <mail@xxxxxxxxxxxxxxx>
Date: Wed, 5 May 2004 11:25:50 +0200
On Wed,  5 May 2004 08:47:05 +0200
"dragonlair@xxxxxxxxx" <dragonlair@xxxxxxxxx> wrote:

> staccati dal resto della rete) serve a scopo didattico e io ci sto
> facendo su il mio stage (laurea triennale), ragion per cui non posso
> fare altro se non quello che il prof mi dice di fare. Lo so che per
> risolvere il mio problema basterebbe usare il tcp/ip, ma lo scopo
> del mio studio e' proprio quello di verificare le performances di
> raw ethernet. Detto questo, il prof stesso mi ha consigliato di
> usare dei cicli, o delle routine in assempblerper introdurre dei
> ritardi, al solo scopo di capire perche' si perdono dei pacchetti;

O il tuo prof è un genio o va ricoverato.
Ti sei fatto spiegare perchè secondo lui introducendo dei ritardi non
becchi errori?

Non è che una 10Mb viaggi a frequenze diverse se spedisci un pacchetto
ogni tanto, quindi sei ugualmente sensibile ai disturbi.

Vuoi fare la sorpresa ai raggi cosmici?
Tipo esco dalla scheda, esco dalla scheda ora, no tie to fregato
raggio cosmico.

Se le eth sono su uno switch non riesci nemmeno a diminuire
collisioni/throughput, perchè diminuisci anche il throughput in
maniera proporzionale (se il traffico dell'altra roba sullo switch è
costante).

L'unica cosa che mi viene ragionevole pensare tu possa affrontare in
maniera sistematica (ovvero che non c'entra con i raggi cosmici o la
manifestazione del Demonio) è la differenza di velocità tra *2*
schede/PC. Questo lo puoi verificare usando normale TCP/IP e guardando
gli overruns (ifconfig).

Su questa ipotesi puoi farti dei conti considerando il costo di una
correzione di errore in termini di tempo e quindi il ritardo massimo
accettabile. A 100Mbit sei nell'ordine dei microsecondi su pacchetti
magri UDP... se il tuo protocollo è ulteriormente a dieta magari hai
tempi dimezzati ma non cambi l'ordine di grandezza.

E stiamo parlando di *2* schede con un problema identificato... se
sono i raggi cosmici, la variazione di carico sulle macchine, il
Demonio... augurissimi.

L'assembler e i cicli while sono assolutamente fuori discussione per
il fatto che sei in un sistema multitasking e temporizzare qualche
cosa facendo affidamento sui tempi di esecuzione delle istruzioni sui
processori oggi è un nonsense.


Ma qua non c'era q.cuno che stava lavorando proprio su una patch del
kernel per una modifica sullo stack TCP/IP???


<Prev in Thread] Current Thread [Next in Thread>