Diálogo de copia de archivos de Windows: ¿Por qué la estimación es tan ... MALA?

38

Estimacion

xkcd

Sé que el cuadro de diálogo de copia de Windows (en Windows XP) almacena primero la copia en la memoria, y todavía está copiando después de que se cierra el cuadro de diálogo, por lo que el tiempo está desactivado, pero ¿por qué es la estimación del tiempo que tomará hacer una copia? tan inexacto, incluso cuando la copia de memoria ha sido desactivada (en Vista y Windows 7) ¡Parece tan arbitrario! ¿Cómo funciona todo el procedimiento de copia y por qué Windows no puede estimarlo correctamente?

Maxim Zaslavsky
fuente
La barra de progreso muestra el número de archivos completados, no el% de tiempo completado, para su información.
Factor Mystic
3
Además, esto debería aplicarse a cualquier sistema operativo, no solo a Windows, ya que creo que las restricciones son universales.
Clockwork-Muse el
1
También hay que destacar la publicación de blog de Mark Russinovich: blogs.technet.com/b/markrussinovich/archive/2008/02/04/…
surfasb

Respuestas:

29

En resumen: los algoritmos deficientes y la estimación irregular son en realidad una debilidad de implementación.

Otras herramientas como TeraCopy hacen un mejor trabajo. Creo que no vale la pena explicar por qué su implementación no es buena. Lo habrán notado y mejorarán.

Lo que es difícil:

  1. Debe tener en cuenta las fluctuaciones de recursos (CPU / ancho de banda de red / velocidad de HDD principalmente)
  2. Debe extrapolar el tiempo que llevará predecir el comportamiento (lo que la copia de archivos de Windows definitivamente hace mal en este momento).
  3. Realice ajustes con el tiempo a su estimación original (¡quiero decir pequeños ajustes que no son como en la imagen divertida de arriba!)

Para esto, no solo la cantidad de bytes sino la cantidad de archivos a crear juegan un papel. Si tiene un millón de archivos de 1 KB o mil archivos de 1 MB, la situación será bastante diferente porque el primero tiene la sobrecarga de crear muchos archivos. Dependiendo del sistema de archivos utilizado, esto podría llevar más tiempo que la transferencia de datos.

Este diálogo me volvió loco también un par de veces:

  • En un sistema WinNT anterior, si tenía muchos archivos pequeños para copiar, mostraba el nombre y una animación agradable para cada archivo que ralentizaba todo el proceso para que fuera prácticamente inutilizable.

La copia moderna de Windows no es mucho mejor:

  • Para calcular la cantidad de datos a transferir, parece hacer una búsqueda primero (eso es lo que supongo que hace), por lo que lleva años si selecciona muchos directorios hasta que efectivamente comience a hacer el trabajo.
  • Algunos tiempos de espera incorporados impiden que se copien archivos grandes (> 60 GB en mi sistema). El dolor es que te dice que después de haber copiado ya más de 30 GB a través de la red y esto se pierde ancho de banda y tiempo porque tienes que reiniciar desde cero.
  • La copia de archivos de una computadora a otra es muy lenta por alguna razón. (Quiero decir, en comparación con el ancho de banda de red disponible, usar otras herramientas es más rápido, por lo que no es una limitación computacional).
jdehaan
fuente
¡Muy interesante!
Maxim Zaslavsky
48

Raymond Chen escribió un muy buen artículo sobre esto una vez. Básicamente, el diálogo es solo adivinar :).

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

"Debido a que el diálogo de copia es solo una adivinanza. No puede predecir el futuro, pero se ve obligado a intentarlo. Y al comienzo de la copia, cuando hay muy poca historia por recorrer, la predicción puede ser realmente mala".

Aquí hay una analogía: supongamos que alguien le dice: "Voy a contar hasta 100, y usted necesita dar estimaciones continuas sobre cuándo terminaré". Comienzan, "uno, dos, tres ...". Te das cuenta de que van a aproximadamente un número por segundo, por lo que estimas 100 segundos. Uh-oh, ahora se están desacelerando. "Cuatro ... ... ... cinco ... ... ..." Ahora tienes que cambiar tu estimación a unos 200 segundos. Ahora se aceleran: "seis-siete-ocho-nueve" Tienes que actualizar tu estimación nuevamente.

