xkcd

Sei que a caixa de diálogo de cópia do Windows (no Windows XP) armazena a cópia primeiro na memória e ainda está sendo copiada após o fechamento da caixa de diálogo. Portanto, o tempo acabou, mas por que a estimativa do tempo necessário para fazer uma cópia tão impreciso, 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?

Em resumo: os algoritmos ruins e a estimativa irregular são realmente uma fraqueza na implementação.

Outras ferramentas como o TeraCopy fazem um trabalho melhor. Eu 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.

Qual é a dificuldade:

1. Você deve levar em consideração as flutuações de recursos (largura de banda da CPU / rede / velocidade do disco rígido, principalmente)
2. Você precisa extrapolar o tempo que levará prevendo o comportamento (o que a cópia de arquivo do Windows definitivamente faz mal agora).
3. Faça ajustes ao longo do tempo de acordo com 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 a serem criados desempenham um papel. Se você tiver um milhão de arquivos de 1 KB ou milhares de arquivos de 1 MB, 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 também me deixou louco várias vezes:

• Em um sistema WinNT antigo, se você tinha muitos arquivos pequenos para copiar, ele exibia o nome e a bela animação de cada arquivo que atrasava todo o processo, tornando-o praticamente inutilizável.

O material moderno de cópia do Windows não é muito melhor:

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

Raymond Chen escreveu um artigo muito bom sobre isso uma vez. Basicamente, a caixa de diálogo está apenas adivinhando :).

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

"Como o diálogo de cópia é apenas adivinhador. Ele não pode prever o futuro, mas é forçado a tentar. E no início da cópia, quando há muito pouco histórico, a previsão pode ser muito ruim.

Aqui está uma analogia: suponha que alguém lhe diga: "Vou contar até 100 e você precisa fornecer estimativas contínuas sobre quando vou terminar". Eles começam: "um, dois, três ...". Você percebe que eles estão indo para cerca de um número por segundo, então estima 100 segundos. Agora eles estão diminuindo a velocidade. "Quatro ... ... ... cinco ... ... ..." Agora você precisa alterar sua estimativa para talvez 200 segundos. Agora eles aceleram: "seis-sete-oito-nove" Você precisa atualizar sua estimativa novamente.

Agora, alguém que está ouvindo apenas suas estimativas, e não a pessoa que conta, pensa que você está doido. Sua estimativa passou de 100 segundos para 200 segundos para 50 segundos; qual é o seu problema? Por que você não pode dar uma boa estimativa?

A cópia de arquivos é a mesma coisa. O shell sabe quantos arquivos e quantos bytes serão copiados, mas não sabe quão rápido será o disco rígido, a rede ou a internet, portanto, é preciso adivinhar. Se o rendimento da cópia for alterado, a estimativa precisará ser alterada para levar em consideração a nova taxa de transferência ".

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

5.6.7E agora? Você considera todos os pontos passados ​​entre os números e calcula a média, apenas toma os últimos 4 intervalos e usa essa média, olha apenas 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 aumenta tanto é que a Microsoft se inclinou para o lado "apenas 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 descer um segundo), mas isso faz com que a ETA total do temporizador salte bastante. .

Um bom exemplo do lado oposto é o 7-Zip quando está compactando. Se a velocidade da compactação cair enquanto processa, você poderá ver que o ETA não aumenta drasticamente como um ETA de transferência de arquivos, mas pode levar de 2 a 3 segundos reais antes que o timer diminua um segundo (ou pode até começar a contar) ) até estabilizar na nova velocidade.

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

Porque a caixa de diálogo de cópia está apenas adivinhando. Não pode prever o futuro, mas é forçado a tentar. E no início da cópia, quando há muito pouco histórico, a previsão pode ser muito ruim.

Em primeiro lugar, esse Windows está supondo. Ele sabe quantos arquivos e qual o tamanho deles, mas a taxa de transferência por arquivo é altamente variável. Depende de coisas como tamanho, ou mesmo localização na unidade em alguns casos. À medida que o tempo passa, ele ajusta suas suposições com base nas condições atuais e passadas e, como tal, você tem velocidades de transferência estimadas imprecisas sob condições do mundo real.

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

Por que o diálogo de cópia fornece estimativas tão horríveis?

Porque a caixa de diálogo de cópia está apenas adivinhando. Não pode prever o futuro, mas é forçado a tentar. E no início da cópia, quando há muito pouco histórico, a previsão pode ser muito ruim.

