xkcd

So che la finestra di dialogo Copia di Windows (in Windows XP) memorizza prima la copia in memoria e continua a copiare dopo la chiusura della finestra di dialogo, quindi il tempo è spento, ma perché è la stima del tempo necessario per fare una copia così impreciso, anche quando la copia della memoria è stata disabilitata (in Vista e Windows 7)? Sembra così arbitrario! Come funziona l'intera procedura di copia e perché Windows non può stimarla correttamente?

In breve: gli algoritmi scadenti e la stima jumpy sono in realtà una debolezza dell'implementazione.

Altri strumenti come TeraCopy fanno un lavoro migliore. Penso che non valga la pena spiegare perché la loro attuazione non è buona. Lo avranno notato e miglioreranno.

Cosa è difficile:

1. Devi prendere in considerazione le fluttuazioni delle risorse (principalmente CPU / larghezza di banda della rete / velocità dell'HDD)
2. È necessario estrapolare il tempo necessario predicendo il comportamento (ciò che la copia del file di Windows fa definitivamente male in questo momento).
3. Apporta le modifiche nel tempo alla tua stima originale (intendo piccole modifiche non come nella divertente foto sopra!)

Per questo non solo la quantità di byte ma la quantità di file da creare svolgono un ruolo. Se hai un milione di file da 1KB o migliaia di file da 1MB la situazione sarà abbastanza diversa perché la prima ha il sovraccarico di creare molti file. A seconda del file system utilizzato, ciò potrebbe richiedere più tempo rispetto al trasferimento effettivo dei dati.

Questo dialogo mi ha fatto impazzire anche un paio di volte:

• Su un vecchio sistema WinNT, se avevi molti file di piccole dimensioni da copiare, mostrava il nome e l'animazione piacevole per ogni file che rallentava l'intero processo praticamente inutilizzabile.

Le moderne funzionalità di copia di Windows non sono molto migliori:

• Per calcolare la quantità di dati da trasferire sembra prima effettuare una ricerca (questo è quello che suppongo lo faccia), quindi ci vogliono anni se si selezionano molte directory prima che inizi effettivamente a fare il lavoro.
• Alcuni timeout integrati impediscono la copia di file di grandi dimensioni (> circa 60 GB sul mio sistema). Il dolore è che ti dice che dopo aver copiato già più di 30 GB sulla rete e questo viene perso con la banda e il tempo perché devi ricominciare da zero!
• La copia dei file da un computer all'altro è dannatamente lenta per qualche motivo. (Voglio dire rispetto alla larghezza di banda di rete disponibile, usando altri strumenti è più veloce quindi non è una limitazione computazionale.)

Raymond Chen ha scritto un articolo molto carino al riguardo una volta. Fondamentalmente, la finestra di dialogo è solo un'ipotesi :).

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

"Perché la finestra di dialogo della copia è solo un'ipotesi. Non può prevedere il futuro, ma è costretta a provare. E all'inizio della copia, quando c'è pochissima storia da percorrere, la previsione può essere davvero pessima.

Ecco un'analogia: supponiamo che qualcuno ti dica: "Ho intenzione di contare fino a 100 e devi dare stime continue su quando avrò finito". Iniziano "uno, due, tre ...". Notate che stanno andando a circa un numero al secondo, quindi stimate 100 secondi. Uh-oh, ora stanno rallentando. "Quattro ... ... ... cinque ... ... ..." Ora devi cambiare il tuo preventivo in forse 200 secondi. Ora accelerano: "sei-sette-otto-nove" Devi aggiornare di nuovo il tuo preventivo.

Ora qualcuno che sta ascoltando solo le tue stime e non la persona che conta pensa che tu sia fuori dai giochi. La tua stima è passata da 100 secondi a 200 secondi a 50 secondi; qual è il tuo problema? Perché non puoi dare un buon preventivo?

La copia dei file è la stessa cosa. La shell sa quanti file e quanti byte verranno copiati, ma non sa quanto sarà veloce il disco rigido o la rete o Internet, quindi deve solo indovinare. Se la velocità effettiva di copia cambia, è necessario modificare la stima per tenere conto della nuova velocità di trasferimento. "

Conterò fino a dieci, 1....2....3....4quanti punti ci vorranno per arrivare a 10?

5.6.7E adesso? Prendi in considerazione tutti i punti passati tra i numeri e fai una media, prendi solo gli ultimi 4 intervalli e usi quella media, guardi solo l'ultimo intervallo?

Hai lo stesso problema con i trasferimenti di file. La velocità che il file trasferisce non è costante, accelera e rallenta in base a molti fattori. La ragione per cui il numero salta così tanto è che Microsoft si è orientata verso il lato "conta solo l'ultimo intervallo" dello spettro.

Non c'è niente di sbagliato in quel lato dello spettro, ti dà "secondi al secondo" più accurati (un secondo in tempo reale fa scendere il contatore di un secondo) ma questo fa saltare l'ETA totale del timer molto .

Un buon esempio del lato opposto è 7-Zip durante la compressione. Se la velocità della compressione diminuisce mentre si elabora, puoi vedere che l'ETA non salta in modo drammatico come un trasferimento di file ETA, ma potrebbero essere necessari da 2 a 3 secondi reali prima che il timer scenda di un secondo (o potrebbe addirittura iniziare a contare ) fino a quando non si stabilizza alla nuova velocità.

In realtà c'è una risposta quasi canonica da parte del Raymond Chen di Microsoft a proposito di WAAAAAY, e ci sono alcuni pezzi del puzzle.

Perché la finestra di dialogo copia è solo un'ipotesi. Non può prevedere il futuro, ma è costretto a provare. E all'inizio della copia, quando c'è pochissima storia da percorrere, la previsione può essere davvero pessima.

Innanzitutto, Windows sta indovinando. Sa quanti file e quanto sono grandi, ma la velocità di trasferimento per file è molto variabile. Dipende da cose come la dimensione, o anche la posizione sull'unità in alcuni casi. Col passare del tempo, si sta adeguando la sua ipotesi in base alle condizioni attuali e passate, e come tale si hanno velocità di trasferimento stimate imprecise in condizioni reali.

Ecco la spiegazione di Raymond Chen , Principal Software Design Engineer presso Microsoft:

Perché la finestra di dialogo della copia fornisce stime così orribili?

Perché la finestra di dialogo copia è solo un'ipotesi. Non può prevedere il futuro, ma è costretto a provare. E all'inizio della copia, quando c'è pochissima storia da percorrere, la previsione può essere davvero pessima.

Ecco un'analogia: supponiamo che qualcuno ti dica: "Ho intenzione di contare fino a 100 e devi dare stime continue su quando avrò finito". Iniziano "uno, due, tre ...". Notate che stanno andando a circa un numero al secondo, quindi stimate 100 secondi. Uh-oh, ora stanno rallentando. "Quattro ... ... ... cinque ... ... ..." Ora devi cambiare il tuo preventivo in forse 200 secondi. Ora accelerano: "sei-sette-otto-nove" Devi aggiornare di nuovo il tuo preventivo.

Il post sul blog citato sopra ha una lunga discussione di questo problema, con alcuni commenti interessanti.

Raymond Chen è una persona leggendaria, "Microsoft Chuck Norris", non credo che otterrai una risposta più autorevole. Sono sicuro che almeno avesse visto il codice in questione.

La ragione ovvia è che la velocità del trasferimento varia nel tempo, così come la media e anche la previsione. Per spiegarlo a un amico non tecnico, ho usato un'analogia che riguarda il viaggio in aereo. Sorvolerai l'Atlantico. Quando arrivi con un taxi all'aeroporto di partenza, il tuo ETA è di circa due mesi. Quando scendi all'aeroporto in arrivo, in base alla tua velocità media finora, raggiungerai la casa del tuo amico in 5 secondi.

Ma devi apprezzare quanto la velocità può effettivamente variare, anche con quello che sembra uno scenario prevedibile, come la copia di file all'interno dello stesso disco o tra due dischi locali. Una delle nuove funzionalità che mi piace in Windows 8 è la possibilità di rappresentare graficamente la velocità nel tempo se fai clic su "maggiori dettagli". Se non si ha accesso a un computer Windows 8, cercare immagini nella finestra di dialogo Copia Windows 8 per molti esempi. Molti di loro sono abbastanza piatti, ma molti sono anche inquietanti e sconnessi, al punto che ti chiedi se il disco rigido sia effettivamente sano, quando scende a zero.

Alcuni di questi dossi sono probabilmente dovuti a variazioni nella dimensione del file - campi più piccoli producono più accessi, che rallentano le cose, specialmente su un disco rigido meccanico che deve cercare spostando la testina di lettura - ma alcuni potrebbero essere solo un disco economico che si blocca al minimo tocco per evitare danni ai piatti.

Esistono algoritmi di previsione ETA migliori e peggiori, ma per una previsione accurata, il computer dovrebbe essere onnisciente. Il rischio di provare a rendere "intelligente" l'algoritmo potrebbe creare casi nuovi, imprevisti, in cui è ancora più esilarantemente sbagliato.

L'unico modo per sapere quanto tempo ci vorrà per comprimere un set di file è comprimerli. A volte la migliore ipotesi di Windows è vicina, a volte è selvaggiamente sbagliata. Lo stesso vale per la copia di un gran numero di file, come sono sicuro che hai notato.

Non è tanto un bug quanto una visualizzazione inutile di informazioni raramente accurate. Il modo migliore per risolverlo è chiudere gli occhi. Ignoralo. ;-)

