Ferraris y camiones con remolque

Trabajando en el mundo de las pymes, en realidad es bastante raro que necesitemos hablar de latencia. El mundo de las pymes está casi universalmente centrado en el rendimiento del sistema y, por lo general, no es consciente de la latencia como una necesidad. Pero hay ocasiones en las que la latencia se vuelve importante y, cuando lo hace, es fundamental que comprendamos la interacción entre el rendimiento y la latencia y qué significa para nosotros la “velocidad”. Una vez que empezamos a adentrarnos en el espacio empresarial, la latencia se contempla con más frecuencia como una preocupación, pero incluso allí el rendimiento casi siempre reina supremo, hasta el punto de que los conceptos de velocidad giran casi universalmente en torno al rendimiento y los conceptos de latencia a menudo se ignoran o se olvidan.

Comprender el papel de la latencia en un sistema puede ser complicado, aunque la latencia en sí misma es relativamente sencilla de entender.

Una excelente comparación entre la latencia y el rendimiento que me gusta utilizar es la idea de un Ferrari y un camión con remolque. Los Ferrari son “rápidos” en el sentido tradicional; tienen un elevado número de “millas por hora”. Se podría decir que están diseñados para la velocidad. Pero ¿lo están?

Por lo general consideramos que los camiones con remolque son lentos. Son bestias grandes y pesadas con una velocidad máxima baja. Pero transportan un montón de cosas a la vez.

En términos informáticos, normalmente pensamos en la velocidad como la capacidad de transporte – pensamos en términos de “artículos” por segundo. En el caso de un Ferrari, ir a doscientas millas por hora es estupendo, pero puede transportar quizá una caja a la vez. Un camión con remolque solo puede ir a cien millas por hora, pero puede transportar cerca de mil cajas a la vez. Cuando hablamos de rendimiento o velocidad en una computadora, esto es más bien en lo que pensamos. En términos de red, pensamos en gigabytes por segundo y rara vez nos preocupa la velocidad de un paquete individual, ya que un solo paquete rara vez es importante. En términos computacionales, pensamos en ideas como las operaciones de coma flotante por segundo, un concepto similar. A nadie le importa realmente cuánto tarda un solo FLOP (operación de coma flotante); solo cuántas podemos completar en uno o diez segundos.

Así que, al observar un Ferrari, podríamos decir que tiene una velocidad útil de doscientas caja-millas por hora. Es decir, por cada hora de operación, un Ferrari puede mover una caja hasta doscientas millas. Un camión con remolque tiene una velocidad útil de cien mil caja-millas por hora. En términos de mover paquetes de un lado a otro, el rendimiento del camión con remolque es fácilmente quinientas veces “más rápido” que el del Ferrari.

Así que, en términos de cómo normalmente pensamos en las computadoras y las redes, un camión con remolque sería “rápido” y un Ferrari sería “lento”.

Pero también hay que tener en cuenta la latencia. Suponiendo que nuestra carga sea minúscula, digamos una carta o una caja pequeña, ¡un Ferrari puede mover esa única caja a lo largo de más de mil millas en tan solo cinco horas! Un camión con remolque tardaría diez horas en hacer ese mismo trayecto (pero podría llevar MUCHÍSIMAS cartas que llegarían todas a la vez). Si lo que necesitamos es llevar un mensaje o un pequeño paquete de un lugar a otro muy rápidamente, el Ferrari es la mejor opción porque tiene la mitad de la latencia (retardo), desde el momento en que iniciamos la entrega hasta que se entrega el primer paquete, que el camión con remolque.

Como puede imaginar, en la mayoría de los casos los camiones con remolque son muchísimo más prácticos porque su velocidad de entrega es mucho mayor. Y, siendo así, en realidad vemos grandes camiones en las autopistas todo el tiempo y la frecuencia de aparición de los Ferrari es muy baja – aunque cada uno cuesta aproximadamente lo mismo de adquirir (muy a grandes rasgos). Pero en casos especiales, el Ferrari tiene más sentido. Solo que no muy a menudo.

Este es un concepto de carácter general y puede aplicarse a numerosas aplicaciones. Se aplica a los sistemas de caché, la memoria, la CPU, las redes, los núcleos y planificadores de los sistemas operativos, a los coches y más. La latencia y el rendimiento generalmente están relacionados de forma inversa – renunciamos a latencia para obtener rendimiento. Para la mayoría de las operaciones esto tiene todo el sentido. Pero a veces tiene más sentido ajustar en función de la latencia.

El almacenamiento es en realidad un caso atípico en la informática, donde casi toda la atención sobre el rendimiento del almacenamiento se centra en las IOPS, que son aproximadamente una medida indirecta de la latencia, en lugar del rendimiento, que se mide en “datos transferidos por segundo”. Rara vez nos importa esta segunda cifra, ya que casi nunca es el origen de los cuellos de botella del almacenamiento. Pero esta es la excepción, no la regla.

