Todo el que ha usado Windows en esta vida lo ha experimentado. Cuando copiamos, transferimos o borramos archivos en el sistema, siempre aparece una ventana de progreso con el tiempo estimado de la operación, y dependiendo del caso, la predicción tiende a ser extremadamente errática.
Esto tiene sus razones, y ahora podemos conocer muchas de ellas gracias a uno de los ingenieros encargados de crear y mantener el cuadro de diálogo de progreso de Windows: David Plummer. Este es el mismo señor que creó el Administrador de tareas de Windows y que dejó de trabajar en Microsoft hace muchos años. Sin embargo, a pesar del tiempo que ha pasado y de los muchos otros desarrolladores que han trabajado en esta y otras características de Windows, las predicciones siguen lejos de ser perfectas y este es el por qué.
Faltan 2 minutos, ahora faltan 2 horas... listo en 30 segundos
Dave es solo una de tantas personas que han trabajado en el cuadro de diálogo de progreso de Windows desde los días de Windows 95, y explica que trabajó en él hasta aproximadamente el 2003. Curiosamente, lo último a lo que se dedicó fue exactamente en mejorar la predicción del tiempo que tardará una operación en completarse cuando involucra muchos archivos.
En un vídeo publicado en su canal de YouTube, donde suele contar anécdotas y explicar cosas interesantes sobre la informática y sus experiencias, Dave pidió que lo culparan a él por el hecho de que esa barra de progreso lo haga tan mal.
La shell está intentando predecir el futuro: el problema, como Plummer comenta, es que los intentos de predicción que la shell de Windows hace para estimar el tiempo restante tienen que ver solo con lo que acaba de suceder o lo que está pasando. Esto implica que, mientras más cerca del inicio del proceso estamos, más equivocada podrá estar la predicción.
Por ejemplo, si la operación involucra pocos archivos de pequeño tamaño, la shell probablemente estime bien que según el tiempo que tomó copiar el primero de estos, el resto tome aproximadamente el mismo y haga un cálculo más acertado. Ahora, cuando la operación es más compleja e involucra múltiples archivos de múltiples tamaños, el asunto se complica muchísimo.
Lo irrelevante que puede ser conocer el tamaño de los archivos y la velocidad de escritura lectura de tus discos: uno creería que hacer un cálculo simple con la información que tienes sobre el tamaño de los archivos a transferir + la velocidad a la que escriben y leen datos tus discos sería suficiente para hacer un buen estimado, pero uno estaría equivocado.
La shell no sabe con exactitud, porque no puede saber: aunque la shell sabe el número total de bits que tiene que copiar, ese es solo un factor en el resultado a la hora de predecir cuánto tiempo tomará el proceso. La mayoría de las veces no es tan simple, y la shell no puede saber exactamente cuánto ancho de banda estará libre dentro del próximo minuto. No sabe qué tan ocupado estará el disco, o el bus, o que tan saturado esté el SSD o si el caché necesita ser reescrito, etc.
Las cosas pueden cambiar durante el proceso: de cambios en las condiciones de la red, a aplicaciones multitarea ralentizando el I/O, a tu disco perdiendo velocidad con el progreso de una copia grande, y pare usted de contar. En esta parte David lo explica todo con un ejemplo extremadamente práctico que intentaré replicar cambiando algunas cosas para adaptarlas a mi audiencia.
Si Windows calculara el tiempo que te tomaría ir de Valencia a Madrid
Si tuvieses que hacer un viaje de Valencia a Madrid y el cuadro de diálogo de Windows fuese el encargado de predecir el tiempo que te tomará, el sistema comenzaría a estimar el tiempo en el momento en que, por ejemplo, empiezas a caminar de tu casa a la parada del Metro.
Con esa información, Windows te diría que llegas en tres días, simplemente porque vas caminando en ese momento. Recordemos que solo puede predecir basándose en lo que ha pasado hasta ahora. Una vez que te montes en el metro esa estimación cambiaría nuevamente a una mucho más corta dado la velocidad extremadamente superior a la que te estás moviendo.
Sin embargo, en cuanto bajes del metro y camines hasta la estación de tren, por ejemplo, el estimado volverá a cambiar de horas o minutos, a días. De pronto, cuando vayas en el Renfe a 250 km/h la predicción te pondría ahí en minutos nuevamente, como si fueses del tren directo a la puerta del hotel. Esto es porque, nuevamente, Windows no puede predecir que te bajes en la estación y tengas que pasar una hora en el tráfico de Madrid para llegar a tu destino final.
La shell de Windows no es Google Maps: a diferencia de algo como Google Maps que predice con extrema exactitud el tiempo que nos toma ir de un sitio a otro por diferentes vías, ese cuadro de diálogo de Windows no está usando una enorme base de datos de otros millones de usuarios que han hecho el mismo viaje antes para predecir el resultado más probable. Windows simplemente no funciona así.
Ver 37 comentarios