Caixa de diálogo de cópia de arquivos do Windows: Por que a estimativa é tão… BAD?

Question

xkcd

Eu sei que o diálogo de cópia do Windows (no Windows XP) armazena a cópia na memória primeiro, e ainda está copiando depois que a caixa de diálogo fecha, então o tempo está desligado, mas por que a estimativa do tempo fazer uma cópia tão imprecisa, mesmo quando a cópia da memória foi desativada (no Vista e no Windows 7)? Parece tão arbitrário! Como funciona todo o procedimento de cópia e por que o Windows não pode estimar corretamente?

    

Answer 1

Resumindo: os algoritmos pobres e a estimativa saltitante são, na verdade, uma fraqueza na implementação.

Outras ferramentas, como o TeraCopy , fazem um trabalho melhor. Acho que não vale a pena explicar por que a implementação deles não é boa. Eles terão notado e irão melhorar.

O que é difícil:

1. Você precisa levar em conta as flutuações de recursos (CPU / largura de banda da rede / velocidade do HDD principalmente)
2. Você precisa extrapolar o tempo necessário para prever o comportamento (o que a cópia de arquivos do Windows faz definitivamente agora).
3. Faça ajustes no tempo ao longo de sua estimativa original (quero dizer, pequenos ajustes que não são como na foto engraçada acima!)

Para isso, não apenas a quantidade de bytes, mas a quantidade de arquivos para criar desempenham um papel. Se você tiver um milhão de arquivos de 1KB ou mil arquivos de 1MB, a situação será bem diferente porque o primeiro tem a sobrecarga de criar muitos arquivos. Dependendo do sistema de arquivos usado, isso pode levar mais tempo do que realmente transferir os dados.

Esse diálogo me deixou louco muitas vezes:

• Em um sistema WinNT mais antigo, se você tivesse muitos arquivos pequenos para copiar, ele exibia o nome e uma animação interessante para cada arquivo, tornando mais lento todo o processo para ficar praticamente inutilizável.

A cópia moderna do Windows não é muito melhor:

• Para calcular a quantidade de dados a transferir, parece fazer uma pesquisa primeiro (é o que eu suponho que faz), portanto, leva muito tempo se você selecionar vários diretórios até que efetivamente comece a fazer o trabalho.
• Algum tempo limite interno impede que arquivos grandes sejam copiados (> cerca de 60 GB em meu sistema). A dor é que ele diz que depois de ter copiado já mais de 30GB pela rede e isso é perdido a largura de banda e tempo, porque você tem que reiniciar do zero!
• A cópia de arquivos de um computador para outro é extremamente lenta por algum motivo. (Quero dizer, comparado com a largura de banda de rede disponível, usando outras ferramentas é mais rápido, portanto não é uma limitação computacional.)

Answer 2

Raymond Chen escreveu um artigo muito bom sobre isso uma vez. Basicamente, o diálogo é apenas uma suposição:).

link

"Because the copy dialog is just guessing. It can't predict the future, but it is forced to try. And at the very beginning of the copy, when there is very little history to go by, the prediction can be really bad.

Here's an analogy: Suppose somebody tells you, "I am going to count to 100, and you need to give continuous estimates as to when I will be done." They start out, "one, two, three...". You notice they are going at about one number per second, so you estimate 100 seconds. Uh-oh, now they're slowing down. "Four... ... ... five... ... ..." Now you have to change your estimate to maybe 200 seconds. Now they speed up: "six-seven-eight-nine" You have to update your estimate again.

Now somebody who is listening only to your estimates and not the the person counting thinks you are off your rocker. Your estimate went from 100 seconds to 200 seconds to 50 seconds; what's your problem? Why can't you give a good estimate?

File copying is the same thing. The shell knows how many files and how many bytes are going to be copied, but it doesn't know know how fast the hard drive or network or internet is going to be, so it just has to guess. If the copy throughput changes, the estimate needs to change to take the new transfer rate into account."

    