Forse c'è un programma là fuori che può copiare / comprimere i file e far suonare un allarme al termine. Sarebbe davvero utile. Potremmo fare un pisolino mentre aspettiamo che Windows finisca la pulizia della casa.

Penso che il motivo sia stato ben spiegato in uno dei commenti del post sul blog collegati dalla risposta di Roald:

Ha un orribile algoritmo di stima. Non ci sono scuse. Se deve copiare 1000 file da 1 KB e 10 file da 1 MB, pensa che sarà occupato con il file da 1 MB come con i file da 1 KB.

Il motivo per cui fornisce stime così orribili è che non è ben fatto. Ovviamente non può mai essere preciso al 100% ma potrebbe essere molto, molto meglio.

Al fine di accelerare il processo di copia (non impiegare troppo tempo a calcolare le stime dei tempi anziché eseguire operazioni relative alla copia), l'utilità di copia di Windows integrata in Explorer mantiene una quantità limitata di informazioni sulla velocità di completamento delle precedenti operazioni di scrittura. Ogni volta che deve calcolare il tempo rimanente, capisce solo il tempo medio impiegato dalle operazioni di scrittura e quindi si moltiplica per il numero di operazioni di scrittura rimanenti.

Il problema è che la quantità di tempo necessaria per eseguire un'operazione di scrittura non è costante: può effettivamente variare in modo significativo. Quindi, questo, a sua volta, produce cambiamenti significativi nella stima del tempo.

