Restliche Dauer bei Kopiervorgängen
-
Hi
Ich habe heute mal wieder mein System gesichert und ich bin immer wieder überrascht welche Zeiten mir bei Kopiervorgängen angezeigt werden. Egal ob OSX, Linux oder Windows, das ist teilweise so grob daneben...
Ich nehme an, dass diese Angaben schlecht präziser bestimmt werden können, denn sonst würden Firmen wie Apple oder Microsoft das sicher umsetzen.
Meine Frage wäre:
Wie wird eigentlich die verbleibende Dauer von Kopiervorgängen bestimmt? Was sind die Ursachen für die teilweise doch heftigen Zeitschwankungen?Grüße
-
cpp_Jungspund schrieb:
Meine Frage wäre:
Wie wird eigentlich die verbleibende Dauer von Kopiervorgängen bestimmt? Was sind die Ursachen für die teilweise doch heftigen Zeitschwankungen?Es ist schrecklich: Es wird tatsächlich vorher das gesamte zu kopierende Material angeguckt und daraus dann eine Abschätzung gemacht. Das ist es, was passiert, wenn Windows vor einem großen Kopiervorgang erst einmal minutenlang "das Kopieren vorbereitet", wohingegen ein Shellkommando ohne Fortschrittsanzeige sofort loslegt.
Bezüglich der Ungenauigkeit: Es ist so ungenau, weil es einfach schwer vorhersehbar ist, und zumindest teilweise einfach schlecht implementiert. Selbst wenn du vorher weißt, wie viele Dateien und wie viele Megabytes zu kopieren sind: Das erste Problem ist, dass du am Anfang nicht weißt, wie lange was davon dauert, das heißt, am Anfang schießt du völlig ins Blaue. Das zweite Problem ist, die Raten sind nicht konstant, also selbst wenn du ein bisschen Daten gesammelt hast, was wie schnell dauert, bedeutet das nicht, dass die nächste Datei mit der gleichen Größe genau so lange dauern wird, das ist einfach technisch bedingt, weil Massenspeicher, Dateisysteme und Netzwerkverbindungen nicht konstant schnell arbeiten. Und dann können auch noch dumme Kopierfunktionen hinzu kommen. Soweit ich weiß, kopiert Windows Dateien immer ganz oder gar nicht. Wenn zum Beispiel eine große Datei über ein Netzwerk nicht 100% korrekt übertragen wurde, dann wird die ganze Datei noch einmal kopiert, anstatt nur ein fehlerhafte Teil. Das ist natürlich Gift für jede Fortschrittsvorhersage. Kann sein, dass das mittlerweile verbessert wurde, war aber zumindest früher so.
-
cpp_Jungspund schrieb:
Ich nehme an, dass diese Angaben schlecht präziser bestimmt werden können, denn sonst würden Firmen wie Apple oder Microsoft das sicher umsetzen.
Haha, guter Witz!
cpp_Jungspund schrieb:
Wie wird eigentlich die verbleibende Dauer von Kopiervorgängen bestimmt? Was sind die Ursachen für die teilweise doch heftigen Zeitschwankungen?
Irgendein banaler Algorithmus, der irgendjemand vor 30 Jahren in der Woche vor der Lieferung mal hingeklatscht hat. Seitdem nie wieder geändert, weil "funktioniert ja". Zumindest sehe ich keinen Grund von etwas anderem auszugehen.
Der I/O-Scheduler im Kernel könnte einigermaßen genau ausrechnen, wie lange das Kopieren bei der aktuellen Gesamtsystemlast dauern wird. Das erfordert aber neue Kernel-APIs und eine Erweiterung des Spaghetti-Code-basierten Schedulers. Da die Schätzungen schon immer schlecht waren, haben sich DAUs daran gewöhnt, also schreit keiner danach, also hat eine Verbesserung niedrige Priorität. Solche Unternehmen arbeiten nur an kritischen Bugs, unnötigen UI-Änderungen und Marketing-Gimmicks ("Windows Subsystem for Linux" zum Beispiel).
-
TyRoXx schrieb:
unnötigen UI-Änderungen
Also ich hab mal was für die Uni programmiert und meine Freundin meinte nur: "Das ist ja gar nicht bunt!". Wen wunderte also?
Außerdem fordern die Richtlinien ja nur die " ungefähre Dauer"
und außerdem hat der Durchschnittsbürger doch eh entweder eine oem-lizenz, studenten-lizenz oder eben gar keine.
-
Ich schätze, ein Teil der Problematik besteht darin, dass solche Schätzungen auf rohen Zahlen basieren, e.g. des Volumens der zu kopierenden Daten, nicht aber auf der strukturellen Komplexität der sie enthaltenden Ordnerhierarchie oder anderen Faktoren wie der Fragmentierung auf Festplattenlaufwerken. Es ist schließlich deutlich effizienter, eine zusammenhängende Datei von einer HDD zu lesen, als tausende Dateien durch seeking auszulesen.
-
TyRoXx schrieb:
Irgendein banaler Algorithmus, der irgendjemand vor 30 Jahren in der Woche vor der Lieferung mal hingeklatscht hat. Seitdem nie wieder geändert, weil "funktioniert ja". Zumindest sehe ich keinen Grund von etwas anderem auszugehen.
Du fällst mir jetzt schon in mehreren Threads mit "Ahnung" auf. Etwas nachdenken vor dem Posten hilft und trägt dem Forenklima positiv bei.
Früher war der Algorithmus jedenfalls sehr schlecht, siehe https://blogs.msdn.microsoft.com/oldnewthing/20040106-00/?p=41193 und vor allem die Kommentare.
Inzwischen (sprich: ich glaube seit Vista, oder aber auch erst seit Win7) hast du eine viel bessere Ansicht, die zeigt dir sogar graphisch an wie viele MB/s kopiert werden und auf welchen Daten daher die Schätzung basiert. Teilweise geht dafür aber auch extra Zeit drauf (siehe Posting SeppJ).
MfG SideWinder
-
SideWinder schrieb:
Du fällst mir jetzt schon in mehreren Threads mit "Ahnung" auf. Etwas nachdenken vor dem Posten hilft und trägt dem Forenklima positiv bei.
Früher war der Algorithmus jedenfalls sehr schlecht, siehe https://blogs.msdn.microsoft.com/oldnewthing/20040106-00/?p=41193 und vor allem die Kommentare.
Was ist jetzt falsch an dem, was ich geschrieben habe?
SideWinder schrieb:
Inzwischen (sprich: ich glaube seit Vista, oder aber auch erst seit Win7) hast du eine viel bessere Ansicht, die zeigt dir sogar graphisch an wie viele MB/s kopiert werden und auf welchen Daten daher die Schätzung basiert.
Windows 7 hat den Graphen noch nicht. Vielleicht sind die Schätzungen ab 8 besser.
-
TyRoXx schrieb:
SideWinder schrieb:
Du fällst mir jetzt schon in mehreren Threads mit "Ahnung" auf. Etwas nachdenken vor dem Posten hilft und trägt dem Forenklima positiv bei.
Früher war der Algorithmus jedenfalls sehr schlecht, siehe https://blogs.msdn.microsoft.com/oldnewthing/20040106-00/?p=41193 und vor allem die Kommentare.
Was ist jetzt falsch an dem, was ich geschrieben habe?
Wilde Spekulation ohne Beleg?
-
Obligatorischer xkcd-Comic:
https://xkcd.com/612/
