On Mon, 2008-12-15 at 17:34 +0100, Miguel Oyarzo O. wrote: > Aldrin Martoq escribió: > > Aca unas pruebas rapidas de mi tarro bajando un archivo de 80MiB con > > wget: > > MTU rate tiempo RX TX # errores > > 1500 1.78MiB/s 45 s 86482 KiB 1757 KiB rx: 38 tx: 0 > > 1500 1.98MiB/s 41 s 86481 KiB 1755 KiB rx: 35 tx: 0 > > 1500 1.90MiB/s 42 s 88268 KiB 1813 KiB rx: 2 tx: 0 > > 200 586KiB/s 141 s 105110 KiB 10314 KiB rx: 61 tx: 0 > > 200 487KiB/s 169 s 105221 KiB 10406 KiB rx:160 tx: 0 > > 200 520KiB/s 159 s 105143 KiB 10327 KiB rx:141 tx: 0 > > Y viendo el resultado, el performance quedo horrible! > > Tambien postulo que el efecto sera realmente peor si tienes mas clientes > > con un MTU 200, ya que segun yo aumentaran las colisiones enormemente > > contrario a lo que dices que la red trabaja bien con paquetes pequen~os. > > Una red con MTU de 200 o 500 no trabajará. Hay paquetes que son > indivisibles y no saldrán de la interfaz. > En redes wifi se prefiere usar Fragmentation Threshold, opera en capa 2 > y no en la cabecera IP, FT revisa estado de los paquetes indivisibles y > es mas eficiente que cambiar MTU. Pueden haber combinaciones de ambos, > pero sería demencia.
Una red con MTU de 200 si debe funcionar, recibes un ICMP de respuesta y debes fragmentar a nivel IP; me parece que configurar MTU es mejor que FT ya que es parte de la negociacion y no necesitas fragmentar o que alguien fragmente "a escondidas". > Tampoco me sirve pues yo necesito para una conexion en particular, no > para todos los nodos conectados al AP. Sorry, no estoy dandote la solucion. Solo estoy discutiendo que no estoy seguro que mejores la comunicacion de la red/conexion disminuyendo el taman~o del paquete como Ricardo dijo, hice una prueba rapida para ver y en mi caso obtuve mas errores (aparte de ser horriblemente lento). Por eso te pedi que corras la prueba y nos cuentes como te va, el escenario tuyo es muy distinto respecto donde corri la prueba y seria muy interesante saber cuanto cambia y en que punto. Para escribir rapido la prueba de un paquete con distinto taman~o lo hice modificando MTU y min_adv_mss, pero eres libre de cambiar el taman~o del paquete como puedas ;) [eso si, asegurate de poder sacar estadisticas para saber si es mejor o peor!] > >> Algo como TCPMSS parece servirme, pero esta implementacion pareciera ser > >> POSTROUTING solamente, yo desearia algo PREROUTING, de forma que el host > >> remoto (sea quien sea) comience a bajar el tamaño de su ventana TCP y me > >> transmita paquetes chicos. > > Los clientes/servidores no estan "ruteando", tienes que ponerlo en > > OUTPUT. Tambien puedes modificar la aplicacion cliente y/o servidor (eso > > de "negociacion") como mencione. > OUTPUT?, no creo, TCPMSS trabaja en la tabla mangle (OUTPUT no existe > alli). Tu quieres decir POSTROUTING? Hace rato que mangle esta en los 5 targets, compruebalo con "iptables -t mangle -nvL". Por orden prefiero OUTPUT (o FORWARD para un router) versus POSTROUTING, pero en ambos funcionaria. > Volviendo a lo mio yo necesito que un equipo intermedio (ruteador Linux > entre el AP ubicado a 10 kmt y mi PC) pueda reducir la venta TCP del > stream *downloaded* que viene desde el AP. Por eso pienso en un > PREROUTING (mangle desde luego), pero parece que no existe esa > implementacion ... o si?. TCPMSS no corta un paquete, sino que interfiere en la negociacion del MSS: tu PC le informa al servidor remoto cual es el taman~o deseado; por eso tienes que modificar la salida de tu PC. A la entrada de tu PC no tiene sentido pues el servidor remoto que envia los paquetes no se entera del cambio. Asi que puedes configurar TCPMSS a la salida de tu PC (no necesitas un equipo intermedio) y nos cuentas como anda. -- Aldrin Martoq <[email protected]> http://aldrin.martoq.cl/videopodcast/
signature.asc
Description: This is a digitally signed message part
