Re: Expediente X en una LAN
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:
ender@bonzo:~$ 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
Reply to: