# Las latencias de un ordenador - Sitio: Ikusmira — enciclopedia en castellano de ciencias sociales y humanidades - URL canónica: https://ikusmira.org/p/las-latencias-de-un-ordenador/ - Categoría: Informática - Publicado: 2026-08-10 - Autoría: Josemari Sarasola Ledesma — Editor coordinador; Profesor titular de escuela universitaria, Universidad del País Vasco/Euskal Herriko Unibertsitatea - Perfiles del autor: https://ekoizpen-zientifikoa.ehu.eus/investigadores/127490/detalle, https://dialnet.unirioja.es/servlet/autor?codigo=333202 - Política editorial (autoría, revisión, correcciones, financiación): https://ikusmira.org/politica-editorial/ La **latencia** (en inglés, *latency*) es el tiempo que pasa desde que se pide algo hasta que llega la respuesta. En un ordenador se mide en nanosegundos, milmillonésimas de segundo, y va de medio nanosegundo para leer un dato que el procesador tiene a mano a ciento cincuenta millones para mandar un mensaje a otro continente y recibir la respuesta. Son casi nueve órdenes de magnitud, la misma distancia que hay entre un segundo y diez años, y casi todo lo que hace rápido o lento a un programa, a una web o a una aplicación del móvil sale de saber en qué punto de esa escala está cada cosa. La lista más citada la publicó en 2001 Peter Norvig, que después dirigiría la investigación de Google, al final de un ensayo sobre cuánto se tarda en aprender a programar. El ingeniero Jeff Dean la popularizó en 2009 entre los que construían sistemas distribuidos con el título de «números que todo el mundo debería saber». Las cifras son aproximadas y de su época, pero sus proporciones apenas han cambiado, y la figura de esta página las dibuja en escala logarítmica, en la que cada marca vertical multiplica por mil. La escala humana del segundo botón es la manera más directa de entender la figura, y la usa Brendan Gregg en su manual de rendimiento de sistemas. Si un nanosegundo durase un segundo, el procesador leería de su caché más cercana en medio segundo y ejecutaría una instrucción en uno. Ir a la memoria principal le costaría un minuto y cuarenta segundos, como levantarse a por un libro de otra habitación. Leer un megabyte seguido de memoria serían casi tres días; buscar un sitio nuevo en un disco duro de los que giran, tres meses, y un paquete de Estados Unidos a Europa y vuelta, casi cinco años. Un programa que va al disco cuando podría haber ido a la memoria no es un poco más lento: es un viaje de un día convertido en una espera de meses. De ahí sale la primera lección práctica, la de las cachés (*caches*). Si leer la memoria es doscientas veces más lento que leer la caché L1, y buscar en el disco, decenas de miles de veces más lento que la memoria, compensa guardar cerca una copia de lo que se usa a menudo, aunque la copia ocupe espacio y haya que vigilar que no se quede vieja. Es lo que hacen los procesadores con varios niveles de caché, los sistemas operativos con la memoria que sobra, los navegadores con las páginas visitadas y las bases de datos con los índices. La [caché LRU](https://ikusmira.org/p/la-cache-lru/) es la regla más común para decidir qué olvidar cuando no cabe todo. La segunda lección es que la latencia y el ancho de banda (*bandwidth*) son cosas distintas. El ancho de banda dice cuántos datos pasan por segundo, y es lo que anuncian los proveedores de fibra; la latencia dice cuánto tarda en llegar el primero. Una conexión de mil megabits es una tubería muy ancha, pero no acorta el viaje. Por eso una web que necesita cincuenta ficheros pequeños, pedidos uno detrás de otro a un servidor lejano, carga despacio con cualquier fibra, y por eso las redes de distribución de contenidos (*content delivery networks*) ponen copias de las webs en cientos de ciudades: no hacen la tubería más ancha, acercan el grifo. La tercera lección es física, y nadie la explicó mejor que Grace Hopper, pionera de la programación y contraalmirante de la Armada estadounidense. Desde finales de los años sesenta repartía en sus conferencias trozos de cable de unos treinta centímetros, la distancia que recorre una señal eléctrica en un nanosegundo en el mejor de los casos, para explicar a los militares por qué un ordenador más pequeño es más rápido. El Museo Nacional de Historia Americana conserva un manojo de esos «nanosegundos», los que repartió en una charla en 1985. Dentro de una fibra óptica, la luz va a unos doscientos mil kilómetros por segundo. Madrid y Nueva York están a unos 5.770 kilómetros, así que una pregunta y su respuesta no pueden tardar menos de 58 milisegundos aunque el cable fuera recto y los equipos, instantáneos. Ninguna inversión baja esa cifra, y cualquier servicio que tenga que responder deprisa en todo el mundo solo tiene una salida: estar cerca de quien pregunta. Las cifras de la figura han envejecido de manera desigual, y eso también enseña algo. Los procesadores de hoy son muchas veces más rápidos que los de 2001, pero leer la memoria principal sigue costando del orden de cien nanosegundos. William Wulf y Sally McKee lo previeron en 1995 en un artículo que llamaron «Chocar con el muro de la memoria»: si el procesador mejora cada año mucho más deprisa que la memoria, llegará un momento en que casi todo el tiempo se irá en esperar datos. Ese muro es la razón de que los procesadores actuales dediquen buena parte de su superficie a la caché. Los discos, en cambio, dieron un salto: los de estado sólido (*solid-state drives*), sin piezas que giren, tardan decenas o cientos de veces menos que los ocho milisegundos de una búsqueda en un disco mecánico, y cambiar a uno sigue siendo la mejora más notable que se le puede hacer a un ordenador viejo. La luz, por su parte, va igual de deprisa que en 2001. Para quien no programa, la figura resume por qué unas cosas tardan y otras no. Abrir un documento que ya está en memoria es inmediato; abrirlo desde un disco giratorio, perceptible; desde un servidor en otro continente, lento aunque la fibra sea buena. Y cuando una aplicación tarda, la pregunta útil no es cuánto ancho de banda tiene la conexión, sino cuántas veces tiene que ir y volver, y hasta dónde. [La caché LRU](https://ikusmira.org/p/la-cache-lru/) – [La arquitectura de von Neumann](https://ikusmira.org/p/la-arquitectura-de-von-neumann/) – [El sistema de nombres de dominio](https://ikusmira.org/p/el-sistema-de-nombres-de-dominio/) – [La notación O grande](https://ikusmira.org/p/la-notacion-o-grande/) – [Disco duro (disco rígido)](https://ikusmira.org/p/disco-duro-disco-rigido/) – [El protocolo TCP/IP](https://ikusmira.org/p/el-protocolo-tcp-ip/) ## Fuentes - Peter Norvig — *Teach Yourself Programming in Ten Years*, norvig.com (2001) — https://norvig.com/21-days.html - Jeff Dean — *Designs, Lessons and Advice from Building Large Distributed Systems*, LADIS 2009, conferencia inaugural (2009) — https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf - William A. Wulf y Sally A. McKee — *Hitting the memory wall: implications of the obvious*, ACM SIGARCH Computer Architecture News 23 (1) (1995) — https://doi.org/10.1145/216585.216588 - Brendan Gregg — *Systems Performance: Enterprise and the Cloud (2.ª ed.)*, Addison-Wesley (2020) - National Museum of American History — *Nanoseconds Associated with Grace Hopper*, Smithsonian Institution (1985) — https://americanhistory.si.edu/collections/object/nmah_692464 --- Cómo citar: Sarasola, Josemari (2026). «Las latencias de un ordenador». Ikusmira. https://ikusmira.org/p/las-latencias-de-un-ordenador/ Índice del sitio para modelos: https://ikusmira.org/llms.txt