Acabo de actualizar mi LAN a gigabit. Esto es lo que netperf tiene que decir sobre las cosas.
Antes:
marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1)
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.02 94.13
Después:
marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 339.15
¿Solo 340 Mbps? ¿Que pasa con eso?
Información general: me estoy conectando a través de un conmutador gigabit a un conector sheevaplug. Tengo cableado Cat5e en las paredes y el recorrido es de unos 30 pies. Si no está familiarizado con netperf, tiende a dar resultados muy estables y nunca miente.
Respuesta1
Verificareste hilo. Uno de los colaboradores (Frennzy) lo describe muy bien. Citaré:
La velocidad "real" de Gigabit Ethernet es...
1Gbps.
Es decir, transferirá bits a razón de mil millones por segundo.
La cantidad de rendimiento de datos que obtiene está relacionada con diversos factores:
Conexión de NIC al sistema (PCI, PCIe, Northbridge, etc.).
Rendimiento del disco duro.
Contención de autobuses.
Protocolo de capa 3/4 y sobrecarga asociada.
Eficiencia de las aplicaciones (FTP frente a SMB/CIFS, etc.)
Tamaño del marco.
Distribución del tamaño de los paquetes (en relación con la eficiencia del rendimiento total)
Compresión (hardware y software).
Contención de buffer, ventanas, etc.
Capacidad y arquitectura de la infraestructura de red (número de puertos, capacidad del backplane, contención, etc.)
En resumen, no lo sabrás realmente hasta que lo pruebes. NetCPS es una buena herramienta para esto, como lo son muchas otras.
Y esto, más adelante en el hilo (mi resaltado):
Deja de pensar así. Detenlo ahora. Todos ustedes.
Por mucho que le gustaría calcular la transferencia de kilos o megaBYTE por segundo, el hecho es que es variable, incluso cuando la velocidad de la red permanece constante. La "velocidad" de la red (bits por segundo) es absoluta. El rendimiento de la red (datos de carga útil reales por segundo) no lo es.
Para el OP: ¿verá, en general, transferencias de datos más rápidas al cambiar de 100 Mbps a 1000 Mbps? Casi definitivamente.¿Estará cerca del máximo teórico? No.Valdrá la pena? Eso lo decides tú.
Si quieres hablar de velocidades de red, habla de velocidades de red. Si quiere hablar sobre rendimiento de datos, hable sobre rendimiento de datos. Los dos no están empatados en forma 1-1.
Respuesta2
Se utiliza el término "máximo teórico", pero tiene una aplicación práctica con las tecnologías Ethernet. En un sistema CSMA/CD como Ethernet, sólo se puede enviar aproximadamente la mitad del ancho de banda del tráfico que contiene el cable, a menudo un poco menos. La razón es que una vez que intentas superar ese "máximo", los transceptores comenzarán a detectar colisiones más de lo que transmiten paquetes. Entonces entra en juego un retroceso exponencial y la transmisión de paquetes se degrada aún más. Token ring solucionó esto, pero creo que tenía muchos problemas propios y ya no se usa mucho. Ethernet/IP se convirtió en el estándar de facto.
Las tecnologías de enlace ascendente, como T3, utilizan pares asíncronos que permiten el rendimiento completo en cada cable, pero tampoco es un protocolo basado en Ethernet.
Mientras utilice dispositivos Ethernet estándar básicos, siempre existirá el "máximo teórico".
Respuesta3
Hablar de CSMA/CD en el contexto de GbE es totalmente falso. Gigabit Ethernet, o cualquier Ethernet "full-duplex", no utiliza CSMA/CD. Y aunque GbE todavía mantenía la posibilidad teórica de funcionamiento semidúplex, no estoy del todo seguro de que alguna vez haya existido un kit GbE de producción real que funcionara semidúplex.
En cuanto a por qué el OP solo alcanzó 300 Mbit/s y pico a través de un enlace de 1000 Gbit/s, sugeriría recopilar estadísticas de netstat para TCP antes y después de cada ejecución de netperf, e incluir las opciones de línea de comandos globales -c y -C. para ver cuál es la utilización de la CPU en cada extremo. Quizás algo esté perdiendo paquetes, o quizás la CPU de un lado o del otro se esté saturando. Si los sistemas en cualquiera de los extremos son multinúcleo, definitivamente verifique las utilizaciones por núcleo con una herramienta externa o revisando la salida de depuración de netperf.
Probablemente sea mejor dejar otras preguntas sobre netperf en la lista de correo netperf-talk de netperf.org.