bisco wrote: > in rete ci sono vari tutorial, fatti piu' o meno bene... > > E allora mi sa che ho beccato io tutti i meno... :D
> prova a dire un po' il problema esatto e magari ti si puo' aiutare meglio... > > Scherzi a parte, è che la situazione è un po' particolare... Praticamente sto realizzando una qdisc (queuing discipline) di tc per la tesi. Questa qdisc serve a quelli dell'univ per un loro testbed di reti UMTS, in particolare io dovrei realizzare la policy per la schedulazione in downstream (cioè dalla base verso i terminali mobili) in un canale condiviso (quindi solo traffico web e mail o simili per capirci, visto che la roba tosta tipo streaming o voip va su canali dedicati). I fatti salienti sono due: - la schedulazione è time-slotted. Praticamente ci sono delle unità di tempo dette TTI (transmition time interval) entro le quali uno ed un solo utente può essere servito. Al prossimo TTI si sceglie un nuovo utente per tutto il TTI e così via; - i terminali mobili UMTS cambiano schema di codifica a seconda del loro rapporto segnale rumore rispetto alla portante della stazione base. Questo implica che in ogni slot c'è un massimo al numero di byte che possono essere inviati ad un utente (Ceil Rate). Queste due condizioni ovviamente implicano che la schedulazione non è conservativa (ovvero è possibile che non venga mandato alcun pacchetto anche se le code non sono vuote). Il che non è mai bello, infatti... La politica di scheduling che mi hanno propinato è la c.d. MaxWeight che funziona così: per ogni TTI k viene schedulato l'utente che massimizza il prodotto Q[k]*CR[k], ove Q[k] è la lunghezza della coda dell'utente all'istante k (ovvero il suo backlog) e CR[k] è il suo ceil rate all'istante k. Poichè la priorità dipende linearmente dalla lunghezza delle code, è banale che l'utente che viene scelto ha sempre qualcosa da mandare (anzi, è proprio per questo che è stato scelto!). L'unica fonte di non conservazione è quindi il Ceil Rate. Infatti supponiamo che decido di mandare all'utente Alice. Alice comincia a ricevere felicemente i suoi pacchetti. Finchè non raggiunge il suo Ceil Rate, è quì sorge il problema. Alice non può mandare, perchè ha raggiunto il Ceil Rate. Nessun altro può mandare, perchè il TTI è assegnato alla sola Alice. Nessuno può mandare. Però la funzione (dequeue, che preleva un pacchetto dalla coda) qualcosa deve ritornare! Infatti io non ho controllo sul fatto che il kernel chiami o meno una funzione di dequeue sul qdisc. L'unica cosa che posso fare è riaccodare il pacchetto 'suverchio' (cioè quello che sforerebbe il Ceil Rate) da dove l'ho preso e ritornare NULL. Ma non finisce quì. Il kernel infatti è furbo, e se riceve un NULL non contiuna a chiamare la dequeue. Solo che al prossimo TTI dovrebbe, senno mi si blocca indefinitamente fino a quando un'altro pacchetto viene accodato dallo strato superiore (e il kernel sa che per ogni pacchetto accodato uno deve essere de-codato). Devo quindi settare un timerino detto 'watchdog' che al prossimo TTI dica al kernel di continuare a chiamare le dequeue sul qdisc. Tale 'cane-di-cancello' l'ho scopiazzato paro paro dal tocken bucket filter del kernel 2.6 che funziona, quindi assumo che funzioni (Aristote perdonami per il sillogismo barocco ma non ho tempo di testare tutto il 2.6 :D). Il problema è il seguente: per qualche motivo (presumo legato a qualche politica di lock) ad un certo punto il kernel smette di accodare nelle code che non siano quella che sta attualmente mandando (cioè se il TTI è di Alice, allore Alice è l'unica che riceve pacchetti accodati dagli strati superiori, e la sua coda è l'unica che aumenta). E poichè è quello con la coda più lunga che manda alla fine si crea un circolo vizioso che mi spu**ana tutto lo scheduling. Peto venia per la mail kilometrica (Biscuttiè, hai capito mo pecchè sevo ghiuto sul vago? :D)... Lunga vita e prosperità a chi potesse darmi una mano. Saluti, B. _______________________________________________ ml mailing list [email protected] http://nalug.net/mailman/listinfo/ml
