Link to home
Start Free TrialLog in
Avatar of Member_2_2394978
Member_2_2394978Flag for United Kingdom of Great Britain and Northern Ireland

asked on

Predict programme finish time

Hi *,

I have some programs which run for a long time; sometimes they run for days/weeks. I can calculate how far through a programme is in percent. What I would like to do is predict (roughly, assuming the programme speed is linear) when a programme should finish.

I have thought that this should be possible by recording the date and time when the programme starts, and then using the current percentage to predict forwards. What I would like is to be able to display a string, containing an estimated time left; perhaps like this:
w0 d13 h17 m22

One thing is that, I currently (due to computer setup) I have another programme displaying the current progress of a programme. Therefore, I have a programme (which I want to monitor and predict finish time for) saving the current progress to a file. This file is then read by the other programme and displays the progress to the user. Therefore, the start time would need to be saved to this same text file and read by the other programme.

Any suggestions? Thoughts?

Cheers,
James
ASKER CERTIFIED SOLUTION
Avatar of Infinity08
Infinity08
Flag of Belgium image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Member_2_2394978

ASKER

Thanks for your response.

This is true, I had completely forgotton that one can get the seconds since the epoch in Unix.

Very simply question!

Thanks,
James
Btw, be careful for division by 0 ;)
In fact, I say it was simple, but I am having a nightmare implementing it!

I am getting all stuck up in variables types.

I have the attached.

I'm looking at the lines with lots of 'X's. I think I currently have problems with casting between floats and ints, as end up with -2010200302 or something similar for predTime.

Also, how could I convert from int (assuming it is calcaulted properly, i.e., predTime) back to time_t which ctime() needs so I can output the time as a nice string.

Sorry, I close the question too early. Nevermind, if it is too late.

Cheers,
James
// Get the current progress
float progress=0.23;

// Get the start time in seconds
char *progressC[100];
int  progressD=0;
FILE *f1;
f1 = fopen("progress.dat", "rt");
fgets(progressC, 100, f1);
progressD = atoi(progressC);
fclose(f1);

// Get the current time in seconds
time_t tim=time(NULL);

// Predict end time in seconds
int predTime = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
char *predTimeC[100] = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
printf("%s\n", predTimeC);

Open in new window

>> Sorry, I close the question too early. Nevermind, if it is too late.

It's certainly not too late. As long as it has to do with the original question (which is definitely the case here), I'm always ready to provide additional support.


>> char *progressC[100];

You probably want :

        char progressC[100] = "";

(similarly for predTimeC further in the code)


>> progressD = atoi(progressC);

Representating the time in seconds since the epoch, can be a large value that might not fit in a (signed) int.
It's probably best to use a time_t, and to store it in binary form in the file.


predTime could then be calculated something like this (assuming that time_t is an integer value that represents the number of seconds since the epoch on your specific platform - which is the case for the large majority of platforms these days) :

        time_t predTime = progressD + ((tim - progressD) / progress);

(I would pick more meaningful/consistent variable names though - see my first post eg.)

Note that this will NOT work on platforms where time_t is NOT an integer value that represents the number of seconds since the epoch on your specific platform. But as said : that is quite unlikely.
Oh, and you can format a time_t as a string using strftime :

        http://www.cplusplus.com/reference/clibrary/ctime/strftime/

(see the code example at the bottom of that reference page)
Wonderful, that's got my silly questions answered.

Many thanks,
James