Unitinfo.txt

Associate
Joined
11 Nov 2004
Posts
522
Anyone know if there is a standard time for how often unitinfo.txt is updated, or whether it is down to individual cores? Seems pretty random. Anyone know of a way to make it update more often?
 
Permabanned
Joined
12 Sep 2005
Posts
3,303
Location
England
Mattus said:
I always thought it was updated at the end of every frame/percent of the WU?

Me too.

Code:
Current Work Unit
-----------------
Name: p1478_tet_1478
Download time: July 26 07:04:34
Due time: September 16 07:04:34
Progress: 98%  [|||||||||_]
 
Soldato
Joined
6 Nov 2005
Posts
8,066
Location
MK45
Mattus said:
I always thought it was updated at the end of every frame/percent of the WU?
For the cores that deal in percentages, it is every percent. With the cores that deal in frames, it is however many frames make up a percent before an update is made.

^ Not very clear :(
 
Associate
OP
Joined
11 Nov 2004
Posts
522
It might seem a random question. The reason i ask is because on my stats page (link at the bottom) I am putting all the threads I am running, and I detect if they are down by the create time on the unitinfo.txt. But I keep getting them displaying as 'down' because I am using an hour as the stale data time before setting them as down. Apparently some unitinfo.txt updates take longer than an hour. I'll have to think of a better way to detect the process status. Means actually doing something proper though :p
 
Associate
OP
Joined
11 Nov 2004
Posts
522
At present one of the unitinfo.txt's hasn't updated since 22:45 and it is 00:09... so some cores must take quite some time per %/frame.
 
Associate
OP
Joined
11 Nov 2004
Posts
522
Hmm those 600pt units should only take a max of a couple of days on those rigs. The reasoning behind that page is that one of those machines was remotely restarted a couple of days ago and the processes didn't start up again properly and I didn't notice. A good couple of days lost crunching. That might be why it looks like they'll take ages to finish, they've been down for a while :rolleyes:
 
Soldato
Joined
30 Sep 2003
Posts
10,916
Location
London
You could possibly use the modified time on the FAHLog.txt instead? Even if the frame is taking a long time, that file will update at least every 30 minutes when FAH writes checkpoint files, if FAH is running.
 
Associate
OP
Joined
11 Nov 2004
Posts
522
Ahhh I like your style. Good idea :D

I was just getting into doing px aux | greps to see if the process is running etc. I'll give that a go.
 
Associate
OP
Joined
11 Nov 2004
Posts
522
That worked a treat. FAHlog is a bit bigger to upload but not by much. Good stuff, it'll do for my purposes. :) ta!
 
Soldato
Joined
26 Dec 2002
Posts
9,348
Location
Derbyshire
RobOC said:
That worked a treat. FAHlog is a bit bigger to upload but not by much. Good stuff, it'll do for my purposes. :) ta!
FAHlog will continue to grow as long until the client is restarted - when the client is restarted it checks the size of the log file and if it's over 50K it will save the information in FAHlog-prev and start fresh

Currently one of my X2's clients has a 150KB log file and the other has a 110KB logfile - that's after about a week of uptime

hope this helps :)
 
Associate
OP
Joined
11 Nov 2004
Posts
522
Hey, yeah that's useful thanks. Might add some kind of service bouncing to the scripts which SCP the files in, to maintain the log file sizes.
 
Back
Top Bottom