Szanowni Forumowicze,

Wydaje mi się, że jestem średnim (ok - zadowalającym! :]) programistą, ale matematyk (algorytmik) to chyba ze mnie cienki.

Przyszło mi zmierzyć się z banalnym (jak mi się wydaje) problemem, jakim jest obliczenie szacowanego czasu do końca wykonywania danej operacji. Algorytm (równanie matematyczne) na obliczenie tego wydawało mi się być oczywiste. Wystarczy mi wyniki typu: "około tyle sekund pozostało". Resztę bez problemów sobie przeliczę na to, co mnie interesuje.

Wymyśliłem dwa algorytmy (wzory) liczące to:

a) ile sekund pozostalo = (ile sekund uplynelo od poczatku / ile rekordow przetworzono) * ile rekordow pozostalo

Mój sposób rozumowania był następujący: dzieląc czas czas, który upłynął do tego momentu przez ilość rekordów jaką przetworzono do tego momentu otrzymuje się ułamek w przybliżeniu określający ile czasu jest zużywane na przetworzenie jednego rekordu (ile sekund lub części jednej sekundy na to potrzeba. Mnożąc to przez ilość pozostałych rekordów (i zaokrąglając) powinno się uzyskać ilość sekund pozostałą do końca wykonywania operacji. A mnożąc ów ułamek przez liczbę wszystkich rekordów - czas potrzebny na przetworzenie ich wszystkich - jeśli ktoś woli.

b) ile sekund to potrwa = (ile sekund uplynelo od poczatku / (jaki jest procent zaawansowania / 100)

ile sekund pozostalo = ile sekund to potrwa - ile sekund uplynelo od poczatku

Tu mój tok myślenia był następujący: skoro 100 sekund trwało wykonanie 65% całości, to całkowity czas wyniesie 100 / 0,65. Następnie odejmując od całkowitego czasu ten, który już upłynął dostajemy szacowany czas, który pozostał.

Jeśli się nie mylę to oba wzory po pewnych przekształceniach da się sprowadzić do jednego i tego samego.

Niestety, albo coś pomieszałem, albo oba moje podejścia do rozwiązania tego zagadnienia okazały się być błędne. W wyniku otrzymuję jakieś brednie. Obliczany czas jest "kosmicznie długi". Na przykłado kilkanaście (lub nawet kilkadziesiąt!) godzin rzekomego wykonywania procesu, który faktycznie (jak się potem okazuje) trwa ledwie półtorej godziny.

Przy czym - najdłuższy (szacowany z tych wzorów) czas jest na samym początku procesu i potem błyskawicznie spada w dół (nawet po kilka godzin na sekudnę na początku). Spada (stabilizuje się) coraz wolniej, aż wreszcie oba z powyższych wzorów podają "mniej więcej" prawidłowy czas po przetworzeniu ok. 50-60% zadania.

Generalnie im dłużej faktycznie trwa proces tym stabilizacja następuje później i tym większe czasy są obliczane na samym początku. Dla testowych procesów trwających po 2-3 minuty już po kilkunastu sekundach jest podawany prawidłowy czas.

Ale mi niestety taka zgaduj-zgadula jest o dupsko rozbić! :/

Potrzebuję algorytm (wzór), który już od pierwszych sekund (od 1% zaawansowania, a najlepiej od początku) poda mi szacunkowy czasu pozostały do zakończenia (lub szacunkową długość trwania procesu) z błędem maksymalnie kilku minut, a nie kilkunastu lub kilkudziesięciu godzin!

To jest problem banalny i oczywisty. Prawie każdy program robiący coś "nieco dłużej" (RAR pakujący pliki, Total Commander wysyłający pliki przez FTP, Windows kopiujący pliki, kodek kodujący film - przykładów są setki) potrafi bezbłędnie lub z minimalnym błędem podać czas do zakończenia zadania już od pierwszych sekund jego trwania. Takie dziwolągi, jak opisuję pojawiają się tylko u mnie.

Mimo spędzenia nad tym problemem kilku godzin i przeszukania Internetu, nie udało mi się znaleźć ani co robię źle, ani prawidłowego algorytmu / wzoru. Dlatego z góry dziękuję za wszelkie uwagi i sugestie, które mogą naprowadzić mnie na rozwiązanie.

Pozdrowienia,
Trejder

Windows, RAR i inne pierdoły nie podają także dokładnego czasu. Ja zawsze przy kopiowania dużej listy katalogów i dużej liczby małorozmiarowych plików na początku mam kilkadziesiąt godzin, później spada po kilka godzin, stabilizuje sięa i tak margines jest zawsze kilkunastominutowy.

Nie ten dział!

9 dni się spóźniłeś Ale i tak masz rację, nie ten dział ;]