Unitinfo.txt

RobOC · 28 Jul 2006 at 23:55

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?

Mattus · 28 Jul 2006 at 23:56

I always thought it was updated at the end of every frame/percent of the WU?

iBot · 29 Jul 2006 at 00:00

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%  [|||||||||_]

RobOC · 29 Jul 2006 at 00:01

Oh ok so if I am on a long WU it could take a while between updates.

A.N.Other · 29 Jul 2006 at 00:03

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

RobOC · 29 Jul 2006 at 00:08

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

RobOC · 29 Jul 2006 at 00:10

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.

shadowscotland · 29 Jul 2006 at 00:12

some of the 4-500pointer can take 90-120minutes on my HT P4 3.0 rigs. and your sig link says some of your threads will take weeks to finish - so yes

RobOC · 29 Jul 2006 at 00:18

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:

Mattus · 29 Jul 2006 at 00:23

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.

RobOC · 29 Jul 2006 at 00:26

Ahhh I like your style. Good idea

I was just getting into doing px aux | greps to see if the process is running etc. I'll give that a go.

RobOC · 29 Jul 2006 at 00:33

That worked a treat. FAHlog is a bit bigger to upload but not by much. Good stuff, it'll do for my purposes.

ta!

rich99million · 29 Jul 2006 at 08:12

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

RobOC · 29 Jul 2006 at 13:11

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.