Answer 3

Eu vou contar até dez, 1....2....3....4 quantos pontos serão necessários para chegar a 10?

5.6.7 E agora? Você leva em conta todos os pontos passados entre os números e a média, você só pega os últimos 4 intervalos e usa essa média, você só olha para o último intervalo?

Você tem o mesmo problema com as transferências de arquivos. A velocidade que o arquivo transfere não é constante, acelera e diminui com base em vários fatores. A razão pela qual o número salta tanto é que a Microsoft se inclinou para o lado "somente contar o último intervalo" do espectro.

Não há nada de errado com esse lado do espectro, ele fornece "segundos por segundo" mais precisos (um segundo em tempo real faz o contador diminuir um segundo), mas isso faz com que o ETA total do cronômetro salte em torno de muito.

Um bom exemplo do lado oposto é 7-Zip quando está sendo compactado. Se a velocidade da compressão cair à medida que for processada, você poderá ver que o ETA não salta drasticamente como um ETA de transferência de arquivos, mas pode levar de 2 a 3 segundos reais antes que o cronômetro desacelere um segundo (ou pode começar a contar ) até estabilizar à nova velocidade.

    

Answer 4

Na verdade, existe uma resposta quase canônica do Raymond Chen, da Microsoft, sobre isso de WAAAAAY de volta, e há algumas peças para o quebra-cabeça.

Because the copy dialog is just guessing. It can't predict the future, but it is forced to try. And at the very beginning of the copy, when there is very little history to go by, the prediction can be really bad.

Primeiramente, o Windows está adivinhando. Ele sabe quantos arquivos e quão grande eles são, mas a taxa de transferência por arquivo é altamente variável. Depende de coisas como tamanho ou até mesmo localização na unidade em alguns casos. Conforme o tempo passa, ele está ajustando seu palpite com base nas condições atuais e passadas e, como tal, você tem velocidades de transferência estimadas imprecisas em condições do mundo real.

    

Answer 5

Aqui está a explicação por Raymond Chen , engenheiro principal de design de software da Microsoft:

Why does the copy dialog give such horrible estimates?

Because the copy dialog is just guessing. It can't predict the future, but it is forced to try. And at the very beginning of the copy, when there is very little history to go by, the prediction can be really bad.

Here's an analogy: Suppose somebody tells you, "I am going to count to 100, and you need to give continuous estimates as to when I will be done." They start out, "one, two, three...". You notice they are going at about one number per second, so you estimate 100 seconds. Uh-oh, now they're slowing down. "Four... ... ... five... ... ..." Now you have to change your estimate to maybe 200 seconds. Now they speed up: "six-seven-eight-nine" You have to update your estimate again.

A postagem no blog citada acima tem uma longa discussão sobre isso questão, com alguns comentários interessantes.

Raymond Chen é uma pessoa lendária, "Chuck Norris da Microsoft", eu não suponho que você tenha uma resposta mais autoritária. Tenho certeza que ele tinha pelo menos visto o código em questão.

    

Answer 6

A razão óbvia é que a velocidade da transferência varia com o tempo, assim como a média, e também a previsão. Para explicar isso a um amigo não-técnico, usei uma analogia envolvendo viagens aéreas. Você vai voar sobre o Atlântico. Quando você chega com um táxi no aeroporto de partida, sua ETA leva cerca de dois meses. Quando você desembarcar no aeroporto de chegada, com base na sua velocidade média, chegará à casa do seu amigo em 5 segundos.

Mas você precisa avaliar o quanto a velocidade pode variar, mesmo com o que parece ser um cenário previsível, como copiar arquivos no mesmo disco ou entre dois discos locais. Um dos novos recursos que eu gosto no Windows 8 é a capacidade de representar graficamente a velocidade ao longo do tempo, se você clicar em "mais detalhes". Se você não tiver acesso a uma máquina com Windows 8, pesquise imagens para Windows 8 copie o diálogo para muitos exemplos. Muitos deles são relativamente planos, mas muitos deles também são perturbadores, a ponto de você se perguntar se o disco rígido é realmente saudável, quando se aproxima de zero.

