- From: Giuseppe Bianchi <
>
- To:
, <
>
- Subject: Re: R: [reti-accesso] post backoff
- Date: Wed, 07 Feb 2007 00:16:37 +0100
Faccio un reply sull'email del vostro collega per svelarvi
l'arcano.
Colgo l'occasione di questa domanda
per allegarvi un nostro grafico sperimentale che mostra la distribuzione
del tempo di interarrivo misurato tra due trasmissioni consecutive per
una coppia driver/NIC di un noto vendor. La scheda rispetta lo standard?
Come spiegate questo grafico?

At 23.32 06/02/2007, un vostro collega wrote:
Grafico 1: sembra che il prodotto usi un dado truccato perch¨¦ il 10% dei
back-off cade intorno ai 310¦Ìsec, che ¨¨ il valore medio se tutti i
back-off hanno pari probabilit¨¤, poi i valori tra 16*20 e 31*20 ¦Ìsec
sono estratti in modo abbastanza uniforme mentre sono inesistenti i
back-off minori di 15*20¦Ìsec. Se ¨¨ cos¨¬ credo che non rispetti lo
standard.
Lo standard dice: una stazione aspetta un DIFS (50 us), poi genera un
contatore di backoff nell'intervallo 0-31. Essendo 20us il tempo di slot
mi aspetterei una distribuzione statistica fatta a picchi di uguale
ampiezza su 50 + k*20 con k in 0,31.
Invece, dal grafico notiamo (a parte piccoli errori di sincronizzazione
che sparpagliano un po' i picchi nell'intorno del valore
atteso):
1) c'e' un GROSSO picco in corrispondenza di circa 300 us
2) per il resto la distribuzione e' quella attesa (almeno fino a 650 us,
in teoria dovrebbe essere 670).
Considerando che il costruttore non puo' aver VOLUTO generare questa
distribuzione di backoff, la spiegazione naturale e' la seguente: a causa
di problemi implementativi nella scheda, il tempo necessario per
prelevare una trama dal buffer (della NIC o del driver, a seconda
dell'implementazione) e metterla in posizione HOL per trasmetterla e'
MAGGIORE di quanto uno si aspetta, ed e' di circa (guarda caso) 300 us!
Ora, poiche' la scheda segue CORRETTAMENTE le regole di post-backoff, la
trama viene trasmessa immediatamente in tutti i casi in cui il backoff
counter si e' nel frattempo decrementato (il picco in corrispondenza di
300 us circa rappresenta infatti la SOMMA di tutti i casi in cui il
valode di backoff generato era minore o uguale a 12 o 13, mentre viene
ulteriormente ritardata in tutti i casi in cui il contatore di backoff si
sta ancora decrementando (ovvero tutti i casi in cui inizialmente e'
stato estratto un valore di backoff maggiore di 12 o 13).
In altre parole, questo grafico e' simpatico perche':
1) dimostra sperimentalmente l'esistenza del post-backoff
2) soprattutto dimostra che questa scheda (o piu' probabilmente il
relativo driver) non e' fatta bene.
Carino, vero?
Decisamente piu' difficile: questa e'
la misura fatta per un'altra scheda. Come vedete NON fa backoff!! Hanno
sbagliato clamorosamente a fare la scheda? Oppure qualcuno ha una
spiegazione? (suggerimento 1: quanto fa 16*20? suggerimento 2: non solo
disonesto, ma anche incapace...)

A valle della spiegazione precedente, questa diventa ovvia. La scheda in
realta' e' TAROCCATA (dal costruttore, NB!!): usa infatti una finestra di
collisione minima NON STANDARD (da altre misure, abbiamo rilevato il
valore CWmin=15).
Peccato pero' che l'inefficienza descritta precedente in questo caso sia
addirittura piu' rilevante, e faccia si' che il ritardo sia di
quasi mezzo millisecondo (sembra poco? un'eternita' a questo
livello!). Ovviamente il post.-backoff e' finito in TUTTI i casi
(rammento che con CWmin=15, al peggio la trasmissione doveva avvenire al
tempo 50+15*20 = 350 us). Ecco perche' TUTTE le trame vengono
immediatamente trasmesse e si forma il picco indicato in figura.
A posteriori, posso dirvi che, essendo partiti dall'analisi di QUESTO
caso, e non avendo noi alcun suggerimento, per capirlo ci abbiamo
impiegato mesi!! (inizialmente abbiamo anche pensato che fossero
completamente sbagliate le NOSTRE misure, oppure che la scheda fosse
clamorosamente mal progettata da NON fare alcun backoff!)
----------------------
Per i piu' curiosi vi allego l'articolo che abbiamo appena finito di
scrivere e che documenta queste scoperte. Verra' pubblicato e presentato
a maggio in una delle conferenze piu' prestigiose nel nostro settore
(insomma, avete capito che ne sono particolarmente fiero:-) - e' infatti
frutto di lavoro durissimo e di 3 anni di ricerche). Pertanto se volete,
potete essere i primi a leggerlo!
Attachment:
final01.pdf
Description: Adobe PDF document
Archivio con motore MhonArc 2.6.16.