Ci sono 3 fattori da prendere in considerazione:

1. La dimensione totale del trasferimento.
2. Il numero di file da trasferire.
3. La "frenesia" dei media, e forse la connessione.

I numeri 1 e 3 sembrano avere l'effetto più ovvio sul calcolo del tempo di trasferimento, ma molte persone non tengono conto del numero 2. Questo può avere un enorme effetto sulla durata del trasferimento ed è difficile da quantificare.

Fondamentalmente, ogni volta che un file viene scritto, il filesystem deve scrivere un po 'di metadati sul file, ad es. proprietà, permessi, tempi di creazione / modifica / accesso, ecc. A seconda del particolare filesystem, queste informazioni possono essere scritte su una parte del disco molto "molto lontana" da dove vengono scritti i file. Questo sovraccarico del filesystem è ciò che può richiedere molto tempo per un trasferimento apparentemente semplice e / o far fluttuare selvaggiamente la stima del tempo.

Ad esempio: trasferendo un file di grandi dimensioni noterai che la stima è stabile ed è abbastanza accurata, ma il trasferimento di centinaia di file di dimensioni variabili, ma della stessa dimensione totale, può richiedere più tempo e causare un adattamento del tempo stimato.

Vi sono tre carenze negli attuali algoritmi di stima.

Contrariamente alla credenza popolare, non sono abbastanza difficili da sollevare le mani.