Alguns desses solavancos são provavelmente devido a variações no tamanho do arquivo - campos menores geram mais acessos, o que atrasa as coisas, especialmente em um disco rígido mecânico que precisa ser movido pela cabeça de leitura - mas alguns podem ser apenas um acionamento barato que pára ao menor toque para evitar danos aos pratos.

Existem melhores e piores algoritmos de previsão ETA, mas para uma previsão precisa, o computador teria que ser onisciente. O risco de tentar tornar o algoritmo "inteligente" é que ele pode criar casos novos e imprevistos, em que é ainda mais hilariamente errado.

    

Answer 7

A única maneira de saber quanto tempo levará para compactar um conjunto de arquivos é comprimi-los. Às vezes, o melhor palpite do Windows é próximo, às vezes é totalmente errado. O mesmo acontece com a cópia de grandes números de arquivos, como tenho certeza de que você notou.

Não é tanto um bug quanto uma exibição inútil de informações raramente precisas. A melhor maneira de consertar isso é fechar os olhos. Ignore isto. ; -)

Talvez exista um programa que possa copiar / compactar arquivos e emitir um alarme quando terminar. Isso seria verdadeiramente útil. Podemos tirar uma soneca enquanto esperamos que o Windows termine a faxina.

    

Answer 8

Acho que o motivo foi bem explicado em um dos comentários do blog postar linkado pela resposta de Roald:

It has a horrible estimate algorithm. There are no excuses. If has to copy 1000 1KB files and 10 1MB files it thinks it will be as busy with the 1 MB file as with the 1KB files.

A razão que dá estimativas tão horríveis é que não é bem feito. Obviamente, nunca pode ser 100% preciso, mas pode ser muito, muito melhor.

    

Answer 9

Para agilizar o processo de cópia (não gastar muito tempo calculando estimativas de tempo em vez de executar operações relacionadas à cópia), o utilitário de cópia do Windows integrado ao Explorer mantém uma quantidade limitada de informações sobre a velocidade de conclusão das operações de gravação anteriores. Cada vez que precisa calcular o tempo restante, ele apenas calcula a quantidade média de tempo que as operações de gravação estão realizando e, em seguida, multiplica pelo número de operações de gravação restantes.

O problema é que a quantidade de tempo necessária para realizar uma operação de gravação não é constante - ela pode, na verdade, variar significativamente. Então, isso, por sua vez, produz mudanças significativas na estimativa de tempo.

    

Answer 10

Existem 3 fatores a serem considerados:

1. O tamanho total da transferência.
2. O número de arquivos a serem transferidos.
3. O "ocupado" da mídia e, possivelmente, a conexão.

Os números 1 e 3 parecem ter o efeito mais óbvio no cálculo do tempo de transferência, mas muitas pessoas não contabilizam o número 2. Isso pode ter um efeito enorme em quanto tempo o transferência vai demorar, e é difícil quantificar.

Basicamente, toda vez que um arquivo é gravado, o sistema de arquivos precisa escrever um pouco de metadados sobre o arquivo, por exemplo. propriedade, permissões, criação / modificação / tempos de acesso, etc. Dependendo do sistema de arquivos específico, essas informações podem ser gravadas em uma parte do disco muito 'distante' de onde o arquivo está sendo gravado. Essa sobrecarga do sistema de arquivos é o que pode fazer com que uma transferência aparentemente simples seja demorada e / ou fazer com que a estimativa de tempo flutue de forma descontrolada.

por exemplo: Ao transferir um arquivo grande, você perceberá que a estimativa é estável e precisa, mas transferir centenas de arquivos de tamanhos variados, mas com o mesmo tamanho total, pode levar mais tempo e fazer com que a estimativa de tempo apresente um ajuste .

    

Answer 11

Existem três deficiências nos algoritmos de estimativa atuais.

