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?
Angehängte Dateien:
-
Unbenannt.png
31 KB
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 ;-)
Rufus Τ. Firefly schrieb: > http://xkcd.com/612/ Der war gut: unten "Der Windows-Autor besucht seine Freunde" Glück, daß meine Navis nicht mit Windows-Zeit rechnen.
> 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...
Angehängte Dateien:
-
win8-file-copy2.png
11 KB -
kde_copy.png
19 KB
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...)
Die Werte können sich je nach System, Programmierer und Historie der Realität mal in erratischen Sprüngen, mal von unten und mal von oben nähern.
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.