Re: R: [reti-accesso] post backoff


Cronologico Percorso di conversazione 
  • 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?

Emacs!

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...)

Emacs!

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.

§