Ao contrário da crença popular, eles não são tão difíceis o suficiente para levantar nossas mãos.

A razão pela qual a maioria das pessoas escreve os blogs, e as pessoas aqui não estão cientes da possibilidade, é o melhor que eu posso dizer devido ao campo de estudo e à amplitude da escolaridade. Um remédio modesto mas também muito confortável deve ser possível para [um graduado com treinamento mais recente do que os escritores do blog] [uma empresa multibilionária] Microsoft.

Vou tentar explicar mais ou menos porquê.

Os pontos de falha são os seguintes. O kernel:

1. não é possível prever com segurança carga futura de E / S devido a circunstâncias fora do escopo do kernel

• nada deve ser feito sobre isso, pois é um problema P = NP muito ilimitado.

2. não rastreia heurísticas de IO em nenhum nível útil de detalhes. A utilização é um conceito muito mais amplo do que a velocidade de leitura / gravação em disco / rede .

• muito pouco precisa ser feito sobre isso, pouco mais do que rastrear as informações mais básicas sobre o uso de I / O

  • do disco
    • a velocidade média de leitura dimensão 1a
    • a velocidade média de gravação dos arquivos dimensão 2a
  • numa base por quanta * de acordo com
    • o tamanho do arquivo dimensão b
    • a localização do arquivo no disco dimensão c
  • * quantificado em [provavelmente] não mais de 3 categorias. A redução da dimensionalidade nos ajudaria a determinar com certeza, mas 3 deveria ser suficiente para mecanismos de previsão (provavelmente bastante eficazes) melhores do que nada:
    • tamanho do arquivo
      • luz
      • médio
      • pesado
    • localização [informa de latência de busca]
      • começando
      • meio
      • você começa o ponto
    • o tamanho e o local do arquivo são redundantes / sobrepostos com a velocidade de leitura / gravação, isso é intencional
  • precisamos saber como o disco "ocupado" está ocupado, para que possamos assumir que ele continuará sendo a dimensão d ocupada
    • calculado a partir da quantidade de arquivos que estão sendo lidos, convolvidos com seus respectivos pesos
    • usado para estimar o tempo no início da caixa de diálogo copiando ... com base na carga esperada futura se tudo além desse diálogo de cópia continuar como está agora
  • o método de gravação para propósito de ... aqui é patenteável

3. eles foram rastreados , não teriam uso para as heurísticas

• pouco foi feito aqui, onde fazemos a maior parte do trabalho
• é onde colocamos os dados de # 2 para usar
  • análise estatística aproximada dos pesos e locais dos arquivos para determinar o quanto de salto vamos fazer. O peso + localização nos dá uma previsão
  • combinam com os pesos e locais de carga de disco atuais
  • para estimar o que achamos que a velocidade média de leitura / gravação do número de arquivos dimensão f será
  • que comparamos para ajustar nosso modelo
  • que nos permitirá estimar com precisão a barra de progresso e o tempo até a conclusão
• o método de análise para fins de previsão ... aqui é patenteável

O ponto de tudo isso é que nosso modelo é apenas 2a = F * (b x c) + complexo d

Onde a, b e c têm 3 estados cada: o gerenciador de arquivos exibe os arquivos (ou apenas os metadados) antes de copiar, e F * (b x c) + d não é um cálculo caro; se você quiser algo mais preciso, use uma tabela de pesquisa com mais estados - não há praticamente nenhum cálculo.

nota: as dimensões aqui são para um prato, seria diferente com um SSD-- início / meio / fim não importaria

A principal diferença entre o que descrevi e as implementações anteriores que vimos até agora seria, em suma, observar o tamanho do arquivo e a distrubtion / entropy do arquivo no disco e usá-lo para [mais] contabilizar com precisão o elemento de tempo de uso do disco.

(a patente é deixada como um exercício para o leitor ...)

    

Answer 12