La ragione per cui la maggior parte delle persone che scrivono i blog e le persone qui non sono consapevoli della possibilità è la migliore che posso dire a causa del campo di studio e dell'ampiezza della scuola. Un rimedio modesto ma anche molto comodo dovrebbe essere possibile per [un laureato con una formazione più recente rispetto agli scrittori di blog] [un'azienda multimiliardaria] Microsoft.

Cercherò di spiegare approssimativamente il perché.

I punti di errore sono i seguenti. Il kernel:

1. non è possibile prevedere in modo affidabile il futuro carico di I / O a causa di circostanze al di fuori dell'ambito del kernel

• nulla dovrebbe essere fatto al riguardo poiché si tratta di un problema P = NP molto illimitato.

2. non tiene traccia dell'euristica IO in nessun livello di dettaglio utile. L'utilizzo è un concetto molto più ampio della velocità di lettura / scrittura su disco / rete .

• a questo proposito occorre fare ben poco, poco più che tenere traccia delle informazioni di base sull'utilizzo dell'IO

  • dal disco
    • la dimensione media della velocità di lettura 1a
    • la velocità media di scrittura della dimensione dei file 2a
  • su base per quanti * secondo
    • dimensione del file b
    • la posizione del file sulla dimensione del disco c
  • * quantizzato in [probabilmente] non più di 3 categorie. La riduzione della dimensionalità ci aiuterebbe a determinare con certezza ma 3 dovrebbe essere sufficiente per (probabilmente piuttosto efficace) meccanismi di previsione migliori del nulla:
    • dimensione del file
      • leggero
      • medio
      • pesante
    • posizione [informa della latenza di ricerca]
      • inizio
      • mezzo
      • ottieni il punto
    • dimensione e posizione del file sono ridondanti / si sovrappongono alla velocità di lettura / scrittura, questo è intenzionale
  • dobbiamo sapere quanto è stato "occupato" il disco in modo da poter supporre che continuerà ad essere quella dimensione occupata d
    • calcolato dalla quantità di file letti, contorto con i rispettivi pesi
    • utilizzato per stimare il tempo all'inizio della copia ... finestra di dialogo basata sul carico previsto futuro se tutto il resto a parte questa finestra di dialogo di copia continua come è ora
  • il metodo di registrazione a scopo di ... qui è brevettabile

3. se fossero rintracciati , non avrebbero avuto uso per l'euristica

• poco è stato fatto qui, dove facciamo gran parte del lavoro
• qui è dove utilizziamo i dati dal n. 2
  • analisi statistiche approssimative dei pesi e delle posizioni dei file per determinare la quantità di salti che faremo. Il peso + posizione ci dà una previsione
  • combinare con pesi e posizioni attuali di caricamento del disco
  • valutare ciò che pensiamo media velocità di lettura / scrittura del numero di file dimensione f sarà
  • che confrontiamo per mettere a punto il nostro modello
  • che ci consentirà di stimare in modo abbastanza accurato la barra di avanzamento e il tempo necessario per il completamento
• il metodo di analisi ai fini della previsione ... qui è brevettabile

Il punto di tutto questo è che il nostro modello è solo 2a = F * (bxc) + d complesso

Dove a, b e c hanno 3 stati ciascuno: il file manager dà un'occhiata ai file (o solo ai metadati) prima di copiarli, e F * (bxc) + d non è un calcolo costoso; se vuoi qualcosa di più preciso usa una tabella di ricerca con più stati: non c'è quasi nessun calcolo.

nota: le dimensioni qui sono per un piatto, sarebbero diverse con un SSD - inizio / medio / fine non contano

La differenza chiave tra ciò che ho descritto e le precedenti implementazioni che abbiamo visto finora sarebbe, in breve, osservare la dimensione del file e la distrubtion / entropia del file sul disco e usarlo per [più] spiegare con precisione l'elemento temporale dell'utilizzo del disco.

(il brevetto viene lasciato come esercizio per il lettore ...)

