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: [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:796 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. (Omm) -- 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
Re: Expediente X en una LAN
Gracias por vuestra ayuda, ya he conseguido arreglar el engendro, efectivamente el problema estaba en que el disco duro no estaba configurado y me saturaba el bus del sistema , vamso que me dejaba tostao el servidor, con el hdparm todo arreglado, gracias de nuevo. El vie, 27-09-2002 a las 23:03, Carles Pina i Estany escribió: Hola, 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 tal como te han comentado, vigila que tengas el DMA activado del disco si son discos IDE: hdparm -d 1 /dev/hda (creo que es así) haz un test de la velocidad de los discos (hdparm -t, creo) Comenta los resultados, para saber... Suerte! -- Carles Pina i Estany | Nick: Pinux / Pine / Teufeus E-Mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.salleURL.edu/~is08139/ Web Interessant sobre l' explorer: http://jscript.dk/unpatched/ Si señor Juez, es tan cierto como que el W'95 es multitarea real -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- --- Un saludo, Pablo Giménez Pizarro La única lucha que se pierde es la que se abandona Mujeres de la Plaza de Mayo (Argentina) .
Expediente X en una LAN
Que tal lista, en esta ocasión me ha sucedido un problema al que ya no sé como meterle mano . La cuestión es que tenía una LAN a 10Mb/s en la que había un servidor de ficheros con woody y clientes win, la red iba perfecta, la tasa de transferencia con los clientes rondaba entorno a los 800KB/s . Acabo de pasar la red a 100Mb/s, con la compra de un nuevo switch, el servidor samba ahora tiene también nfs para trabajar con otros clientes linux. El problema es que ahora la tasa de transferencia entre cualquier cliente (hay clientes win, linux y mac) con el servidor es entorno a los 1,4MB/s, lo he probado haciendo tranferencias de ficheros grandes (256MB) mediante nfs y ftp, en ambos casos igual. 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 . Por último indicar que las máquinas tienen procesador Duron de 600MHz y memorias ram entre 256MB y 512MB, si alguien puede arrojar alguna luz de que puede estar pasando se lo agradecería. Perdonar lo largo del mensaje y gracias . -- --- Un saludo, Pablo Giménez Pizarro La única lucha que se pierde es la que se abandona Mujeres de la Plaza de Mayo (Argentina) .
Re: Expediente X en una LAN
Pablo Giménez Pizarro escribió:: Que tal lista, en esta ocasión me ha sucedido un problema al que ya no sé como meterle mano . La cuestión es que tenía una LAN a 10Mb/s en la que había un servidor de ficheros con woody y clientes win, la red iba perfecta, la tasa de transferencia con los clientes rondaba entorno a los 800KB/s . Acabo de pasar la red a 100Mb/s, con la compra de un nuevo switch, el servidor samba ahora tiene también nfs para trabajar con otros clientes linux. El problema es que ahora la tasa de transferencia entre cualquier cliente (hay clientes win, linux y mac) con el servidor es entorno a los 1,4MB/s, lo he probado haciendo tranferencias de ficheros grandes (256MB) mediante nfs y ftp, en ambos casos igual. 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 . Por último indicar que las máquinas tienen procesador Duron de 600MHz y memorias ram entre 256MB y 512MB, si alguien puede arrojar alguna luz de que puede estar pasando se lo agradecería. Perdonar lo largo del mensaje y gracias . ¿saturación del bus del servidor?, ¿velocidad del acceso a disco? Hace unos días, en una charla técnica, mencionaban la disparidad de calidad entre las distintas tarjetas de red de una misma marca (3Com). Suena a falta de optimización en el servidor, ¿no? -- Héctor Andrés Rompato Carricart [EMAIL PROTECTED] Coordinador técnico COVIARES S.A. -- Autopista La Plata - Buenos Aires Gerencia de equipos y sistemas Av. España y Autopista, Quilmes (1878) Buenos Aires, Argentina
Re: Expediente X en una LAN
Hola, 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 tal como te han comentado, vigila que tengas el DMA activado del disco si son discos IDE: hdparm -d 1 /dev/hda (creo que es así) haz un test de la velocidad de los discos (hdparm -t, creo) Comenta los resultados, para saber... Suerte! -- Carles Pina i Estany | Nick: Pinux / Pine / Teufeus E-Mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.salleURL.edu/~is08139/ Web Interessant sobre l' explorer: http://jscript.dk/unpatched/ Si señor Juez, es tan cierto como que el W'95 es multitarea real