Existem muitas variáveis "desconhecidas" quando você está tentando prever quanto tempo algo vai levar. Por exemplo, enquanto o programa sabe que existem 3500 arquivos e que os arquivos são de 3.5 GB (3500 MB), isso significa que cada arquivo tem 1 MB? Não necessariamente. Pode haver muitos arquivos de 4 KB e muitos arquivos de 100 MB, além de outros in-between. Além disso, você deve levar em consideração de onde os arquivos estão vindo e para onde estão indo (por exemplo, mídia.) Qual é o maior gargalo? Como você conta ao tentar copiar arquivos de um disco rígido através de um túnel VPN ? Você dá o melhor cenário e ajusta seus contadores em tempo real. É por isso que você vê esses medidores de progresso mudando na hora.

    

Answer 13

O modelo matematicamente correto é fazer uma média e extrapolação ingênuas:

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

A razão é que, pela Lei dos Grandes Números, as flutuações locais serão canceladas na velocidade média de transferência , e isso lhe dará o resultado mais estável.

O que a Microsoft parece fazer é calcular a velocidade de transferência no último período de tempo. Isso significa que cada flutuação local altera significativamente o resultado.

    

Answer 14

There is some way to refine or correct this kind of "bug"?

Como Roald van Doorn disse, é basicamente apenas suposição. Claro, isso não significa que não poderia ser um melhor adivinhador. Existem muitas heurísticas que podem ser usadas para calcular isso.

1. A melhor maneira, mais cara, seria manter um histórico de 'cópias' anteriores e usar algoritmos de inteligência artificial para calcular um palpite
2. Pode-se construir uma fórmula baseada na pesquisa de quanto tempo ela deve levar. Eles poderiam levar em conta coisas como: sistema de arquivos, número de arquivos, tamanho dos arquivos, tempo de busca do disco, velocidade de leitura / gravação em massa, localização dos arquivos no disco (fragmentação), utilização atual do disco.
3. Uma mistura dos dois. Ie. faça alguns benchmarks para descobrir quanto tempo certas operações demoram e use-as como um histórico para fórmulas simples.

Obviamente, nada disso é facilmente implementado ... e eu mencionei apenas cópias de arquivos. Um trabalho semelhante precisaria ser feito para todos os tipos de transferências.
A questão que você tem que se perguntar - você preferiria que a Microsoft gastasse seu tempo dando uma estimativa melhor ou preferiria que eles fizessem sua transferência de arquivos mais rapidamente.

No entanto, se você comprimir algo com 7-zip, você notará que é muito melhor adivinhar do que o Windows. Eu duvido que esteja fazendo algo tão complicado, apenas um adivinhador um pouco melhor.

    

Answer 15

Em suma, o cálculo é baseado na velocidade de transferência atual .

Por exemplo: se a sua taxa de transferência sumir porque o Windows tem que copiar uma quantidade enorme de arquivos minúsculos, o tempo esperado sobe linearmente e vice-versa para arquivos grandes.

É quase impossível prever o que a velocidade de transferência será em todo o processo de transferência, porque depende de muitos fatores como tamanho do arquivo, uso da CPU, transmissão erros, etc.

    

Answer 16

Há algumas respostas interessantes na postagem do blog do MSDN Aprimorando nosso básico de gerenciamento de arquivos: copie, mova, renomeie e exclua sobre isso. Quanto ao porquê é difícil:

Estimating the time remaining to complete a copy is nearly impossible to do with any precision because there are many unpredictable and uncontrollable variables involved – for instance, how much network bandwidth will be available for the length of the copy job? Will your anti-virus software spin up and start scanning files? Will another application need to access the hard drive? Will the user start another copy job?

E como eles estão melhorando,

Rather than invest a lot of time coming up with a low confidence estimate that would be only slightly improved over the current one, we focused on presenting the information we were confident about in a useful and compelling way. This makes the most reliable information we have available to you so you can make more informed decisions.