Aqui está uma analogia: suponha que alguém lhe diga: "Vou contar até 100 e você precisa fornecer estimativas contínuas sobre quando vou terminar". Eles começam: "um, dois, três ...". Você percebe que eles estão indo para cerca de um número por segundo, então estima 100 segundos. Agora eles estão diminuindo a velocidade. "Quatro ... ... ... cinco ... ... ..." Agora você precisa alterar sua estimativa para talvez 200 segundos. Agora eles aceleram: "seis-sete-oito-nove" Você precisa atualizar sua estimativa novamente.

A postagem do blog citada acima tem uma longa discussão sobre esse assunto, com alguns comentários interessantes.

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

A razão óbvia é que a velocidade da transferência varia ao longo do tempo, assim como a média e 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, seu ETA é de aproximadamente dois meses. Quando você desembarcar no aeroporto de chegada, com base na sua velocidade média até o momento, chegará à casa do seu amigo em 5 segundos.

Mas você precisa avaliar o quanto a velocidade pode realmente 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 muitos exemplos na caixa de diálogo de cópia do Windows 8 . Muitos deles são razoavelmente planos, mas muitos também são perturbadores, a ponto de você se perguntar se o disco rígido é realmente saudável quando cai para zero.

Algumas dessas falhas provavelmente ocorrem devido a variações no tamanho do arquivo - campos menores geram mais acessos, o que torna as coisas mais lentas, especialmente em um disco rígido mecânico que deve ser movido pela cabeça de leitura - mas algumas podem ser apenas uma unidade barata que para com o menor toque para evitar danos aos pratos.

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

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

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

Talvez exista um programa que possa copiar / compactar arquivos e emitir um alarme quando terminar. Isso seria realmente útil. Poderíamos tirar uma soneca enquanto esperamos o Windows terminar a limpeza da casa.

Eu acho que o motivo foi bem explicado em um dos comentários do blog vinculado pela resposta de Roald:

Tem um algoritmo de estimativa horrível. Não há desculpas. Se for necessário copiar 1000 arquivos de 1 KB e 10 arquivos de 1 MB, ele acha que estará tão ocupado com o arquivo de 1 MB quanto com os arquivos de 1 KB.

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

Para agilizar o processo de cópia (não gaste muito tempo calculando estimativas de tempo em vez de executar operações relacionadas à cópia), o utilitário de cópia do Windows incorporado ao Explorer mantém uma quantidade limitada de informações sobre a rapidez com que as operações de gravação anteriores foram concluídas. Cada vez que ele precisa calcular o tempo restante, ele apenas calcula o tempo médio que as operações de gravação estão demorando e multiplica pelo número de operações de gravação restantes.

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

Há três fatores a serem levados em consideração:

1. O tamanho total da transferência.
2. O número de arquivos a serem transferidos.
3. A "ocupação" 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 respondem pelo número 2. Isso pode ter um efeito enorme no tempo que a transferência levará e é difícil de 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, tempos de criação / modificação / 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 uma transferência aparentemente simples demorar muito e / ou fazer com que a estimativa de tempo flutue bastante.

por exemplo: ao transferir um arquivo grande, você notará que a estimativa é estável e é bastante precisa, mas a transferência de centenas de arquivos de tamanhos variados, mas o mesmo tamanho total, pode levar mais tempo e fazer com que a estimativa de tempo seja adequada.

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

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

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

Vou tentar explicar mais ou menos o porquê.

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

1. não pode prever com segurança 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 detalhe. A utilização é um conceito muito mais amplo 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 de uso de IO

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

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

• pouco foi feito aqui, onde fazemos a maior parte do trabalho
• é aqui que colocamos os dados do nº 2 para usar
  • análise estatística aproximada dos pesos e locais dos arquivos para determinar quanto salto vamos fazer. A localização do peso + nos fornece uma previsão
  • combinar com os pesos e locais de carga de disco atuais
  • estimar o que achamos que a velocidade média de leitura / gravação do número de arquivos da 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 com o objetivo de prever ... aqui é patenteável

O ponto de tudo isso é o nosso modelo é apenas 2a = F * (bxc) + d complexo

Onde a, bec têm três estados cada: o gerenciador de arquivos espia os arquivos (ou apenas os metadados) antes de copiar e F * (bxc) + 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, seriam diferentes com um SSD - começo / meio / fim não importaria

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

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

