¿Cuál es la principal diferencia entre el software de red y el hardware de red?


Respuesta 1:

Algunos antecedentes. Comencé a construir hardware, comenzando con las puertas TTL de la serie 7400, luego con los procesadores 8080, construí una pila de sistemas embebidos interesantes. Tenía una especialidad de EE y programé lo suficiente para que los sistemas integrados funcionen.

Un proyecto paralelo (hacer un Z80 10 veces más rápido, usar tecnología AMD 2900 bit-slice, luego convertirlo en un multiprocesador de memoria compartida) me llevó a preguntarme "¿cómo lo programa?", Lo que condujo a la dualidad de las estructuras del sistema operativo , lo que me llevó a construir sistemas de memoria distribuida.

Y eso me llevó a enfrentar este enorme montón de papel

y eso llevó a involucrarse en el desarrollo temprano de las pilas TCP / IP y arreglar las pilas TCP / IP que no interoperaban. Software de redes instantáneas.

Al mismo tiempo, este no era mi "trabajo diario", que era construir computadoras de memoria distribuida de alto rendimiento. Las redes eran LENTAS, es decir, 10 megabits por segundo era lo último en tecnología. Pero eso fue lento, en relación con el ancho de banda de la CPU / memoria.

Así que dejé de pensar en términos de bits y comencé a pensar en términos de bytes, y usé un montón de cosas de transmisión en modo diferencial, y fui de 16 bits de ancho más ECC, y construí hardware de bus de token de toda la palabra. Golpeando memoria a memoria a 150 megabytes por segundo. (¡Oye! ¡RDMA antes de que sea la hora!) Easy-peasy.

Pero solo fue fácil porque (a) había estado construyendo CPU a partir de puertas en el límite del rendimiento durante mucho tiempo y (b) entendí las pilas de redes de software de adentro hacia afuera. Sabía dónde necesitaba insertar cosas en el hardware, dónde necesitaba guardarlas en el software, qué se podía hacer para minimizar las copias de memoria a memoria de la CPU, todo ese jazz.

Para ser realmente bueno con el software de red, debe ser capaz de comprender cómo se utiliza la pila de red, lo que sucede en el otro lado de la API, en tierra de aplicaciones. Si va a desarrollar protocolos, si va a trabajar en la optimización del rendimiento, esa es la clave: debe saber por qué es importante.

Si va a construir hardware, necesita saber cómo funcionan los controladores del sistema operativo, o hacer suposiciones estúpidas y estúpidas. No puedo decirte cuán completamente dañado el cerebro ha visto parte del hardware que he visto, debido a las "optimizaciones" realizadas por algún ingeniero de hardware.

Si va a crear protocolos de enrutamiento y software integrado para enrutadores, ese es un juego diferente. Debe comprender todas las matemáticas que se utilizan para construir el gráfico y todos los algoritmos que pueden hacerlo más rápido (o más lento). También debe comprender los trucos: la traducción mira a un lado los buffers, qué almacenar en caché cuando, etc.

No importa dónde se encuentre en la pila, cuanto más sepa sobre el resto de la pila, mejor podrá ser. Los procesos de pensamiento son diferentes, los puntos nativos naturales que te inclinas a optimizar son diferentes, y comprender el otro lado te ayuda a estar en mejores condiciones para no tomar las decisiones equivocadas.


Respuesta 2:

Básicamente, se trata de entrenamiento. Algunas personas tienen un grado de EE. Otros tienen un título de CS. No importa cuál, tienen una cierta educación y orientación y son mejores para hacer las cosas que han aprendido.

Todavía tengo que conocer a una persona que realmente pueda hacer ambas cosas. Y he trabajado con cientos, si no miles, de las mejores personas de redes en el planeta.


Respuesta 3:

Básicamente, se trata de entrenamiento. Algunas personas tienen un grado de EE. Otros tienen un título de CS. No importa cuál, tienen una cierta educación y orientación y son mejores para hacer las cosas que han aprendido.

Todavía tengo que conocer a una persona que realmente pueda hacer ambas cosas. Y he trabajado con cientos, si no miles, de las mejores personas de redes en el planeta.