File I/O Errors with 5.0-PLEASE READ BEFORE UPDATING TO V5 CLIENT!

ketoketo Occupied. Or is it preoccupied? Icrontian
edited August 2004 in Folding@Home
I'm just in the process of changing over my systems to 5.0

I use console on 3 of the systems (including 2nd verson on HT P4) and am getting TONS of I/O errors with the console version. So much so that I have now changed all machines over to the graphical client, which doesn't seem to be having any issues.

Obviously I can't do this on the HT machine. Any word if this is common or any suggestions to resolve it?

Comments

  • muddocktormuddocktor
    edited August 2004
    Aw ****, I forgot about posting on phasing in 5.0. I remember about a month ago when they first put 5.0 up for beta testing that they said to not try upgrading to the new client in the middle of a wu as it might mess it up. This is what Vijay posted on July 7 in the beta forum about the issue:
    The new client uses a new queue.dat format. Some data there can get screwed up. The best way to solve this problem is to install the new client into a new directory, rather than on top of an old install.

    We are working to do a queue.dat conversion, but for now please just use a clean dir.

    I don't know if they've made a queue.dat conversion yet, but if so it might still be making mistakes. When I upgraded the clients on the machines I've upgraded so far, I didn't make a new folder for it, but waited until it was finished with a wu then shut down. I then deleted the queue.dat file and the work folder and the old client and then added the new console client into the folder and made new shortcuts to add my startup flags to and then started the client up again. It then generated a new work folder and queue.dat file and downloaded a fresh wu.

    When you installed the gui client keto, it probably installed it to a new folder called C:\Program Files\Folding@Home, so it didn't try to convert a queue.dat file.

    I would suggest that anyone replacing the old client by upgrading to the new client to finish their present wu and then delete the queue.dat file and work folder after it has successfully sent in the completed wu. Then go ahead and install the v5 client and let it build a new queue.dat file and work folder. :thumbsup:
  • ketoketo Occupied. Or is it preoccupied? Icrontian
    edited August 2004
    OK. That seems to be clear enough. Now, in the F@H thread, there's something about the ID needs to be changed in registry but the example shows only 1 ID in the registry - shouldn't there be 2 on a HT machine? Can only find the 1 reg entry for Pande.

    I always thought I was getting proper 'credit' on the HT machine but I've begun to doubt it and am not sure how to verify it.
  • muddocktormuddocktor
    edited August 2004
    keto wrote:
    OK. That seems to be clear enough. Now, in the F@H thread, there's something about the ID needs to be changed in registry but the example shows only 1 ID in the registry - shouldn't there be 2 on a HT machine? Can only find the 1 reg entry for Pande.

    I always thought I was getting proper 'credit' on the HT machine but I've begun to doubt it and am not sure how to verify it.

    On a HT machine, the pandegroup id will be the same for both clients but you need to assign a different machine id for each different instance you have running. This is done with the -config flag for the console client. If you are running a gui and a console, the gui client will have the machine id "1", so assign the console client machine id "2-8" when setting up with the -config flag. You can have up to 8 different machine id's on 1 boxen with v4 or higher, so theoretically you could cover a quad xeon (like any of us have the megabucks for that kind of rig) with HT by assigning machine id's 1 through 8 to the different instances.
  • EyesOnlyEyesOnly Sweden New
    edited August 2004
    This tread made me really nervous yet so far, 3 or so wus done, i've had no problem whatsoever except getting way to many gromacs but that's not fah faults. That is because of that darn bothered: :D:mean::rant:

    Anyway since i didn't try to find any instructions i just tried to switch by simply stopping the client right in a wu. It had gone through about 370 frames out of 400. After that i uninstalled the firedaemon service, deleted the client, copied a version 5 client into that dir, double clicked it, and hoped for the best.

    Without hardly asking any questions it started, showed a dosscreen and appeard to be working on the previous wu. Since i wanted to doublecheck the settings i created a shortcut for it and clicked it. After making sure every setting including the new ones was done it ones again got to work.

    Since i wasn't sure that it would start at bootup as it said i rebooted after i had started em3 again which didn't show any errors. After reboot fah and em3 started as they should and have as a said in the beginning given me no problems as of yet.

    Sorry for the long post but i had to spell it out. BTW how come i haven't had any problems. Was i just lucky?
  • muddocktormuddocktor
    edited August 2004
    Yeah, I think that you must have gotten lucky, EO. Glad that you didn't have problems on your update. :)
  • edcentricedcentric near Milwaukee, Wisconsin Icrontian
    edited August 2004
    Two of my boxes went fine with an install over the old.
    One of them barfed a big wu though. It seema to be running the next one fine.
    At least I won't worry, if I see anymore errors I'll just wipe the directory and start over.
  • EyesOnlyEyesOnly Sweden New
    edited August 2004
    muddocktor wrote:
    Yeah, I think that you must have gotten lucky, EO. Glad that you didn't have problems on your update. :)

    yeah for me. :D
    :celebrate :cool::thumbsup::rarr: :sweflag:
  • csimoncsimon Acadiana Icrontian
    edited August 2004
    I upgraded 31 instances from v4 to v5 last week. I kept the existing work folder & unit and queue.dat files only and deleted everything else.
    I don't recall exactly but I think everything went smoothly. If any one of them gave me trouble it was the t-bird at dads which was resolved easily by deleting the queue.dat and work folder but I'm not even sure I remember having to do that.
    Anyway ...I would'nt be too concerned about it.
  • EQuitoEQuito SoCal, USA
    edited August 2004
    For me V5 was ending too many units early so I went back to v4 and everything is cool again.
  • muddocktormuddocktor
    edited August 2004
    EQuito wrote:
    For me V5 was ending too many units early so I went back to v4 and everything is cool again.

    Hmm, I guess I'll have to keep an eye out on the rigs I just upgraded today then EQuito, thanks for the warning. BTW, were the wu's that were ending early in the p130x series by any chance(some of the large wu's)? Those do have a higher percentage of early ends and LINCS warnings than the regular gromacs or DGro wu's. Vijay does say that even with the early ends that they are learning lots with this new process though.
  • EQuitoEQuito SoCal, USA
    edited August 2004
    :thumbsup:

    I don't remember which ones were ending early cause I don't keep track of names and such but like I said, since going back to V4 all of them had finished perfectly.

    :cheers:
Sign In or Register to comment.