On Vie 27 Sep 2002 20:44, Pablo Giménez Pizarro wrote: [...] > Lo curioso es que presenta el típico esquema de buffers saturados en una > comunicación, la transferencia empieza a unos 11MB/s y va decreciendo > hasta estabilizarse, tras varias fluctuaciones, en unos 1,4MB/s. > Viendo que el rendimiento era muy bajo, un ancho de banda de 1,4MB/s > entre dos puntos sin que haya más tráfico en la red, me lance a ver si > habría algún defecto en el hardware de la red, he cambiado tarjetas > (algunas de marca como las 3Com), he cambiado cables, e incluso he > cambiado el switch pensando que podría estar defectuoso, resultado: todo > igual . > En cuanto a las tarjetas ethernet he comprobado que no tiran paquetes ni > hay colisiones mirando la información dada por ifconfig tras las > transferencias. > Hemos probado también con un cable cruzado a comunicar el servidor con > un cliente directamente y el resultado es el mismo . > Descartando el problema del hardware de red pregunté a uno de mis > profesores de redes que podría estar pasando y me indico que podría ser > problema de las máquinas, que la pila TCP/IP o los protocolos no eran > capaces de dar más ancho de banda, lo único que he observado al respecto > es que haciendo una transferencia mediante ftp el cliente linux de ftp > carga mucho el sistema, un top me indica que el sistema se lleva el > 70%-80% del tiempo de CPU, es decir, que el kernel se pone a tope, > también con nfs el sistema se realentiza, de hay he deducido que el > problema pueda ser que el kernel (v2.4.18) no soporte mas ancho de > banda, ya que en todas las pruebas realizadas uno de los extremos de la > comunicación era siempre un linux. > Alguien puede aclararme si esto puede ser cierto y si sabe alguna > solución, pues yo tenía entendido que linux era capaz de lidiar con > redes de este tipo y que podía perfectamente dar anchos de banda de > 100Mb/s, esto sucede tanto con protocolos tcp (ftp) como udp (nfs), de > lo que deduzco que si hay algun problema esta en la capa IP que esta por > debajo de ambos .
¡Absurdo! Hemos estado haciendo pruebas precisamente estos dos últimos meses en RedIRIS. Hemos enviado 500 Mbit/s sobre IPv6 a través de una tarjeta Gigabit Ethernet por media Europa (unos 2200 km, para ser exactos). ¿Los núcleos? 2.4.20-pre5 por nuestra parte, 2.4.18 por el otro extremo. Así que Linux es capaz de llenar perfectamente una Fast Ethernet. En realidad, *sí* hay un límite en los núcleos actuales, pero es por el sistema de recoger las interrupciones. Básicamente, empiezas a tener problemas con unos 60.000 o 70.000 paquetes por segundo. No es tu caso. Se pone en un 70%-80% de CPU...Hum...¿y qué proceso es el que se lleva la CPU? Eso lo verás con un top... ¿Las tarjetas son PCI? Yo tengo en mi equipo dos 3Com 3C905, una Cyclone y una Boomerang, PCI, y funcionan perfectamente. Nunca había visto un problema de sobrecarga como el tuyo. ¿Podrías mirar si las tarjetas están generando muchas interrupciones? Puedes saberlo con un cat /proc/interrupts: [EMAIL PROTECTED]:~$ cat /proc/interrupts CPU0 0: 145243168 XT-PIC timer 1: 658148 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 12889488 XT-PIC soundblaster 8: 3 XT-PIC rtc 10: 2222796 XT-PIC usb-uhci 12: 6588303 XT-PIC eth0 <======= Este valor. 14: 1522717 XT-PIC ide0 15: 10359 XT-PIC ide1 NMI: 0 LOC: 145243899 ERR: 0 MIS: 0 ¿Sube *a lo bestia* cuando haces una transferencia? Debería subir en uno por cada paquete. Un saludo, Ender. -- Why is a cow? Mu. (Ommmmmmmmmm) -- Servicios de red - Network services Centro de Comunicaciones CSIC/RedIRIS Spanish Academic Network for Research and Development Madrid (Spain) Tlf (+34) 91.585.49.05