Ci sono molte variabili "sconosciute" quando stai cercando di prevedere quanto tempo impiegherà qualcosa. Ad esempio, mentre il programma sa che ci sono 3500 file e che i file ammontano a 3,5 GB (3500 MB), ciò significa che ogni file è 1 MB? Non necessariamente. Potrebbero esserci molti file da 4 KB, molti file da 100 MB e alcuni altri in mezzo. Inoltre, devi prendere in considerazione da dove provengono i file e dove stanno andando (ad es. Media). Qual è il maggiore collo di bottiglia? Come si fa ad account tentando di copiare file da un HDD attraverso un tunnel VPN ? Dai uno scenario migliore e poi aggiusti i tuoi contatori in tempo reale. Questo è il motivo per cui vedi quei misuratori di progresso cambiare al volo.

Il modello matematicamente corretto è effettivamente fare una media e un'estrapolazione ingenue:

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

Il motivo è che, secondo la legge dei grandi numeri, le fluttuazioni locali si annulleranno nella velocità di trasferimento media e questo ti darà il risultato più stabile.

Ciò che Microsoft sembra fare è calcolare la velocità di trasferimento nell'ultimo intervallo di tempo. Ciò significa che ogni fluttuazione locale modifica significativamente il risultato.

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

Come ha detto Roald van Doorn, in pratica è solo un'ipotesi. Naturalmente, ciò non significa che non potrebbe essere un indovino migliore. Esistono molte euristiche che potrebbero essere utilizzate per calcolare questo.

1. Il modo migliore, il modo più costoso, sarebbe quello di mantenere una cronologia delle precedenti "copie" e quindi utilizzare algoritmi di intelligenza artificiale per calcolare un'ipotesi
2. Si potrebbe costruire una formula basata sulla ricerca del tempo necessario. Potrebbero prendere in considerazione cose come: file system, numero di file, dimensione dei file, tempo di ricerca del disco, velocità di lettura / scrittura della massa del disco, posizione dei file sul disco (frammentazione), utilizzo attuale del disco.
3. Un mix dei due. Vale a dire. fare alcuni benchmark per scoprire quanto tempo impiegano determinate operazioni e quindi usarli come cronologia per semplici formule.

Ovviamente nulla di tutto ciò è facilmente implementabile .. e ho citato solo le copie dei file. Un lavoro simile dovrebbe essere svolto per tutti i tipi di trasferimenti.
La domanda che ti devi porre: preferiresti che Microsoft trascorresse il tempo a darti una stima migliore o preferiresti che i tuoi file fossero trasferiti più velocemente.

Tuttavia, se comprimi qualcosa con 7-zip, noterai che è molto meglio indovinare di Windows. Dubito che stia facendo qualcosa di così complicato, solo un'ipotesi leggermente migliore.

In breve, il calcolo si basa sulla velocità di trasferimento corrente .

Ad esempio: se la velocità di trasferimento diminuisce perché Windows deve copiare enormi quantità di piccoli file, il tempo previsto aumenta linearmente e viceversa per file di grandi dimensioni.

È quasi impossibile prevedere quale sarà la velocità di trasferimento durante l'intero processo di trasferimento, perché dipende da molti fattori come dimensione del file, utilizzo della CPU, errori di trasmissione ecc.

Ci sono alcune risposte interessanti nel post del blog MSDN. Migliorare le basi della nostra gestione dei file: copia, sposta, rinomina ed elimina al riguardo. Quanto al perché è difficile:

Stimare il tempo rimanente per completare una copia è quasi impossibile da fare con precisione perché sono coinvolte molte variabili imprevedibili e incontrollabili, ad esempio quanta larghezza di banda di rete sarà disponibile per la durata del lavoro di copia? Il tuo software antivirus si avvia e avvia la scansione dei file? Un'altra applicazione dovrà accedere al disco rigido? L'utente avvierà un altro processo di copia?

E come stanno migliorando,

Invece di investire molto tempo a elaborare una stima di scarsa fiducia che sarebbe leggermente migliorata rispetto a quella attuale, ci siamo concentrati sulla presentazione delle informazioni di cui eravamo fiduciosi in modo utile e convincente. Questo rende le informazioni più affidabili che abbiamo a disposizione per consentirti di prendere decisioni più informate.

Detto questo, se vuoi davvero migliorare solo la stima data e mantenere la barra di avanzamento così com'è, potresti fare qualcosa suggerito in un commento di Slashdot :