La latencia y el rendimiento pueden tener algunas interacciones sorprendentes en el mundo de la informática. Cuando hablamos de redes, por ejemplo, normalmente medimos solo el rendimiento (Gb/s) pero rara vez nos preocupa mucho la latencia (que normalmente se mide en milisegundos). Por lo general, esto se debe a que casi todos los sistemas de red tienen cifras de latencia similares y la mayoría de las aplicaciones están prácticamente despreocupadas por los retardos de latencia. Solo en la rara aplicación, como VoIP sobre enlaces internacionales o satélite, la latencia afecta a la persona promedio o, a veces, puede sorprender a la gente cuando intenta algo poco habitual, como iSCSI sobre una conexión WAN de larga distancia, y de repente la latencia aparece para sorprenderlos como un problema imprevisto.

Uno de los lugares donde la interacción de la latencia y el rendimiento empieza a volverse impactante e interesante es cuando pasamos de redes de datos eléctricas u ópticas a redes físicas. Una cita famosa en la industria es:

Nunca subestimes el ancho de banda de una camioneta familiar repleta de cintas circulando a toda velocidad por la autopista.

Esta es una gran demostración de un enorme ancho de banda con una latencia muy alta. Conduciendo cincuenta millas a través de la ciudad, una sola camioneta familiar o SUV podría transportar cientos de petabytes de datos, alcanzando tasas de datos que la fibra de 10 GB/s no podría ni acercarse a igualar. Pero el tiempo que tarda en llegar el primer paquete de datos es de aproximadamente una hora. A menudo descartamos este tipo de red porque damos por sentado que la latencia debe estar acotada por debajo de unos 500 ms. Pero ese no siempre es el caso.

Australia fue noticia recientemente, cuando realizaron una prueba para ver si una paloma que transportaba una tarjeta SD podía, en términos de rendimiento de red, superar al ISP de la región – ¡y la paloma acabó siendo más rápida que el ISP!

En términos de rendimiento informático, a menudo ignoramos la latencia hasta el punto de ni siquiera ser conscientes de ella como un contexto en el que hablar de rendimiento. Pero en los círculos de la informática de baja latencia se la considera con muchísimo cuidado. El rendimiento del sistema generalmente se reduce en gran medida (se vuelve común fijar como objetivo que los sistemas alcancen solo un diez por ciento de utilización de la CPU, cuando los sistemas más tradicionales apuntan a cerca del noventa por ciento) con conceptos como núcleos en tiempo real, afinidad de CPU, anclaje de procesadores, tasas de aciertos de caché y mediciones reducidas, todos ellos utilizados para centrarse en obtener la respuesta más inmediata posible de un sistema en lugar de intentar sacar el máximo procesamiento total de un sistema.

Los lugares comunes donde se desea una baja latencia desde una perspectiva computacional son los sistemas de control críticos (como los controladores de fabricación, donde incluso un milisegundo de latencia puede causar problemas en la planta de producción) o los sistemas de negociación financiera, donde unos pocos milisegundos de retardo pueden hacer que las inversiones hayan cambiado de precio o que los productos ya se hayan vendido y ya no estén disponibles. La velocidad, en términos de latencia, suele ser el factor decisivo entre ganar dinero o perderlo – incluso un solo milisegundo puede ser paralizante.

Técnicamente, incluso los sistemas de procesamiento de audio y vídeo tienen que ser sensibles a la latencia, pero la mayoría de los sistemas informáticos modernos tienen tanto sobrante de capacidad de procesamiento y la latencia es por lo general lo bastante baja que la mayoría de los sistemas, incluso las centralitas PBX de VoIP y los sistemas de conferencias, pueden funcionar hoy en día necesitando solo muy rara vez ser conscientes de las preocupaciones de latencia en el lado del procesamiento (incluso la latencia de red es cada vez menos común como preocupación). El administrador o ingeniero de sistemas promedio podría fácilmente llegar a atravesar una carrera entera sin necesidad de trabajar nunca en un sistema sensible a la latencia o para el cual no haya tanta capacidad disponible como para ocultar cualquier sensibilidad a la latencia.

Definir la velocidad, ya sea que signifique rendimiento, latencia o incluso alguna otra cosa o alguna combinación de ambas, es algo muy importante en todos los aspectos de la TI y de la vida. Comprender cómo nos afectan en distintas situaciones y cómo reaccionan entre sí, existiendo generalmente en una relación indirecta en la que las mejoras en el rendimiento tienen un costo en latencia o viceversa, y aprender a equilibrarlas según sea necesario para mejorar los sistemas en los que trabajamos es algo muy valioso.