Ahora, alguien que está escuchando solo sus estimaciones y no la persona que cuenta cree que está fuera de control. Su estimación pasó de 100 segundos a 200 segundos a 50 segundos; ¿Cuál es tu problema? ¿Por qué no puedes dar una buena estimación?

Copiar archivos es lo mismo. El shell sabe cuántos archivos y cuántos bytes se copiarán, pero no sabe qué tan rápido será el disco duro, la red o Internet, por lo que solo tiene que adivinar. Si el rendimiento de la copia cambia, la estimación debe cambiar para tener en cuenta la nueva tasa de transferencia ".

RD
fuente
8
La analogía que está dando puede resumirse en una palabra: estadísticas.
Surfasb
33

Voy a contar hasta diez, 1....2....3....4¿cuántos puntos se necesitarán para llegar a 10?

5.6.7¿Qué te parece ahora? ¿Toma en cuenta todos los puntos pasados ​​entre los números y lo promedia, solo toma los últimos 4 intervalos y usa ese promedio, solo mira el último intervalo?

Tiene el mismo problema con las transferencias de archivos. La velocidad que transfiere el archivo no es constante, se acelera y se ralentiza en función de muchos factores. La razón por la que el número salta tanto es porque Microsoft se inclinó hacia el lado "solo cuenta el último intervalo" del espectro.

No hay nada de malo en ese lado del espectro, le brinda "segundos por segundo" más precisos (un segundo en tiempo real hace que el contador baje un segundo), pero esto hace que la ETA total del temporizador salte mucho .

Un buen ejemplo del lado opuesto es 7-Zip cuando se está comprimiendo. Si la velocidad de la compresión disminuye a medida que se procesa, puede ver que el ETA no salta dramáticamente como un ETA de transferencia de archivos, pero puede tomar de 2 a 3 segundos reales antes de que el temporizador funcione un segundo (o incluso puede comenzar a contar ) hasta que se estabilice a la nueva velocidad.

Scott Chamberlain
fuente
2
Me pega por qué no hicieron un promedio móvil exponencial o regular ...
Mehrdad
@Mehrdad Creo que las versiones más recientes de Windows sí, el tiempo ETA se comporta mucho más como 7zip en Windows 7 y más reciente.
Scott Chamberlain
15

En realidad, hay una respuesta casi canónica por parte de Raymond Chen de Microsoft sobre esto desde WAAAAAY, y hay algunas piezas en el rompecabezas.

Porque el diálogo de copia es solo adivinar. No puede predecir el futuro, pero se ve obligado a intentarlo. Y al comienzo de la copia, cuando hay muy poca historia, la predicción puede ser realmente mala.

En primer lugar, que Windows está adivinando. Sabe cuántos archivos y cuán grandes son, pero la velocidad de transferencia por archivo es muy variable. Depende de cosas como el tamaño, o incluso la ubicación en el disco en algunos casos. A medida que pasa el tiempo, está ajustando su estimación en función de las condiciones actuales y pasadas, y como tal tiene velocidades de transferencia estimadas inexactas en condiciones del mundo real.

Journeyman Geek
fuente
Un poco interesante, el primer comentario en 2004 describe el menú desplegable de información de copia de archivo detallado que muestra los bytes restantes que no se introdujeron hasta 2006 en Vista.
Scott Chamberlain
2
Sí, alguien en el chat también señaló esto. Estoy tentado a decir que eso resuelve el problema de que el usuario mire fijamente en el momento de la finalización, dándole gráficos coloridos para que los mire fijamente :)
Journeyman Geek
@JourneymanGeek "alguien en el chat" informando! Sí, si bien esta es una fuente bastante autorizada, es importante tener en cuenta que es de 2004, y está muy desactualizada y probablemente solo esté vagamente relacionada con los algoritmos actuales en uso en Windows 8.
Bob
1
Aquí hay una publicación de blog relacionada en Windows 8: "Es casi imposible estimar el tiempo restante para completar una copia con precisión ... En lugar de invertir mucho tiempo con una estimación de baja confianza que solo mejoraría ligeramente sobre el actual, nos enfocamos en presentar la información que teníamos confianza ... "
Kelly Thomas
12