Mantenere una tabella delle velocità previste per ciascun dispositivo di archiviazione sul filesystem. Registra quanto tempo impiega a leggere le informazioni sul filesystem. Quando un dispositivo è montato, se è ragionevole per il tipo di dispositivo, cerca in mezzo e alla fine, misurando anche le velocità lì. Ottieni curve approssimative per la velocità di lettura e scrittura tra le posizioni e usale per stime future. Per future operazioni di lettura e scrittura, prendere nota della loro posizione e della loro velocità e regolare le curve di conseguenza.

All'avvio di un'operazione, osserva le curve di input e output per i rispettivi dispositivi. Trova la velocità prevista per la posizione target. Qualunque sia la velocità più bassa dovrebbe essere utilizzata per la stima.

Volevo solo aggiungere che il numero totale di file è facilmente il fattore che richiede più tempo delle operazioni di copia dei file su un PC. Ricordo sempre come un giovane studente, indurre deliberatamente il fallimento dei PC nella mia classe di informatica iniziando con 1 file senza contenuto e copiandolo, quindi selezionando i 2 file e copiando di nuovo e così via. Una volta passati circa 1024 file, ha iniziato a impiegare enormi quantità di tempo per fare qualsiasi cosa anche quando non stava copiando alcuna informazione salvata per l'intestazione del file. Provalo anche su un nuovo sistema operativo, copia file esponenziale e vedrai cosa succede. Cibo per la mente.

Ho appena copiato 200 GB dall'HDD USB sull'unità principale. C'erano circa 130000 file

Dopo i primi 4-5 minuti ho osservato che:

• Per i file più piccoli, la velocità era di circa 100 file al secondo a circa 600 KB / s
• E per file di grandi dimensioni era come 70 MB / s

All'inizio le finestre hanno cambiato la stima da circa 1 ora a 5+ ore, quindi di nuovo a 1 ora e così via. Alla fine, come nel 95%, stava ancora cambiando la stima da 10 minuti a 10+ ore. Quindi, invece di diventare più accurato, stava diventando sempre meno preciso.

Spettacoli matematici semplici:

130.000 file a 100 file al secondo = 22 minuti

200.000 MB a 70 MB al secondo = 47 minuti

22 minuti - sciolti nel tempo di ricerca copiando file di pochi kilobyte di dimensioni. 47 minuti - il tempo necessario per trasferire i dati effettivi se non c'è tempo di ricerca.

La somma dei 22min + 47min è il tempo massimo assoluto che potrebbe richiedere.

Quindi, ovviamente, la stima dovrebbe essere compresa tra 47 e 69 minuti.

Ciò che mostra la finestra di dialogo al 90% circa: "Sto copiando alcuni piccoli file a 1 MB / s, ci sono 20 GB di dati in più, ci vorranno 5:30 ore per il completamento.

Pochi secondi dopo: "Sto copiando un grosso file qui, a 70mb / s ci vorranno 4 minuti per completarlo.

Ciò che l'uomo vede effettivamente dalla stessa finestra di dialogo: 120.000 file e 180 GB sono già copiati per 40 minuti. Gli altri 10000 file e 20 GB dovrebbero durare circa 5 minuti

La finestra di dialogo fornisce informazioni sufficienti per eseguire calcoli che diventano sempre più accurati ogni secondo. Conosce la velocità con cui vengono copiati i file di piccole dimensioni. Sa a quale velocità vengono copiati i file di grandi dimensioni. Sa anche quanti file e quanti byte sono rimasti.

È così semplice fare un'ipotesi così accurata solo impostando il limite superiore e inferiore.

La finestra di dialogo mostra dati un po 'più corretti solo nel caso in cui i file di grandi dimensioni si trovino prima dei file di piccole dimensioni. In questo caso inizia a 40 minuti e dopo 30 minuti inizia a copiare piccoli file e dice "bene, ho bisogno di altri 20 minuti".

Ma quando i file piccoli all'inizio e i file grandi sono alla fine. La finestra di dialogo in realtà non importa a quali "file al secondo" trasferisce i file di piccole dimensioni. Fa il suo calcolo come se il numero di file piccoli fosse infinito, e come se fossero per sempre piccoli.