Darn Unitinfo.txt file acting up again

[Edward2]

The unitinfo.txt file on both of my not-fred USB clients is acting up again, which means that I am unable to monitor their status via HFM. The filesize of both unitinfo.txt files is 168MB.

I've tried stopping the folding client, deleting the unitinfo.txt file, and then restarting the client. I've tried rebooting the client. But each time the file is recreated, it is 168MB.

Oh well. I just had to vent a little bit. :screwy: :bang head

[Adak]

That is just weird! Is this a known bug with NotFred's?

[harlam357]

I've noticed this on one of my notfred's VMs as well Edward. I'm going to put a check in for the size of that file, and if it's way bigger than expected I'm going to halt pulling it across the network.

Only a few things are actually pulled from that file... and if everything isn't garbled in the regular log file all the information can be pulled from the regular log. However, I still look at the UnitInfo.txt because sometimes the Project (R/C/G) string gets chopped off in the regular log, and I can determine this instead by looking at the UnitInfo.txt and parsing its Tag information.

I haven't added this check yet... but it's easy to do. I've also already made a check for FAHLog.txt file size and I'm only pulling it across the wire when it has changed vs. the currently cached FAHLog.txt file for that client instance. If anyone has their retrieval loop setup to a really low number, like 5 minutes, this will increase the speed of the retrieval sequence because it cuts down on I/O... especially on SMP clients. GPU clients write to the log ~1 per minute or less on most WUs.

I was working on the 'Offset' feature last night based on Jolly-Swagman's report to me. I really almost have to wait till midnight to test these things... otherwise I have to fudge with all the clock (time) settings on my boxes to simulate... anyway, just makes for some longer than necessary evenings. ;) Jolly's problem was manifested by the code I'm using to deal with frame times when midnight hits.

Lastly... I got your last e-mail Edward. I haven't had a chance to take a look at everything, but a mobile page is definitely doable.

[Jolly-Swagman]

The unitinfo.txt file on both of my not-fred USB clients is acting up again, which means that I am unable to monitor their status via HFM. The filesize of both unitinfo.txt files is 168MB.

I've tried stopping the folding client, deleting the unitinfo.txt file, and then restarting the client. I've tried rebooting the client. But each time the file is recreated, it is 168MB.

Oh well. I just had to vent a little bit. :screwy: :bang head


This is a known bug in the unitinfo.txt file maily spotted in Notfreds,, both Diskless and VM,s have on the odd occasion seen this in other SMP clients too, and Stanford folding@home site has a few post about it too, it usually clears its self,

Sometimes you wil see a client with 56788339% thats caused by the unitinfo.txt bug.

[Edward2]

I've noticed this on one of my notfred's VMs as well Edward. I'm going to put a check in for the size of that file, and if it's way bigger than expected I'm going to halt pulling it across the network.

Lastly... I got your last e-mail Edward. I haven't had a chance to take a look at everything, but a mobile page is definitely doable.

FYI.... HFM is showing that both of my not-freds VMs are offline (gray), so it isn't trying to pull the file across the network AFAIK. If I double-click the VM, it does take me to the VM directory, and I can open the FAHlog.txt file to verify that it is still running.

No rush on the webpage stuff. Just wanted to send you some ideas I had while I was thinking about them.

[harlam357]

Sometimes you wil see a client with 56788339% thats caused by the unitinfo.txt bug.

I've fixed this in HFM as well... I noticed on a few occasions that I was getting a rather large value for 'Progress' at the beginning of a WU, found it to be coming from the UnitInfo.txt file. I've set this data field to accept only 0 - 100. If I get a value not in that range, it gets defaulted back to 0.

FYI.... HFM is showing that both of my not-freds VMs are offline (gray), so it isn't trying to pull the file across the network AFAIK. If I double-click the VM, it does take me to the VM directory, and I can open the FAHlog.txt file to verify that it is still running.

No rush on the webpage stuff. Just wanted to send you some ideas I had while I was thinking about them.

Ok, do you see something in the log file/messages to this effect?

[5/4/2009-3:30:00 PM] - HFM.Instances.ClientInstance.RetrievePathInstance (<client name>) The path <path>\FAHLog.txt is inaccessible.

Could also be UnitInfo.txt... if either of them fail retrieval then the client is deemed offline as you're seeing.

[Edward2]

I got the following message when I first started HFM:

[5/4/2009-8:20:59 AM] - HFM.Instances.ClientInstance.RetrievePathInstance (W_Quad-1) The path \\IP-address\c\etc\folding\1\FAHLog.txt is inaccessible.
[5/4/2009-8:20:59 AM] - HFM.Instances.ClientInstance.RetrievePathInstance (W_Quad-2) The path \\IP-address\c\etc\folding\2\FAHLog.txt is inaccessible.

I got the following message when I tried "refreshing" the client:

[5/4/2009-6:15:23 PM] - HFM.Instances.ClientInstance.RetrievePathInstance (W_Quad-1) Execution Time: 105,766 ms
[5/4/2009-6:15:25 PM] - HFM.Instances.LogParser.ParseUnitInfo threw exception Exception of type 'System.OutOfMemoryException' was thrown..
[5/4/2009-6:15:25 PM] - HFM.Instances.LogParser.ParseUnitInfo Execution Time: 1,406 ms
[5/4/2009-6:20:57 PM] - HFM.Instances.ClientInstance.RetrievePathInstance (W_Quad-2) Execution Time: 439,000 ms
[5/4/2009-6:20:59 PM] - HFM.Instances.LogParser.ParseUnitInfo threw exception Exception of type 'System.OutOfMemoryException' was thrown..
[5/4/2009-6:20:59 PM] - HFM.Instances.LogParser.ParseUnitInfo Execution Time: 1,922 ms

[harlam357]

Yeah... that would be the problem... The darn UnitInfo is so damn big that reading it in takes a crap load of memory. I was try to debug the other night and kept wondering why my VM (I develop inside a Virtual PC VM) kept paging... then I started looking at the memory usage and it just shot up and ate everything in sight when I hit this trashed 160MB UnitInfo.txt file. Until that point I wasn't aware the file was that large.

Anyway, in this situation I will halt pulling that 'too large' UnitInfo.txt file across the wire and attempt to parse the information solely from the FAHLog.txt file, at least until the UnitInfo.txt returns to normal proportions.

[Zerix01]

Strange. I have three unitinfo.txt files at 160 bytes. I imagine this is how they are suppose to be as there are only a few characters in that file. Could it be a bad core making them grow so big?

[Edward2]

One of my VM/not-freds clients completed its WU, and the unitinfo.txt file is back to normal size (1KB). I can now monitor this client. The other client still has about 20% left.

I don't know what causes the unitinfo.txt file to grow so large, but I have seen it before.

[harlam357]

Put the fix in HFM... too tired, made too many other changes too... Build 11 comes tomorrow. ;)