Dito isto, se você realmente quer melhorar apenas a estimativa dada e manter a barra de progresso como está, você poderia fazer algo sugerido em um comentário do Slashdot :

Maintain a table of expected speeds for each storage device on the filesystem. Record how long it takes to read the filesystem information. When a device is mounted, if it's reasonable for the device type, seek to the middle and end, measuring speeds there, too. Get approximate curves for the read and write speeds across locations, and use those for future estimates. For future read and write operations, take note of where they are and how fast they go, and adjust the curves accordingly.

When an operation starts, look at the curves for input and output for the respective devices. Find the expected speed for the target location. Whichever speed is lower should be used for the estimate.

    

Answer 17

Só queria acrescentar que o número total de arquivos é facilmente o fator mais demorado de operações de cópia de arquivos em um PC. Eu sempre me lembro como um jovem estudante, induzindo deliberadamente a falha dos PCs na minha aula de computação começando com 1 arquivo sem conteúdo, copiando-o, depois selecionando os 2 arquivos e copiando novamente e assim por diante. Depois de passar de 1024 arquivos, começou a gastar muito tempo para fazer qualquer coisa, mesmo quando não estava copiando nenhuma informação, exceto no cabeçalho do arquivo. Tente você mesmo, mesmo em um novo SO, cópia de arquivo exponencial e você verá o que acontece. Alimento para o pensamento.

    

Answer 18

Acabei de copiar 200 GB do disco rígido USB para a minha unidade principal. Havia cerca de 130000 arquivos

Após os primeiros 4-5 minutos, observei que:

• Para os arquivos menores, a taxa era de cerca de 100 arquivos por segundo em cerca de 600KB / s
• E para arquivos grandes era como 70MB / s

No início, as janelas alteraram a estimativa de 1 hora para 5 ou mais horas e depois para 1 hora, e assim por diante. No final, como em 95%, ainda estava mudando a estimativa de 10 minutos para mais de 10 horas. Por isso, em vez de se tornar mais preciso, estava cada vez menos preciso.

A matemática simples mostra:

130.000 arquivos em 100 arquivos por segundo = 22 minutos

200.000 MB em 70 MB por segundo = 47 minutos

22 minutos - soltos em tempo de busca copiando arquivos de poucos kilobytes de tamanho. 47 minutos - o tempo necessário para transferir os dados reais, se não houver tempo de busca.

Soma dos 22min + 47min é o tempo máximo absoluto que pode ser necessário.

Então, obviamente, a estimativa deve estar entre 47 e 69 minutos.

O que a caixa de diálogo mostra em cerca de 90%: "Estou copiando alguns arquivos pequenos a 1MB / s, há 20 GB a mais de dados, levará 5:30 horas para ser concluído.

Alguns segundos depois: "Estou copiando um arquivo grande aqui, a 70mb / s, levará 4 minutos para ser concluído.

O que os humanos realmente vêem no mesmo diálogo: 120.000 arquivos e 180 GB já são copiados por 40 minutos. O resto de 10.000 arquivos e 20 GB deve levar cerca de 5 minutos

O diálogo fornece informações suficientes para fazer cálculos cada vez mais precisos a cada segundo. Ele sabe a taxa na qual pequenos arquivos são copiados. Sabe a que velocidade grandes arquivos são copiados. Também sabe quantos arquivos e quantos bytes restam.

É tão simples fazer suposições tão precisas apenas definindo o limite superior e inferior.

A caixa de diálogo mostra um pouco mais de dados corretos apenas quando os arquivos grandes estão antes dos arquivos pequenos. Se este for o caso, ele começa aos 40 minutos e, após 30 minutos, ele começa a copiar arquivos pequenos e diz "bem, preciso de mais 20 minutos".

Mas quando os arquivos pequenos no começo e os arquivos grandes estão no final. A caixa de diálogo não se importa com o que "arquivos por segundo" transfere os arquivos pequenos. Ele faz o seu cálculo como a contagem de arquivos pequenos é infinito, e que, como eles sempre serão pequenos.