Aquí está la explicación de Raymond Chen , ingeniero principal de diseño de software en Microsoft:

¿Por qué el diálogo de copia da estimaciones tan horribles?

Porque el diálogo de copia es solo adivinar. No puede predecir el futuro, pero se ve obligado a intentarlo. Y al comienzo de la copia, cuando hay muy poca historia, la predicción puede ser realmente mala.

Aquí hay una analogía: supongamos que alguien le dice: "Voy a contar hasta 100, y usted necesita dar estimaciones continuas sobre cuándo terminaré". Comienzan, "uno, dos, tres ...". Te das cuenta de que van a aproximadamente un número por segundo, por lo que estimas 100 segundos. Uh-oh, ahora se están desacelerando. "Cuatro ... ... ... cinco ... ... ..." Ahora tienes que cambiar tu estimación a unos 200 segundos. Ahora se aceleran: "seis-siete-ocho-nueve" Tienes que actualizar tu estimación nuevamente.

La publicación del blog citada anteriormente tiene una larga discusión sobre este tema, con algunos comentarios interesantes.

Raymond Chen es una persona legendaria, "Chuck Norris de Microsoft", no creo que vaya a obtener una respuesta más autorizada. Estoy seguro de que al menos había visto el código en cuestión.

haimg
fuente
9

La razón obvia es que la velocidad de la transferencia varía con el tiempo, y también lo hace el promedio, y también lo hace la predicción. Para explicar esto a un amigo no técnico, he usado una analogía que implica viajar en avión. Vas a volar sobre el Atlántico. Cuando llegue con un taxi al aeropuerto de salida, su ETA es de aproximadamente dos meses. Cuando desembarque en el aeropuerto de llegada, en función de su velocidad promedio hasta el momento, llegará a la casa de su amigo en 5 segundos.

Pero debe apreciar cuánto puede variar realmente la velocidad, incluso con lo que parece un escenario predecible, como copiar archivos dentro del mismo disco o entre dos discos locales. Una de las nuevas características que me gustan en Windows 8 es la capacidad de graficar la velocidad con el tiempo si hace clic en "más detalles". Si no tiene acceso a una máquina con Windows 8, busque imágenes para el cuadro de diálogo de copia de Windows 8 para obtener muchos ejemplos. Muchos de ellos son bastante planos, pero muchos de ellos también son inquietantemente accidentados, hasta el punto de que te preguntas si el disco duro es realmente saludable, cuando se hunde a cero.

Es probable que algunos de estos baches se deban a variaciones en el tamaño del archivo (los campos más pequeños producen más accesos, lo que ralentiza las cosas, especialmente en un disco duro mecánico que debe buscar moviendo su cabezal de lectura), pero algunos pueden ser simplemente un disco barato que se detiene en el más mínimo toque para evitar daños en los platos.

Hay mejores y peores algoritmos de predicción de ETA, pero para una predicción precisa, la computadora tendría que saberlo todo. El riesgo de intentar hacer que el algoritmo sea "inteligente" es que podría crear casos nuevos e imprevistos en los que es aún más hilarantemente incorrecto.

Diálogo de copia de Windows 8

Diálogo de copia de Windows 8 2

nitro2k01
fuente
4

La única forma de saber cuánto tiempo llevará comprimir un conjunto de archivos es comprimirlos. A veces, la mejor suposición de Windows está cerca, a veces está muy mal. Lo mismo ocurre con la copia de grandes cantidades de archivos, como estoy seguro de que has notado.

No es tanto un error como una exhibición inútil de información rara vez precisa. La mejor manera de solucionarlo es cerrar los ojos. Ignoralo. ;-)

Quizás haya un programa que pueda copiar / comprimir archivos y hacer que suene una alarma cuando finalice. Eso sería realmente útil. Podríamos tomar una pequeña siesta mientras esperamos que Windows termine la limpieza de la casa.

