Weird Unitinfo.txt File

Has anyone else seen this problem before? I have 2 VM folding clients running on my quad computer. The Unitinfo.txt file is 1KB on one of the clients, and it is 168MB on the other client. This seems to create some problems for FAHmon, because it is showing the 168MB client as being 1723161585% complete with an ETA of 2/11/2023.

I tried stopping the Folding client and deleting the Unitinfo.txt file, but this did not appear to help any. When I restarted the folding client, it re-created the Unitinfo.txt file as 168MB again.

Are the Vms different Machine ID's in your config file , as they should be

Try deleting the work folder and Queue dat , unit info.txt then restart

It is a known problem. You don't need to do anything.

Thanks for letting me know. I thought I might have done something wrong. BTW, I do have different machineID's for each of the VM's.

If running two separate VMs, each with one client... Machine ID will not matter.

Each VM is like it's own rig, so even though there are two VMs/Clients on the same physical box, each client is isolated to its own world. One client cannot "see" the other.

You don't need to change anything, however. Running each client with a different Machine ID will work just fine in this scenario as well.

Well, the good news is that when your WU is complete, it will be more complete than anybody ever dreamed possible!

Bad new is, that won't happen until 2023!!

Crazy stuff!

Actually harlem, i'd be careful about the MachineIDs on seperate VMs. When i did mine up first, i installed f@h, then cloned the vms, and started them up, they both got the same WU. exact same PRCG, had to change the ID on one of them to get a different WU. I think the fact that they were cloned, meaning aside from the machineID, they will look like identical machines, and the server will think the same computer/client has requested a WU without uploading the one it sent, therefore sending the same WU again.

And ya, i've seen the unitinfo.txt error a few times, nothing to worry about, it will finish and upload like all the rest.

Cluster said:

Actually harlem, i'd be careful about the MachineIDs on seperate VMs. When i did mine up first, i installed f@h, then cloned the vms, and started them up, they both got the same WU. exact same PRCG, had to change the ID on one of them to get a different WU. I think the fact that they were cloned, meaning aside from the machineID, they will look like identical machines, and the server will think the same computer/client has requested a WU without uploading the one it sent, therefore sending the same WU again.

Click to expand...

Ahh, this is true and a known no-no when it comes to cloning VMs. When cloning, do not setup the FAH client in the original VM that will be cloned. When each client fires up the first time it gets a unique ID (client ID for lack of a better term). If the client is setup and the VM is cloned, I don't believe changing the Machine ID will pay any dividends to aleviate the duplicated client ID which results in receiving duplicate work. If it does, that's a new one on me.

If one does setup the client and then clone, the easiest thing to do is just remove the entire FAH (or whatever you call it) folder on the cloned VM, recreate the folder, and finally download and configure the client again on the cloned VM (which is what one would have done anyway if they hadn't installed the client before cloning). This will ensure that each VM's client receives a different client ID. To my knowledge, the Machine ID is only used locally on each machine and is not sent to Stanford's servers when connecting to the assignment server.

Does your guide address any this? If not, we could use ChasR's input here too... I'm sure he's dealt with this 10x over.

Just as an update, the WU finished in a normal time frame without any problems at all. Sometimes FAHmon shows the correct percentage complete and sometimes it does not, but at least the WU's are finishing without any problems.

I just need to get my new heatsink, so I can overclock my Q9300.