Existem muitas variáveis ​​"desconhecidas" quando você está tentando prever quanto tempo algo 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, muitos arquivos de 100 MB e outros intermediários. Além disso, você deve levar em consideração de onde os arquivos vêm e para onde estão indo (por exemplo, mídia). Qual é o maior gargalo? Como você tenta copiar arquivos de um disco rígido através de um túnel VPN ? Você fornece o melhor cenário possível e, em seguida, ajusta seus contadores em tempo real. É por isso que você vê esses medidores de progresso mudarem rapidamente.

O modelo matematicamente correto é realmente 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 fornecerá o resultado mais estável.

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

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

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

1. A melhor maneira, a mais cara, seria manter um histórico das 'cópias' anteriores e, em seguida, usar algoritmos de inteligência artificial para calcular uma estimativa
2. Pode-se construir uma fórmula baseada em pesquisas de quanto tempo deve levar. Eles podem levar em consideração coisas como: sistema de arquivos, número de arquivos, tamanho dos arquivos, tempo de busca do disco, velocidade de leitura / gravação em massa do disco, localização dos arquivos no disco (fragmentação), utilização atual do disco.
3. Uma mistura dos dois. Ou seja. faça alguns benchmarks para descobrir quanto tempo determinadas 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 pergunta que você deve fazer a si mesmo: você prefere que a Microsoft gaste seu tempo oferecendo uma estimativa melhor ou faça com que seus arquivos sejam transferidos mais rapidamente.

No entanto, se você compactar algo com o 7-zip, perceberá que é muito melhor do que o Windows adivinhar. Duvido que esteja fazendo algo tão complicado, apenas um palpite um pouco melhor.

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

Por exemplo: Se a sua taxa de transferência diminuir porque o Windows precisa copiar uma quantidade enorme de arquivos minúsculos, o tempo esperado aumenta linearmente e vice-versa para arquivos grandes.

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

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

É quase impossível estimar o tempo restante para concluir uma cópia com precisão, porque há muitas variáveis ​​imprevisíveis e incontroláveis ​​envolvidas - por exemplo, quanta largura de banda de rede estará disponível para a duração do trabalho de cópia? O seu software antivírus irá girar e iniciar a verificação de arquivos? Outro aplicativo precisará acessar o disco rígido? O usuário iniciará outro trabalho de cópia?

E como eles estão melhorando,

Em vez de investir muito tempo com uma estimativa de baixa confiança que seria apenas ligeiramente melhorada em relação à atual, nos concentramos em apresentar as informações de que estávamos confiantes de uma maneira útil e convincente. Isso torna as informações mais confiáveis ​​disponíveis para você, para que você possa tomar decisões mais informadas.

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

Mantenha uma tabela de velocidades esperadas para cada dispositivo de armazenamento no sistema de arquivos. Registre quanto tempo leva para ler as informações do sistema de arquivos. Quando um dispositivo é montado, se for razoável para o tipo de dispositivo, procure no meio e no final, medindo velocidades também. Obtenha curvas aproximadas para as velocidades de leitura e gravação em todos os locais e use-as para estimativas futuras. Para futuras operações de leitura e gravação, anote onde elas estão e com que rapidez elas vão e ajuste as curvas de acordo.

Quando uma operação começa, observe as curvas de entrada e saída dos respectivos dispositivos. Encontre a velocidade esperada para o local de destino. Qualquer velocidade mais baixa deve ser usada para a estimativa.

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

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

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

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

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

Shows simples de matemática:

130.000 arquivos a 100 arquivos por segundo = 22 minutos

200.000 MB a 70 MB por segundo = 47 minutos

22 minutos - perdidos no 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.

A soma dos 22min + 47min é o tempo máximo absoluto que poderia levar.

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 1 MB / s, há 20 GB a mais de dados, e são necessárias 5:30 horas para concluir.

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

O que o ser humano vê na mesma caixa de diálogo: 120.000 arquivos e 180 GB já são copiados por 40 minutos. O restante de 10000 arquivos e 20 GB deve levar cerca de 5 minutos

A caixa de diálogo fornece informações suficientes para fazer cálculos cada vez mais precisos a cada segundo. Ele sabe a taxa na qual os arquivos pequenos são copiados. Ele sabe a que velocidade os arquivos grandes são copiados. Ele 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 dados um pouco mais corretos apenas no caso de os arquivos grandes estarem antes dos arquivos pequenos. Se for esse o caso, começa aos 40 minutos e, após 30 minutos, 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 seu cálculo como se os arquivos pequenos contassem como infinito, e como se eles fossem para sempre pequenos.