Steve Rindsberg
fuente
4

Creo que la razón se explicó muy bien en uno de los comentarios de la publicación del blog vinculada por la respuesta de Roald:

Tiene un algoritmo de estimación horrible. No hay excusas Si tiene que copiar 1000 archivos de 1 KB y 10 archivos de 1 MB, cree que estará tan ocupado con el archivo de 1 MB como con los archivos de 1 KB.

La razón por la que da estimaciones tan horribles es que no está bien hecho. Obviamente, nunca puede ser 100% preciso, pero podría ser mucho, mucho mejor.

Thomas Bonini
fuente
1
Saber qué tan grande es un archivo en Windows requiere abrirlo, y abrir un archivo en Windows significa leerlo. Y en lugar de abrir todos los archivos para ver qué tan grandes son para obtener una buena estimación de cuánto tiempo tomará la copia, Windows decide usar su tiempo para copiar los archivos; después de todo, eso es lo que le pidió que hiciera.
SecurityMatt
1
@SecurityMatt: Si ese fuera el caso, tomaría años obtener una lista del directorio. Estoy seguro de que los tamaños de archivo se almacenan en el directorio y se actualizan cada vez que se cambia el archivo. Por lo tanto, debe haber una manera de obtener una estimación rápida y bastante precisa del tiempo de copia en función de los tamaños de archivo enumerados en el directorio y algunas suposiciones sobre la velocidad de transferencia. Un sistema operativo realmente inteligente prestaría atención a la velocidad de transferencia promedio a lo largo del tiempo y la usaría en sus estimaciones.
RobH
4

Para acelerar el proceso de copia (no gastar demasiado tiempo calculando estimaciones de tiempo en lugar de realizar operaciones relacionadas con la copia), la utilidad de copia de Windows integrada en el Explorador mantiene una cantidad limitada de información sobre la rapidez con que se completaron las operaciones de escritura anteriores. Cada vez que necesita calcular el tiempo restante, solo calcula la cantidad promedio de tiempo que las operaciones de escritura han estado tomando y luego se multiplica por el número de operaciones de escritura restantes.

El problema es que la cantidad de tiempo que lleva realizar una operación de escritura no es constante; en realidad, puede variar significativamente. Esto, a su vez, produce cambios significativos en la estimación del tiempo.

Brian Gradin
fuente
No creo que tenga toda la razón en esto: puede mantener un promedio utilizable de escrituras usando solo 2 números: el promedio actual [ A] y el número de puntos de datos utilizados para obtener ese promedio [ n]. Luego, para actualizarlo, es solo un caso de (A*n + [New value])/[n+1]. Además, dado que las operaciones de copia casi siempre están vinculadas a IO y no a la CPU, un cálculo simple como ese cada pocos segundos no es nada. Por otro lado, mantener un promedio de las últimas nescrituras requiere una matriz / cola / pila de nelementos, para que sepa qué valor se debe desalojar.
Básico
¡Buen punto! Entonces, ¿por qué diablos está tan por todas partes? : P
Brian Gradin
Supongo que intentaron ser inteligentes haciendo un promedio más receptivo, teniendo en cuenta solo las últimas escrituras, y seleccionaron muy pocas. Dicho esto, no tengo la fuente, ¿quién sabe?
Básico
4

Hay 3 factores a tener en cuenta:

  1. El tamaño total de la transferencia.
  2. El número de archivos a transferir.
  3. El "ajetreo" de los medios, y posiblemente la conexión.

Los números 1 y 3 parecen tener el efecto más obvio en el cálculo del tiempo de transferencia, pero muchas personas no tienen en cuenta el número 2. Esto puede tener un gran efecto sobre cuánto tiempo llevará la transferencia y es difícil de cuantificar.

