-
Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!
HFM.NET duplicate client warning - bad??
- Thread starter orion456
- Start date
It is really bad. THe Assignment Server sees the machines with the same User and machine IDs as one machine, so frequently the AS will employ the "lost WU" algorithim on them. Machine A gets assigned a new WU then a short time later, machine B with the same UID and MID requests a new WU. THe AS thinks Machine A & B are the same machine and you "lost" the first WU, so it sends you the same WU. Now you've got Machine A and Machine B working on the same WU and only the first returned will receive credit for the return.
It doesn't require a reinstall to fix the issue. If the dupes are in the same machine, give them different MIDs. If they are Linux instances, stop the client and delete machinedependent.dat on one dupe and restart. Windows, I think there is a PandeGroup registry key that can be deleted to force a new User ID.
It doesn't require a reinstall to fix the issue. If the dupes are in the same machine, give them different MIDs. If they are Linux instances, stop the client and delete machinedependent.dat on one dupe and restart. Windows, I think there is a PandeGroup registry key that can be deleted to force a new User ID.
Last edited:
OP
- Joined
- May 31, 2004
- Thread Starter
- #3
Lovely, the WUs are on different machines. I suppose I duplicated them a LONG time ago.
I will look for the registry key fix.
thx.
- Joined
- Sep 22, 2004
Have you been moving WUs around manually *OR* cloning VMs? It matters... at least in the current release of HFM.
There are a couple places that User ID and Machine ID could be being pulled, and if it's available... v0.4.8 pulls that information from the queue.dat file first. Upcoming release will take these values from the log file first and use the queue as a backup source (opposite of how it's done now - and because of situations like this). So, if you've moved a WU from one machine to another, it is probably not a problem and the note about being duplicate should go away when the client who received the transferred unit is assigned a new one (as the next queue entry will then be coded with that client's ID and not the ID of the client that originally received the WU).
If Linux VMs have been cloned and never had their machinedependant.dat file deleted, then I believe that is cause for concern, b/c the VM looks like the same machine to Stanford. The safest thing to do is find the "matching" clients and fix one of them. This is what ChasR is talking about.
There are a couple places that User ID and Machine ID could be being pulled, and if it's available... v0.4.8 pulls that information from the queue.dat file first. Upcoming release will take these values from the log file first and use the queue as a backup source (opposite of how it's done now - and because of situations like this). So, if you've moved a WU from one machine to another, it is probably not a problem and the note about being duplicate should go away when the client who received the transferred unit is assigned a new one (as the next queue entry will then be coded with that client's ID and not the ID of the client that originally received the WU).
If Linux VMs have been cloned and never had their machinedependant.dat file deleted, then I believe that is cause for concern, b/c the VM looks like the same machine to Stanford. The safest thing to do is find the "matching" clients and fix one of them. This is what ChasR is talking about.
OP
- Joined
- May 31, 2004
- Thread Starter
- #5
These are windows machines, most likely duplicated a year ago. All instances of the GPUs on two machines say duplicates as well as one SMP. They are all running different projects according to HFM.
I believe the registry key value to delete is found in \HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PandeGroup\Folding@Home\UserID. I've never had to try this, so I don't guarantee it'll work.
You will not always be assigned the same WU, but it'll happen fairly often and really screw with your ppd.
You will not always be assigned the same WU, but it'll happen fairly often and really screw with your ppd.
OP
- Joined
- May 31, 2004
- Thread Starter
- #8
That key must not be right because there is no Wow6432Node in the registry and the only PandeGroup entires are for the old 5.03 single client. I checked on other windows machines and with the same result; no such entries.
In searching another computer's registry which as only one SMP running, there are no entries that I could find for PandeGroup, or Folding@Home with UserID as a key.
Interestingly there is no entry for "passkey" either.
Last edited:
FAH windows user ID (notes from an old sneaker net post).
Search the registry for a key called userID.
for XP, HKEY_LOCAL_MACHINE\SOFTWARE\PandeGroup\Folding@home\UserID
Typically located in:
XP: HKEY_LOCAL_MACHINE\SOFTWARE\PandeGroup\Folding@home
Vista: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PandeGroup\Folding@home
NOTE: With Windows Vista, the key can also be stored in this location, if you have installed the SMP client. This one takes precidence:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\PandeGroup\Folding@home
Search the registry for a key called userID.
for XP, HKEY_LOCAL_MACHINE\SOFTWARE\PandeGroup\Folding@home\UserID
Typically located in:
XP: HKEY_LOCAL_MACHINE\SOFTWARE\PandeGroup\Folding@home
Vista: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PandeGroup\Folding@home
NOTE: With Windows Vista, the key can also be stored in this location, if you have installed the SMP client. This one takes precidence:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\PandeGroup\Folding@home
OP
- Joined
- May 31, 2004
- Thread Starter
- #10
Mine is WinXP and the only such entry is for an old client 5.03. Does the UserID remain the same even after changing to a new client which is SMP?
The Pandegroup userID key remains in the registry even when the FAH software is uninstalled.
Apparently the CPU and GPU are using the same PandeGroup userID registry key. Just stop the clients, delete the registry entry, delete the duplicate WU (work folder and queue.dat), and a new userID will be created when the client is restarted.
I first ran into "duplicate ID" issue several years ago with the 5xx clients after ghosting a W2K build on a farm rig. Could not figure out how to get rid of the dup ID, so ended up making a fresh build and creating image prior to installing FAH. Later learned about the userID registery key in a sneaker net guide. In Linux, all you have to do is delete the machinedependent.dat file located in the folding directory.
Apparently the CPU and GPU are using the same PandeGroup userID registry key. Just stop the clients, delete the registry entry, delete the duplicate WU (work folder and queue.dat), and a new userID will be created when the client is restarted.
I first ran into "duplicate ID" issue several years ago with the 5xx clients after ghosting a W2K build on a farm rig. Could not figure out how to get rid of the dup ID, so ended up making a fresh build and creating image prior to installing FAH. Later learned about the userID registery key in a sneaker net guide. In Linux, all you have to do is delete the machinedependent.dat file located in the folding directory.
OP
- Joined
- May 31, 2004
- Thread Starter
- #12
This worked for SMP and GPU, but not for two single clients. On restarting the single client resumed with the old key. Even rebooting did not reset the key. I suppose the only alternative is to delete them completely along with the key.
OP
- Joined
- May 31, 2004
- Thread Starter
- #14
On my machine its "UserID".
Yes, the Id is "UserID".
If you are still having the duplicate UserID issue and can't update the client, then you could change the machine ID to be unique on each machine, which would make it look like you were running multiple instances on the same rig, but each should get unique work. I think FAH502 supported 1-16 for machine id. Change the machine ID by running FAH with the -configonly flag and selecting advanced options, or carefully edit the client.cfg file with a text editor. You must restart the client for the change to take effect.
If you are still having the duplicate UserID issue and can't update the client, then you could change the machine ID to be unique on each machine, which would make it look like you were running multiple instances on the same rig, but each should get unique work. I think FAH502 supported 1-16 for machine id. Change the machine ID by running FAH with the -configonly flag and selecting advanced options, or carefully edit the client.cfg file with a text editor. You must restart the client for the change to take effect.
- Joined
- Jan 17, 2010
- Location
- Planet Bananas
Also if deleting the registry key and restarting multiple clients, start one client and wait a few seconds before starting the next client.
I have had instances where the first client has not had a chance to update the registry and the second client then grabs a new key from Stanford which then replaces the first. Not sure if that causes any issues though.
I have had instances where the first client has not had a chance to update the registry and the second client then grabs a new key from Stanford which then replaces the first. Not sure if that causes any issues though.
It happens and isn't a biggie. If you're big on doing the most science, you can delete the duplicate WU on the slowest machine. Points wise there is no ill effect from running duplicates, unless the machines have the same User ID and Machine ID.
