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