Básicamente, cada vez que se escribe un archivo, el sistema de archivos necesita escribir un poco de metadatos sobre el archivo, por ejemplo. propiedad, permisos, tiempos de creación / modificación / acceso, etc. Dependiendo del sistema de archivos en particular, esta información puede escribirse en una parte del disco muy 'lejos' de donde se está escribiendo el archivo. Esta sobrecarga del sistema de archivos es lo que puede hacer que una transferencia aparentemente simple tarde mucho tiempo y / o haga que la estimación del tiempo fluctúe enormemente.

Por ejemplo: al transferir un archivo grande, notará que la estimación se mantiene estable y es bastante precisa, pero la transferencia de cientos de archivos de diferentes tamaños, pero el mismo tamaño total, puede llevar más tiempo y hacer que la estimación de tiempo se ajuste.

Sammitch
fuente
4

Hay tres deficiencias en los algoritmos de estimación actuales.

Contrariamente a la creencia popular, no son lo suficientemente difíciles como para levantar las manos.

La razón por la que la mayoría de las personas que escriben los blogs, y las personas aquí no son conscientes de la posibilidad, es lo mejor que puedo decir debido al campo de estudio y la amplitud de la educación. Un remedio modesto pero también muy cómodo debería ser posible para [un graduado con capacitación más reciente que los escritores de blogs] [una compañía multimillonaria] Microsoft.

Intentaré explicar a grandes rasgos por qué.


Los puntos de falla son los siguientes. El núcleo:

1. no puede predecir de manera confiable la carga de E / S futura debido a circunstancias fuera del alcance del núcleo

  • No se debe hacer nada al respecto, ya que es un problema P = NP muy ilimitado.

2. no rastrea la heurística IO en ningún nivel útil de detalle. La utilización es un concepto mucho más amplio que la velocidad de lectura / escritura de disco / red .

  • se necesita hacer muy poco al respecto, poco más que rastrear la información de uso de IO más básica

    • del disco
      • la velocidad media de lectura dimensión 1a
      • la velocidad de escritura promedio de los archivos dimensión 2a
    • por cuarentena * según
      • la dimensión de tamaño del archivo b
      • la ubicación del archivo en la dimensión de disco c
    • * cuantificado en [probable] no más de 3 categorías. La reducción de la dimensionalidad nos ayudaría a determinar con certeza, pero 3 debería ser suficiente para (probablemente bastante efectivo) mecanismos de predicción mejores que nada:
      • tamaño del archivo
        • ligero
        • medio
        • pesado
      • ubicación [informa de la latencia de búsqueda]
        • comenzando
        • medio
        • tú entiendes
      • el tamaño y la ubicación del archivo son redundantes / superpuestos con la velocidad de lectura / escritura, esto es intencional
    • necesitamos saber qué tan "ocupado" ha estado el disco para poder asumir que seguirá siendo esa dimensión ocupada d
      • calculado a partir de la cantidad de archivos que se leen, convolucionados con sus respectivos pesos
      • se usa para estimar el tiempo al inicio de la copia ... diálogo basado en la carga esperada futura si todo lo demás aparte de este diálogo de copia continúa como está ahora
    • el método de grabación con el propósito de ... aquí es patentable

3. si fueran rastreados , no tendrían uso para la heurística

  • poco se ha hecho aquí, donde hacemos la mayor parte del trabajo
  • aquí es donde ponemos los datos del # 2 para usar
    • análisis estadístico aproximado de los pesos y ubicaciones de los archivos para determinar cuánto saltaremos. El peso + ubicación nos da una predicción
    • combinar con los pesos y ubicaciones actuales de carga de disco
    • para estimar lo que creemos que la velocidad promedio de lectura / escritura del número de archivos será la dimensión f
    • que comparamos para afinar nuestro modelo
    • lo que nos permitirá estimar con bastante precisión la barra de progreso y el tiempo de finalización
  • El método de análisis con el propósito de predecir ... aquí es patentable

El punto de todo esto es que nuestro modelo es solo 2a = F * (bxc) + d complejo

Donde a, byc tienen 3 estados cada uno: el administrador de archivos mira los archivos (o solo los metadatos) antes de copiar, y F * (bxc) + d no es un cálculo costoso; si desea algo más preciso, use una tabla de búsqueda con más estados; casi no hay ningún cálculo.

