im Anhang habe ich mal ein Bild.
darauf ist zu sehen dass Dateien mit einer Gesamtgröße von (noch) 3,38GB
auf einen USB-Stick kopiert werden.
Die kopiergeschwindigkeit ist 10,0MB/Sekunde.
Offensichtlich passt aber die geschätzte Zeit nicht, für diese 3,38GB
wurden knapp 12 Minuten benötigt.
Berechnen würde ich das aber so:
3,38GB * 1024 = 3461,12MB
3461,12MB / 10,0 MB/Sekunde = 346,112 Sekunden = 5,8 Minuten
Die angezeigte Zeit hat bei mir noch nie gepasst, können die bei MS
einfach nicht rechnen oder ist der Grund nicht ganz so trivial?
wieso stimmt diese Rechnung nicht? wie berechnet windows das?
Die Geschwindigkeit ist meistens nur eine gewisse
Durschschnittsgeschwindigkeit. Die Zeit wird aber, laut Beobachtung, von
der aktuellen tatsächlichen Geschwindigkeit (oder einem Durchschnitt der
letzten paar Sekunden) hochgerechnet. Die variiert aber in weiten
Grenzen. Zb je nachdem wie stark das System sonst noch ausgelastet ist.
Lasse ich das System in Ruhe kopieren, dann stimmen die prognostizierten
Zeiten meistens ganz gut. Starte ich mehrere Kopierjobs gleichzeitig,
dann stimmt keine einzige Prognose mehr. Auch wenn man neben dem
Kopieren noch was anderes tut, sieht man nach kurzer Zeit, wie die
prognostizierte Zeit in die Höhe schiesst (teilweise absurd hoch).
Auf einem Multitasking-System ist es nun mal nicht so einfach, Zeiten
vorherzuberechnen. Man weiß ja nie, ob die aktuelle Systemlast in den
nächsten 2 Minuten auch noch vorhanden sein wird, ob sie zunimmt oder
sogar abnimmt. Startest du ein Programm, welches viel Speicher belegt,
kann das dazu führen, dass anderer Speicher freigeräumt werden muss,
Pages müssen auf die Festplatte ausgelagert werden, was dann wiederrum
mit der Performance deines Kopierjobs interagiert.
Von mit aus könnte man diese Zeitprognose ruhig auch weglassen. Jeder
der schon mal in einer Command Line mit XCOPY kopiert hat, wird
beobachtet haben, dass der XCOPY schon wieder fast fertig ist, noch ehe
Windows überhaupt erst mal ermittelt hat, wie groß die zu kopierende
Datenmenge überhaupt ist. Größere Datenmengen löschen ist dasselbe: Die
meiste Zeit verbraucht anscheinend die Animation der 'fliegenden Files'
chris schrieb:> können die bei MS einfach nicht rechnen
Das ist der Grund.
Und das ist auch ein "running gag" in praktisch jeder Windows-Version,
früher hat dieser Dateikopier-Dialog auch gerne völlig bizarre Werte
angezeigt.
http://xkcd.com/612/
chris schrieb:> wie berechnet windows das?
sobald du windows installierst entsteht irgendwo im prozessor ein
kleiner käfig ind dem zwei trolle sitzen und durch würfeln mit
hühnchenknochen die kopierzeit vorhersagen ;-)
> früher hat dieser Dateikopier-Dialog auch gerne völlig bizarre> Werte angezeigt.
so manche Prozentangaben in den Setup Programmen, waren auch nicht so
ganz ... vertrauenswürdig :-)
chris schrieb:> Die angezeigte Zeit hat bei mir noch nie gepasst, können die bei MS> einfach nicht rechnen
Die Berechnung wird wahrscheinlich intern mit dem Windows-Taschenrechner
oder mit Excel ausgeführt. Die konnten beide noch nie richtig rechnen
;-)
Karl Heinz Buchegger schrieb:> Die Geschwindigkeit ist meistens nur eine gewisse> Durschschnittsgeschwindigkeit. Die Zeit wird aber, laut Beobachtung, von> der aktuellen tatsächlichen Geschwindigkeit (oder einem Durchschnitt der> letzten paar Sekunden) hochgerechnet.
Erfahrenere Programmierer achten in solchen Fällen wenigstens darauf,
dass gleichzeitig angezeigte fehlerbehaftete Schätzwerte wenigstens
untereinander konsistent sind. Ein Schätzfehler fällt i.Allg. nicht so
sehr auf und wird von den Anwendern meist auch als solcher akzeptiert.
Widersprüche in den Ergebnissen sind aber (oft zurecht) ein Grund für
Gemecker.
Wie war das noch bei früheren Windows-Installationen (95; 98; ME) mit
der "Berechnung" der verbleibenden Zeit?
Anscheinend hat man eine bestimmte Systemkonfiguration als Standard
definiert und dann dort gemessen, wie lange es noch dauert wenn Datei X
kopiert wurde, dann wenn Datei Y kopiert wurde usw.
Bei einem schnellen System waren angezeigte 30 Minuten nach 10 Minuten
vorbei und bei einem langsamen Rechner zogen sich 30 Minuten recht lange
hin :-)
Scheiboperationen besitzen oft mehrere völlig unterschiedliche Phasen.
Werden beispielsweise erst einmal Directories angelegt und kleine Files
kopiert, dann können diese Operationen ziemlich lange dauern. Da Windows
bei solchen Medien aufgrund der Neigung der Anwender, Sticks gern mal
mittendrin rauszuziehen, praktisch kein Caching durchführt, dauern
Metaoperationen auf USB-Sticks schaurig lange.
Kommt anschliessend ein grosses Image-File, dann wird zunächst aus der
miserablen Bytes/Sekunde-Perforance des Kleinkrams auf dieses File
geschlossen und der resultierende Wert liegt zumindest anfangs grässlich
hoch. Das kann sich dann im Laufe der Zeit ändern.
Bei dieser Einschätzung entsteht ein Zielkonflikt, der sich sehr schön
an der xkbd-Karikatur zeigt: Peilt man über eine kurze Zeit, dann können
die Werte extrem schwanken. Peilt man über eine länge Zeit, dann steht
so ein Mist drin wie oben. Wie man es macht, immer ist es falsch.
Rufus Τ. Firefly schrieb:> Und das ist auch ein "running gag" in praktisch jeder Windows-Version
Hatten wir da nicht letztens einen Thread, wo jemand den
Fortschrittsbalken unter LINUX bemeckerte, weil der ebenso falsch geht?
Und LINUX ist doch das OS, wo die Programmierer sich alle ganz viel Mühe
geben und immer alles richtig machen...
Rufus Τ. Firefly schrieb:> Und das ist auch ein "running gag" in praktisch jeder Windows-Version,> früher hat dieser Dateikopier-Dialog auch gerne völlig bizarre Werte> angezeigt.
Bei Windows 8 haben sie dazugelernt!
Jetzt kann man am Graphen sehen, warum der Wert so schwankt...
(Bildquelle :
http://andrewblock.net/2012/09/22/the-windows-8-file-copy-dialog-is-awesome/
)
(Und ja, Linux (KDE) hat das auch schon lange...)
Hallo,
die Kopiergeschwindigkeit ist auch real ganz unterschiedlich, z.B. für
eine grosse Filmdatei oder 10000 kleine Dateien.
Heute macht sich auch kaum noch jemand die Mühe, eine Berechnung auch
nur zu versuchen, meistens fängt der Fortschrittsbalken einfach von
links wieder an, wenn der Vorgang noch nicht fertig ist. Bei manchen
Installationsprogrammen werden locker 20 mal 100% erreicht.
Gruss Reinhard
@ Icke ®. (49636b65)
>Rufus Τ. Firefly schrieb:>> Und das ist auch ein "running gag" in praktisch jeder Windows-Version>Hatten wir da nicht letztens einen Thread, wo jemand den>Fortschrittsbalken unter LINUX bemeckerte, weil der ebenso falsch geht?>Und LINUX ist doch das OS, wo die Programmierer sich alle ganz viel Mühe>geben und immer alles richtig machen...
Genau - an diesen Thread hatte ich auch beim Lesen der Frage gedacht.
Letztendlich kann sowieso kein OS vorhersehen, wann der Job wirklich zu
Ende sein wird. Linux nicht, und Win nicht.
Win95 war da an dieser Stelle noch ziemlich nachlässig. Kopierte man ein
Bündel Files in einem Rutsch, dann konnte es schon passieren, daß Win95
Millionen von Minuten anzeigte, weil es scheinbar Zeit/File gemessen
hatte, nicht Zeit/Byte. Und da ein File aus unterschiedlich vielen Bytes
bestehen konnte, kamm etwas utopisches heraus.
Also, wenn ich 1000 fast nur kleine Files kopieren wollte, und das erste
File, welches gerade als erstes dran kam, war ausnahmsweise ein sehr
großes, dann glaubte Win95, daß auch der Rest der Files sehr groß war.
Also muß es entsprechend lange dauern, was es in seiner
Fortschrittsanzeige auch verkündete.
Neuere Winxx dagegen ermitteln erstmal, wieviel Bytes das im Ganzen
sind.
Damit wird die angezeigte Restlaufzeit nicht mehr abhängig von der
Anzahl Dateien, sondern von der Gesamtmenge an Bytes. Deswegen der
Effekt, der von Karl Heinz Buchegger im letzten Abschnitt erwähnt wird,
weswegen irgendein Kopiervorgang mit einem Tool, welches eine
Fortschrittsanzeige anzeigen will, erstmal nix sinnvolles zu machen
scheint.
Dann kommt der FS (Filesystem) Cache dazu. Der bewirkt, daß der
Kopiervorgang anfangs rasent schnell geht, und dann am Ende bei 99%
(oder so ;-) stecken bleibt, und irgendwann plötzlich fertig ist. Da
unterscheiden sich Win und Linux praktisch gar nicht. Ist also ein
allgemeines Übel, denn man kocht ja überall nur mit Wasser ...
@ Εrnst B✶ (ernst)
>Rufus Τ. Firefly schrieb:>> Und das ist auch ein "running gag" in praktisch jeder Windows-Version,>> früher hat dieser Dateikopier-Dialog auch gerne völlig bizarre Werte>> angezeigt.>Bei Windows 8 haben sie dazugelernt!>Jetzt kann man am Graphen sehen, warum der Wert so schwankt...
Ich sehe nicht, "warum" der Wert so schwankt. Ich sehe nur, daß er so
schwankt ... ist also eher unnütz ...
Jens G. schrieb:> Neuere Winxx dagegen ermitteln erstmal, wieviel> Bytes das im Ganzen sind.
Was tierisch nervt, wenn man viele Dateien kopiert und erst mal 10
Minuten auf der Platte rumgerödelt wird bevor das Kopieren gestartet
wird. Von daher ist der Ansatz AnzahlRestDateien *
Zeit/bisherkopierteDatei = geschätzte Zeit möglicherweise zu belächeln
und oft ungenau, ich persönlich hätte auch nix dagegen eine Option
"kopieren ohne Fortschrittsanzeige" zu haben. Was dazuführt, das ich
dann oft doch ein cp / xcopy nutze...
Beim kopieren auf USB Stick gehen die ersten 99% auch superschnell
(landet alles im RAM Cache) und das letzte % dauert dann 'ewig'...
Jens G. schrieb:> Letztendlich kann sowieso kein OS vorhersehen, wann der Job> wirklich zu Ende sein wird. Linux nicht, und Win nicht.
Naja jeder der es nicht machen muss weiß zumindest sicher das bei ihm
das immer stimmen würde und 'die anderen' nur nicht rechnen können ;-)
Läubi .. schrieb:> ich persönlich hätte auch nix dagegen eine Option> "kopieren ohne Fortschrittsanzeige" zu haben.
DAs war in frühen Computerzeiten so! Dann erkannte der User gar nicht ob
der PC hängt oder arbeitet. Folglich haben die Leute, die Kiste einfach
ausgeschaltet und mehr Probleme durch unfertige Dateiübertragungen
gehabt!
Friedhofsgärtner schrieb:> Folglich haben die Leute, die Kiste einfach> ausgeschaltet und mehr Probleme durch unfertige Dateiübertragungen> gehabt!
Dafür gab es StatusLEDs an den Disketten-Laufwerken und entsprechend
laute Laufwerke. ;)
Unmögliches wird sofort erledigt - Wunder dauern etwas länger!
Ein bisschen sind wir daran schuld. Wir markieren lustig drauf los und
sagen: Mach mal.
Geht das Fenster danach einfach zu, so sind wir unzufrieden.
Also muss ein Fortschrittsbalken her.
Ein einfaches Beispiel:
Um irgendwas anzeigen zu können, muss das System erst mal gucken was
denn angesagt ist. Bei *.*, womöglich mit Unterverzeichnissen, steht
weder fest wie viele Dateien, noch wie viele Bytes kopiert werden
sollen.
>Was tierisch nervt, wenn man viele Dateien kopiert und erst mal 10>Minuten auf der Platte rumgerödelt wird bevor das Kopieren gestartet>wird.
Am Ende kommt dabei heraus:
Soundso viele Bytes und
Soundso viele Dateien.
Und was sagt das aus?
Eigentlich Garnichts.
amateur schrieb:> Am Ende kommt dabei heraus:> Soundso viele Bytes und> Soundso viele Dateien.> Und was sagt das aus?
Du kannst hinterher nachsehen ob am Ziel der Platz reicht oder ob die
Menge der kopierten Daten plausibel erscheint.
Friedhofsgärtner schrieb:> DAs war in frühen Computerzeiten so! Dann erkannte der User> gar nicht ob der PC hängt oder arbeitet.
Wie oft "hängt" den der PC bei dir wenn du Dateien kopierst, ein
einfaches x Bytes kopiert zeigt im Notfall auch an das "was passiert".
oszi40 schrieb:> ob am Ziel der Platz reicht
Das ist auch der einzige Vorteil der Aktion.
amateur schrieb:> Geht das Fenster danach einfach zu, so sind wir unzufrieden.> Also muss ein Fortschrittsbalken her.
warum unbedingt ein fortschritt-balken? in irgendweiner ((ur)alten)
windows-version gab es doch so eine nette animation, in der dateien von
einem ordner in den anderen kopiert/verschoben wurden - so sieht der
user, dass etwas passiert ohne dass man herumorakeln muss wie lange das
noch dauert.
linux hat einen fortschritt-balken beim kopieren? da ich eigentlich
immer in der konsole kopiere ist mir das noch nie aufgefallen... ;-)
Läubi .. schrieb:>> ob am Ziel der Platz reicht> Das ist auch der einzige Vorteil der Aktion.
Das kommt auf das Betriebssystem an was passiert. Es gab schon
Betriebssysteme, die haben gar nicht erst ANgefangen zu kopieren wenn
der Platz am Ziel nicht reichte.
Seit CPM/M$ kopiert man dagengen fleißig BIS am Ziel der Platz
verbraucht ist. Da lohnt es sich schon rechtzeitig zu wissen, ob der
Platz überhaupt ausreicht oder man wartet Stunden um es dann erst zu
merken.
oszi40 schrieb:> die haben gar nicht erst ANgefangen zu kopieren wenn> der Platz am Ziel nicht reichte
Naja in Gnome wird man halt gefragt ob man es trotzdem wagen möchte ;-)
Daniel F. schrieb:> linux hat einen fortschritt-balken beim kopieren? da ich> eigentlich immer in der Konsole kopiere ist mir das noch nie> aufgefallen... ;-)
Es gibt auch Tools welche das auf der Konsole anzeigen... trotzdem gibt
es auch bei Linux schon länger Grafische Oberflächen ich schrieb ja auch
das ich oft alternativ die Konsole nutze. Wenn man die Dateien/Ordner
aber selektieren möchte um nicht alles zu kopieren ist das nur lästig.
Danke für Eure Antworten, da habe ich ja was los getreten :o)
Offensichtlich liegt das also daran, dass die zu kopierenden Daten nicht
direkt von HDD auf USB kopiert werden sondern sie nehmen den Umweg über
den RAM.
...Kann man das nicht irgendwie abstellen!? Ein OS müsste heute doch so
schlau sein und die Daten direkt kopieren können sofern es erkennt dass
es sich bei der Senke um ein Wechseldatenträger handelt"?
Wenn das passen würde, kann man die Zeitanzeige weg lassen und und
einfach angeben welche Dateien bereits geschrieben worden sind (1000 von
2000Bytes geschrieben).
Ich werde mich gleich hinsetzen und Bill Gates diesen äusserst
erachtenswerten Vorschlag mailen....
chris schrieb:> Wenn das passen würde, kann man die Zeitanzeige weg lassen und und> einfach angeben welche Dateien bereits geschrieben worden sind (1000 von> 2000Bytes geschrieben).
Das wäre auch zeitlich ungenau weil 1000 kleine Dateien mehr
Kopfbewegungen verursachen (Zeit brauchen) als eine Giga-Datei, die nur
einen Eintrag im Directroy braucht.
chris schrieb:> ...Kann man das nicht irgendwie abstellen!? Ein OS müsste heute doch so> schlau sein und die Daten direkt kopieren können sofern es erkennt dass> es sich bei der Senke um ein Wechseldatenträger handelt"?
Schon mal was von einem Dateisystem gehört? Dazu braucht man schon etwas
mehr als den Binärinhalt der Datei.
Ausserdem ist das programmökonomischer Unsinn. Wenn du 10 Sorten
Datenträger hast, brauchst du 10 Treiber Gerät -> RAM und 10 Treiber RAM
-> Gerät. Willst du am RAM vorbei kopieren, selbst wenn das sinnvoll
möglich wäre, bräuchtest du 180 Treiber, und bei der Entwicklung eines
neuen Datenträgers müsstest du 20 Treiber entwickeln statt 2.
Aber Bill freut sich sicher über eine amüsante Ablenkung vom Alltag.
Gruss Reinhard
@chris
>Offensichtlich liegt das also daran, dass die zu kopierenden Daten nicht>direkt von HDD auf USB kopiert werden sondern sie nehmen den Umweg über>den RAM.>...Kann man das nicht irgendwie abstellen!? Ein OS müsste heute doch so>schlau sein und die Daten direkt kopieren können sofern es erkennt dass>es sich bei der Senke um ein Wechseldatenträger handelt"?
Macht es doch weitgehend bei Wechseldatenträgern per default. Du kannst
ja eine sogenannte Entfernungsrichtlinie festlegen. Für schnelles
entfernen (kein FS-Cache), oder für bessere Leistung (mit FS-Cache).
Oder eine Schreibcacherichtlinie, was ebenfalls den FS-Cache betrifft.
Kannste einstellen beim entsprechenden Gerät in der Systemsteuerung.
>Wenn das passen würde, kann man die Zeitanzeige weg lassen und und>einfach angeben welche Dateien bereits geschrieben worden sind (1000 von>2000Bytes geschrieben).
Bei unterschiedlichen Dateigrößen läßt das aber auch keine genauere
Abschätzung für die Restdauer zu.
>Ich werde mich gleich hinsetzen und Bill Gates diesen äusserst>erachtenswerten Vorschlag mailen....
Bill Gates ist doch schon lange arbeitslos - der wird nicht mehr
antworten.
rosch schrieb:> Wie war das noch bei früheren Windows-Installationen (95; 98; ME) mit> der "Berechnung" der verbleibenden Zeit?> Anscheinend hat man eine bestimmte Systemkonfiguration als Standard> definiert und dann dort gemessen, wie lange es noch dauert wenn Datei X> kopiert wurde, dann wenn Datei Y kopiert wurde usw.> Bei einem schnellen System waren angezeigte 30 Minuten nach 10 Minuten> vorbei und bei einem langsamen Rechner zogen sich 30 Minuten recht lange> hin :-)
Das war auch noch bei späteren Versionen der Fall; z. B. zeigte das
Windows-XP-Setup (Man beachte: Windowsversion mit integriertem Service
Pack 2!) zu Anfang IMMER eine Restdauer von 39 Minuten an :)
Je nach System dauerte dann beim Dateienkopieren eine Windows-Minute
eben nur 20 Sekunden - oder zwei Minuten.
Und irgendwo im Hinterkopf klingelt gerade was, dass es bei Vista noch
irgendeinen ähnlichen Gag gab. Ist aber schon ein paar Monde her,
seitdem ich zuletzt ein Windows installierte...
Unbenannt.png
(31 KB)
