mmm... ritardi ethernet semplici... 2 mezze giornate per implementarlo... mi viene in mente una qdisc che vidi solo su carta 3-4 anni fa, ma non ne trovai una implementazione pronta.
Io spenderei un'ora per prendere un cavo ethernet, tagliuzzarlo e giuntarlo col saldatore... l'unica cosa a cui devi fare attenzione e' fare saldature piu' simili possibili altrimenti i ritardi sulle coppie differiscono troppo tra una coppia e l'altra. Il risultato, se c'e', non e' misurabile/dosabile... ma e' la cosa piu' rapida che mi viene in mente. Al max puoi procedere per gradi: 2 giunte e misuri, 5 giunte e misuri, ... Altrimenti devi vedere se hai schede di rete o switch con chip realtek di 3-4 anni fa... che sono programmabili al dettaglio... o seguendo la stessa strada puoi dare una smanacciata nel driver della scheda che hai a disposizione; non credo sia particolarmente oneroso in termini di tempo. Il kernel lo lascerei stare... troppo complesso trovare dove mettere le mani... 2 mezze giornte ti servirebbero solo per quello. Dimmi a cosa ti serve, che magari tiro fuori qualosa dal Manuale. ciao Michele Fabio ha scritto: > 2009/1/27 ZioPRoTo (Saverio Proto) <ziopr...@gmail.com> > >>> Conoscete un modo per introdurre un ritardo (anche costante) nei >> pacchetti >>> che transitano attraverso una macchina? >> Prima domanda, pacchetti IP o frames ethernet ? > > > Il mio traffico è TCP/IP, ma mi piacerebbe introdurre ritardo lavorando al > livello ethernet in modo da sembrare solo uno switch all'applicazione che > produce traffico. > > > >> Non ci crederai ma la settimana scorsa stavo affrontando lo stesso problema >> ! >> >> Il mio problema specifico era aspettare un tempo T (dell'ordine di >> grandezza del ms) prima di inviare ogni frame 802.11 sull'interfaccia >> di uscita. >> In pratica volevo inserire una specie di "tempo di guardia" tra i frames. > > > Quindi tu vuoi controllare il numero di frame al secondo che mandi > sull'interfaccia? > Perché invece io sarei più interessato a simulare un ritardo tipo "canale > trasmissivo lungo", cioè un tubo in cui le trame escono X ms dopo essere > entrate, senza intervenire sulla distanza (temporale) tra una trama e > l'altra. Forse anche quello che dici tu potrebbe servirmi, ma mi sembra > comunque un problema diverso. > > >>> Facendo qualche "cerca" sul man non mi sembra che iptables permetta di >>> ritardare i pacchetti; e nemmeno ibtables purtroppo. >> >> Con iptables o ebtables non puoi farlo, te lo garantisco io, perché >> non c'è un target di quel tipo. > > > Peccato perché questa poteva essere una strada facilmente percorribile. > > >> Allora ho chiesto ad Andrea Detti se è possibile farlo con Traffic >> Control di Linux (tc), ma la risposta è stata che non c'è uno >> scheduler già implementato che ha esattamente quel comportamento. >> >> E' possibile però implementare lo scheduler nel Kernel !! Che risorse >> di tempo hai su questo progetto ?? Possiamo vedere di farlo insieme, >> anche se io sono gia stracarico di cose da fare ;) > > > Purtroppo non ho né le risorse né il tempo, al massimo mi concedono due > mezze giornate per fare questa cosa. Qui ogni tanto vengono a chiedermi > qualche nuova questione legata alla rete, senza fornire troppi dettagli sul > problema, e tipicamente si aspettano qualche risposta nel giro di qualche > ora. > Mi aspetto che prima o poi inizieranno a piovermi schiaffi sulla testa. :-( > > >>> Su google ho trovato un IET (http://iet.sourceforge.net/) che farebbe >>> proprio al caso mio: peccato che non sembra più supportato dal 2003 e mi >>> sembra di capire che funziona solo su kernel 2.4... >> >> Mi sembra uno strumento da mettere "in mezzo al cavo" per introdurre >> dei ritardi ... ma ritardi semplici :) > > > Appunto, è proprio quello che vorrei fare io. > Quello che dici tu invece mi sembra, come hai già detto, una questione da > traffic control. Mi ricordo che Sort faceva qualcosa di simile con il > meccanismo del Tocken Bucket, hai provato a vedere se si può usare per i > tuoi scopi? Mi pare che anche Andrea Detti si occupava di questa cosa... > spero che non si ricada nel problema che manca uno scheduler. > > Ma tu, se hai un "treno di frames", devi mettere un ritardo costante a >> tutto il treno ? ovvero devi rallentare solo il primo ? perché questo >> penso che invece sia possibile farlo con il Traffic Control [1]. >> >> Saverio >> >> [1] - http://lartc.org/howto/ >> > > Il link che mi segnali sembra molto interessante, provo a vedere se trovo > quello che sto cercando. Cmq che intendi con rallentare solo il primo? i > pacchetti secondo, terzo, quarto (ecc) possono anche arrivare prima del > primo (che è stato rallentato) oppure subiscono almeno lo stesso ritardo del > primo? che utilità potrebbe avere questa cosa? Mi sembra piuttosto che il > mio caso sia quello di rallentare TUTTO il treno, non si può fare con il > Traffic Control di linux? > > Ciao, > Fabio >