nota: las dimensiones aquí son para un plato, serían diferentes con un SSD; principio / medio / final no importaría

La diferencia clave entre lo que describí y las implementaciones anteriores que hemos visto hasta ahora sería, en resumen, observar el tamaño del archivo y la distribución / entropía del archivo en el disco y usarlo para explicar [más] con precisión el elemento de tiempo del uso del disco.

(la patente se deja como ejercicio para el lector ...)

Aumentar
fuente
@Twisty ya terminé, ¿cómo está ahora?
paIncrease
Mucho mejor. Buena suerte con el sitio y gracias por unirte a la comunidad.
Digo reinstalar a Mónica el
3

Hay muchas variables "desconocidas" cuando intentas predecir cuánto tiempo tomará algo. Por ejemplo, si bien el programa sabe que hay 3500 archivos y que los archivos ascienden a 3,5 GB (3500 MB), ¿eso significa que cada archivo tiene 1 MB? No necesariamente. Podría haber muchos archivos de 4 KB, y muchos archivos de 100 MB, y algunos otros en el medio. Además, debe tener en cuenta de dónde provienen los archivos y hacia dónde van (por ejemplo, los medios de comunicación). ¿Cuál es el mayor cuello de botella? ¿Cómo cuentas tratando de copiar archivos de un HDD a través de un túnel VPN ? Usted da el mejor escenario y luego ajusta sus contadores en tiempo real. Es por eso que ves que esos medidores de progreso cambian sobre la marcha.

JSanchez
fuente
2

El modelo matemáticamente correcto es hacer un promedio y una extrapolación ingenuos:

transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed

La razón es que, según la Ley de Grandes Números, las fluctuaciones locales se cancelarán en la velocidad de transferencia promedio , y esto le dará el resultado más estable.

Lo que Microsoft parece hacer es calcular la velocidad de transferencia en el último período de tiempo. Esto significa que cada fluctuación local cambia el resultado significativamente.

ybungalobill
fuente
2
Su modelo no manejará adecuadamente las perturbaciones de larga duración, como comenzar otras transferencias de archivos en paralelo, y continuará diciéndome que solo tomará 5 minutos más a pesar de que la misma cantidad de datos solo tomó 20 minutos. Una media móvil ponderada podría ser más precisa.
Daniel Beck
@DanielBeck: No es exactamente correcto. El tiempo esperado aumentará gradualmente. La pregunta es ¿qué tan rápido aumentará? Bueno, depende del tiempo transcurrido. Si fue una operación larga, por ejemplo, ya se estaba copiando durante 5 horas, entonces no aumentará mucho la expectativa. Pero, ¿la imprecisión de 15 minutos es importante para una operación de 5 horas? No. El punto es que te da la mejor aproximación en términos de error relativo. Además, no puede hacer algo que funcione mucho mejor en cada escenario.
ybungalobill
2
El problema de su modelo es que no reacciona absolutamente a los cambios en la velocidad de transferencia a mitad de la transferencia. Esto será tan insufrible como la rápida transferencia de archivos de Windows Ejemplo : transferencia de 60 GB a 10 MB / s al principio. Tiempo restante al inicio: 100min. Transfiera 54GB y baje a 2MB / s. Después de 90 minutos: Tiempo estimado restante en 54GB: 10min. Tiempo real dejado en 54GB: 50min. Después de 115 minutos : Tiempo estimado restante en 57GB: 6min. Tiempo real dejado en 57GB: 25min. Después de 131.67 minutos : Tiempo estimado restante en 59GB: 2.23 minutos. Tiempo real dejado en 59GB: 8.33 minutos.
Daniel Beck
@DanielBeck: toda la transferencia dura 150 minutos, por lo que el error relativo máximo es del 50% al comienzo de la transferencia, donde no puede hacer nada mejor. En el 54 GB es solo ~ 14% de descuento del total. (si te toma 150 minutos, ¿por qué importan 20 minutos?) En realidad, una muy buena estimación ... Dicho esto, entiendo tu punto. La manera de mejorar esto es no ponderada media móvil porque no se puede saber qué tamaño de la ventana debe ser (esta operación no espera que tenga minutos como copiar un archivo,
ybungalobill
u horas a través de un protocolo de intercambio de archivos p2p donde obtienes 10 minutos de 10 MB / sy 10 minutos de 0 MB / s). La forma de mejorar esto es tomar el promedio ponderado por tiempo, no por tamaño.
ybungalobill
1
There is some way to refine or correct this kind of "bug"?

