Grobe Restzeitberechnung für einen Vorgang

    • VB.NET

    Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von kevin89.

      Grobe Restzeitberechnung für einen Vorgang

      Hallo,

      eine Zeitberechnung lässt sich sehr einfach realisieren, hier mal ein Beispiel im Zusammenhang mit einer Progressbar. Es ist simple Mathematik, und es gilt: Je flüssiger und genauer die Progressbar, umso besser die Zeitberechnung.

      Zunächst benötigen wir eine globale Integer-Variable sek mit dem Standardwert 0, die die Gesamtzeit des Vorgangs zählt. Bei jeder Ausführung des Vorgangs muss sek auf 0 gesetzt werden und der Timer gestartet werden. In Timer_Tick (Timerinterval 1000!):

      VB.NET-Quellcode

      1. Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
      2. sek += 1
      3. Dim t As Timespan = Timespan.FromSeconds((ProgressBar1.Maximum - ProgressBar1.Value) * (g_sek / ProgressBar1.Value))
      4. ' hier sind die daten...
      5. End Sub


      Gruß

      Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von „kevin89“ ()

      Hallo Kevin,

      das ist ne ganz nette sache, aber da gibt es 4(oder mehr) Haken:

      -das Interval des timers weist nicht auf 1 sekunde hin, das ist bei jedem PC untershiedlich (ok, auf die paar microsekunden kommts auch net an, aber wenn, dann richtig ;))
      -je nach dem vorgang muss auch eine funktion da sein die den wert an die progressar sendet!
      -wenn diese funktion vorhanden ist, kann es auch manchmal sein, dass der rückgabewert größer als 100 ist, das wäre dann der sichere tod des programms ^^
      -die rückgabewerte einer funktion können immer unterschiedlich sein! d.h. du kannst sie auch nicht teilen, damit alles richtig läuft!

      mfg
      martinustreveri

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „martinustreveri“ ()

      Natürlich läuft ein Timer relativ genau 1 Sekunde... bis zu einer Abweichung von einigen Milisekunden (die allerdings selten vorkommt) wird sich am Ergebnis aber eh nix ändern.
      -je nach dem vorgang muss auch eine funktion da sein die den wert an die progressar sendet!
      Das Beispiel ist ja auch für eine Progressbar.
      -wenn diese funktion vorhanden ist, kann es auch manchmal sein, dass der rückgabewert größer als 100 ist, das wäre dann der sichere tod des programms
      -die rückgabewerte einer funktion können immer unterschiedlich sein! d.h. du kannst sie auch nicht teilen, damit alles richtig läuft!

      Ich glaube du hast da was falsch verstanden...

      Es geht hier um die Restzeitberechnung, zum Beispiel "Noch 05:39" könnte da rauskommen. Ich benutze diese Methode der Restzeitberechnung in meinem Programm "Crypt" im Showroom, lass da mal einen Wikipedia-Artikel verschlüsseln, dann dauert der Vorgang etwas länger und du kannst dir die Zeitberechnung ansehen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „kevin89“ ()

      "Dodo" schrieb:

      Das der Timer nicht genau läuft weiß ich, aber die gezählen skeunden dienen ja nur zur aktuallisierung und wenn die volle Minute nicht 100%ig zeitgleich sondern paar sek versetzt angezeigt wird.


      glaubst du mir jetzt?

      na gut, das anpassen....
      von mir aus, kann man machen...

      finde aber, einfacher geht das mit dem backgroundworker..

      /e: Naja... Das ist mir klar, aber du brauchst ja auch was was die value vn der progressbar angibt... oder wo willst du die infos herbekommen?... jaja, ich weis, das gehört woanders in aber trotzdem..

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „martinustreveri“ ()

      Nein. So ein Timer geht schon sehr genau. Ein minimale Abweichung kann man aber nicht verhindern.

      finde aber, einfacher geht das mit dem backgroundworker.

      Ein Timer wird hier ausnahmsweise mal nicht grundlos eingesetzt.

      Die Info's kommen von der Progressbar... simpelste Mathematik eben. Wenn du eine Zeitberechnung einbaust, dann benutzt du in der Regel auch eine Progressbar. Und wenn nicht: anpassen.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „kevin89“ ()

      lass mal einen timer ne halbe stunde laufen, und du wirst merken, das es immer zu abweichungen kommen wird

      Da hat doci recht, eine Attosekunde kann das schonmal abweichen, aber das würde dann in den 1000'er Nullkommabereich gehen. Das spielt bei der Auswertung letzendlich keine Rolle, schlimm wäre es, wenn der Timer eine Zehntel Sekunde falsch gehen würde aber so ungenau ist er auch nicht. Wenn du einen Vorgang machst, der 500 Tage dauert, wirst du in etwa eine Abweichung von 3 Sekunden merken.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „kevin89“ ()

      ok, ich gebs z, ich lag falsch :S (ich bin relativ jung für nen programmierer...werde heut 12.. also bewertet mich bitte nich über :!: )

      naja..
      aber 2 "restzeitberechner" gleichzeitig kann man das dann sicher auch net laufen lassen, dann müsste man schon jeweils die variablem anders benennen:

      VB.NET-Quellcode

      1. dim sek1 as integer 'restzeit 1
      2. dim sek2 as integer 'restzeit 2
      3. dim sek3 as integer 'restzeit 3
      4. ....


      das ist so richtig, dagegen kannste nix sagen!!! :P

      mfg.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „martinustreveri“ ()


      Dann verstehst du, warum er auch so funktioniert

      Die meisten Sachen verstehe ich sogar, ohne sie auszuprobieren ...

      "Restzeit" ist definiert als GesamtZeit - VerstricheneZeit
      Falls GesamtZeit unbekannt ist, haben wir EINE Gleichung mit ZWEI Unbekannten. Und dann wird's halt schwierig.

      NACHTRAG: Die GesamtZeit wird bei dir offensichtlich in Abhängigkeit von Progressbar.Maximum berechnet. Damit definierst du letztlich die GesamtZeit durch diesen Wert. Damit ist letztlich die Funktion für die Berechnung zuständig, die diesen wert setzt. Genauso wie beim setzen von "Value". Das ganze funzt also nur halbwegs zuverlässig wo du Schleifen mit festen Grenzen verwendest.

      Einfaches Beispiel wo sowas nicht klappen kann:
      Rekursives berechnen der Gesamtgröße eines Ordners inkl. aller Unterordner.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „picoflop“ ()

      WENN man Schleifen mit festen Grenzen ablaufen lässt, ist diese Methode sehr zuverlässig, und relativ genau, da die Werte dann gleichmäßig laufen (in der Regel). Andernfalls ist es entweder nicht besonders genau oder es funktioniert garnicht, da hast du recht.

      In einfachen Worten: Wenn man das Maximum, also den entgültigen Wert nicht kennt, funktioniert das hier nicht (gut). Aber dann lässt sich generell keine oder nur eine ungenaue Zeitberechnung erstellen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „kevin89“ ()