Como dijo Roald van Doorn, básicamente es solo adivinar. Por supuesto, eso no significa que no podría ser un mejor adivinador. Hay muchas heurísticas que podrían usarse para calcular esto.

  1. La mejor manera, la más costosa, sería mantener un historial de 'copias' anteriores y luego usar algoritmos de inteligencia artificial para calcular una suposición
  2. Se podría construir una fórmula basada en la investigación de cuánto tiempo debería tomar. Podrían tener en cuenta cosas como: sistema de archivos, número de archivos, tamaño de los archivos, tiempo de búsqueda del disco, velocidades de lectura / escritura masivas del disco, ubicación de los archivos en el disco (fragmentación), utilización actual del disco.
  3. Una mezcla de los dos. Es decir. haga algunos puntos de referencia para averiguar cuánto tiempo tardan ciertas operaciones y luego utilícelas como un historial para fórmulas simples.

Obviamente, nada de esto se implementa fácilmente ... y solo mencioné copias de archivos. Debería realizarse un trabajo similar para todo tipo de transferencias.
La pregunta que debe hacerse: ¿preferiría Microsoft pasar su tiempo dándole una mejor estimación o preferiría que hicieran que sus archivos se transfieran más rápido?

Sin embargo, si comprime algo con 7-zip, notará que es mucho mejor adivinar que Windows. Dudo que esté haciendo algo tan complicado, solo un adivinador un poco mejor.

usuario606723
fuente
1

En resumen, el cálculo se basa en la velocidad de transferencia actual .

Por ejemplo: si su velocidad de transferencia se hunde porque Windows tiene que copiar una gran cantidad de archivos pequeños, el tiempo esperado aumenta linealmente y viceversa para archivos grandes.

Es casi imposible predecir cuál será la velocidad de transferencia durante todo el proceso de transferencia, porque depende de muchos factores como el tamaño del archivo, el uso de la CPU, los errores de transmisión, etc.

klingt.net
fuente
1

Hay algunas respuestas interesantes en la publicación del blog de MSDN Mejorando nuestros conceptos básicos de administración de archivos: copie, mueva, cambie el nombre y elimine sobre esto. En cuanto a por qué es difícil:

Es casi imposible estimar el tiempo restante para completar una copia con precisión porque hay muchas variables impredecibles e incontrolables involucradas, por ejemplo, ¿cuánto ancho de banda de red estará disponible para la duración del trabajo de copia? ¿Su software antivirus se activará y comenzará a escanear archivos? ¿Necesitará otra aplicación acceder al disco duro? ¿Comenzará el usuario otro trabajo de copia?

Y cómo están mejorando,

En lugar de invertir mucho tiempo para llegar a una estimación de baja confianza que solo mejoraría ligeramente con respecto a la actual, nos centramos en presentar la información en la que confiamos de una manera útil y convincente. Esto brinda la información más confiable que tenemos disponible para que pueda tomar decisiones más informadas.

Dicho esto, si realmente quieres mejorar solo la estimación dada y mantener la barra de progreso como está, puedes hacer algo sugerido en un comentario de Slashdot :

Mantenga una tabla de velocidades esperadas para cada dispositivo de almacenamiento en el sistema de archivos. Registre cuánto tiempo lleva leer la información del sistema de archivos. Cuando se monta un dispositivo, si es razonable para el tipo de dispositivo, busque en el medio y el extremo, midiendo las velocidades allí también. Obtenga curvas aproximadas para las velocidades de lectura y escritura en diferentes ubicaciones, y úselas para estimaciones futuras. Para futuras operaciones de lectura y escritura, tome nota de dónde están y qué tan rápido van, y ajuste las curvas en consecuencia.

Cuando comienza una operación, mire las curvas de entrada y salida para los dispositivos respectivos. Encuentre la velocidad esperada para la ubicación objetivo. Cualquiera que sea la velocidad más baja debe usarse para la estimación.

eis
fuente
1

Solo quería agregar que el número total de archivos es fácilmente el factor que consume más tiempo de las operaciones de copia de archivos en una PC. Siempre puedo recordar como un joven estudiante, induciendo deliberadamente fallas de PC en mi clase de computación al comenzar con 1 archivo sin contenido, y copiarlo, luego seleccionar los 2 archivos y copiarlos de nuevo y así sucesivamente. Una vez que pasó más de 1024 archivos, comenzó a tomar una gran cantidad de tiempo para hacer cualquier cosa, incluso cuando no estaba copiando ninguna información, excepto el encabezado del archivo. Pruébelo usted mismo incluso en un nuevo sistema operativo, copia exponencial de archivos y verá lo que sucede. Comida para el pensamiento.

Daft Gowk
fuente
Si bien es interesante, esto no responde la pregunta. Lea cómo responder antes de responder.
usuario 99572 está bien el
0

Acabo de copiar 200GB de USB HDD a mi disco principal. Había alrededor de 130000 archivos

Después de los primeros 4-5 minutos, observé que:

  • Para los archivos más pequeños, la velocidad era de aproximadamente 100 archivos por segundo a aproximadamente 600 KB / s
  • Y para archivos grandes era como 70 MB / s

Al principio, Windows cambió la estimación de 1 hora a más de 5 horas, luego volvió a 1 hora y así sucesivamente. Al final, como en el 95%, todavía estaba cambiando la estimación de 10 minutos a más de 10 horas. Entonces, en lugar de volverse más preciso, iba cada vez menos preciso.

Espectáculos matemáticos simples:

130,000 archivos a 100 archivos por segundo = 22 minutos

200,000 MB a 70 MB por segundo = 47 minutos

22 minutos: perdido en el tiempo de búsqueda, copiando archivos de pocos kilobytes de tamaño. 47 minutos: el tiempo que necesitará para transferir los datos reales si no hay tiempo de búsqueda.

La suma de los 22min + 47min es el tiempo máximo absoluto que podría tomar.

Entonces, obviamente, la estimación debe estar entre 47 y 69 minutos.

Lo que el cuadro de diálogo muestra aproximadamente al 90%: "Estoy copiando algunos archivos pequeños a 1 MB / s, hay 20 GB más de datos, tardará 5:30 horas en completarse.

Pocos segundos después: "Estoy copiando un archivo grande aquí, a 70mb / s, tardará 4 minutos en completarse.

Lo que los humanos realmente ven desde el mismo diálogo: 120,000 archivos y 180GB ya están copiados por 40 minutos. El resto de 10000 archivos y 20 GB deberían tomar unos 5 minutos

El cuadro de diálogo proporciona información suficiente para realizar cálculos que se vuelven cada vez más precisos. Sabe a qué velocidad se copian los archivos pequeños. Sabe a qué velocidad se copian los archivos grandes. También sabe cuántos archivos y cuántos bytes quedan.

Es tan simple hacer una suposición tan precisa solo estableciendo el límite superior e inferior.

El cuadro de diálogo muestra datos un poco más correctos solo en caso de que los archivos grandes estén antes que los archivos pequeños. Si este es el caso, comienza a los 40 minutos, y después de 30 minutos comienza a copiar archivos pequeños y dice "bueno, necesito 20 minutos más".

Pero cuando los archivos pequeños al principio y los archivos grandes están al final. El diálogo en realidad no le importa a qué "archivos por segundo" transfiere los archivos pequeños. Hace su cálculo como si el recuento de archivos pequeños fuera infinito, y eso siempre será pequeño.

Xizario
fuente
Esto en realidad no responde la pregunta.
DavidPostill
En realidad lo responde, si estás leyendo con cuidado. Son dos tipos de mala estimación y he explicado por qué suceden desde un punto de vista de ingeniería inversa basado en ejemplos.
Xizario