What does this mean?

danball1976danball1976 Wichita Falls, TX
edited June 2003 in Folding@Home
I am using the beta client, and alot of recent WU's have been ending early. This one is a little odd

Sorry, this belongs back in the main Team Short-Media didn't notice I posted it here

Comments

  • CycloniteCyclonite Tampa, Florida Icrontian
    edited June 2003
    It kind of tells you in the message. Drop your overclock back a little bit.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Nah, I don't want to at this time. I think it has to do with the BETA client and SSE, as for what the protien looked like at the beginning, all the stuff was scattered, and kept getting further away, so that protien probably was already bad.

    Actually, what I mainly wanted to know what the "Box Exploding" meant.
  • seversphereseversphere
    edited June 2003
    I'd like to know what box exploding is too :)

    up your vcore and see if you can finish the WUs

    otherwise drop back to 3.24 client and do the one little extra step of -forceasm.
  • mmonninmmonnin Centreville, VA
    edited June 2003
    The only thing different with the beta client is 3dnow! default and not SSE default for Athlons.

    You just dont realize that with SSE your machine is not stable. It maybe be stable for everyday use but not under the stress of gromacs. Take off -forceasm or back down the OC. One or the other. Cause you get no points for those early end units right now. Its a 30% loss using 3dnow! and not SSE so I would suggest you back down the SSE.

    If you get these all the time its not the WUs its YOU!. I havent gotten one of these in awhile and I am OCed. I am stable, you are not.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    OH, ok. I guess I'll turn off -forceasm.
  • fatcatfatcat Mizzou Icrontian
    edited June 2003
    ...or lower your overclock...50 less mhz is not going to slow down your folding production that much...are u using extreme FSB's...that might also do it with only a 1/5 divider on the kd7. but yea like they said..getting 90% through a 17hr WU only to have it EARLY_UNIT_END with no pts is no fun...

    fc
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Nope, just 13.5x166.
  • mmonninmmonnin Centreville, VA
    edited June 2003
    You will lose more by not using -forceasm then lowering the FSB by 1 or 2. Watch your times go up several minutes per frame depending on the WU.

    Have you raised vcore any?

    Have you set the 1/5 divider like FatCat said?

    Maybe change the CAS latency to a lower setting aka higher number.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    By the 1/5 divider, that would be the 166/66/33 right? Yes I am using that.

    My vcore is about .05 to .10 volts above the default.
  • mmonninmmonnin Centreville, VA
    edited June 2003
    Yes thats the right divider.

    You can go higher with the vcore as long as temps are not that high.

    What gets me is why you raised the multi and not your FSB. You have PC3200 ram and its running at PC2700 speeds. You seem to be more worried about your mhz and overal system performance but do not OC right. You raise the FSB and not usually lower the multi.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Because its easier to do than fiddling with the FSB, and its more stable.
  • mmonninmmonnin Centreville, VA
    edited June 2003
    Well with an nForce2 mobo you can easily make that a 400mhz system with an OC of the FSB.

    Then you could lower multi to 11.5, up the FSB to 200 and you have a 2.3ghz system that will perform better than your system plus a few extra mhz to even the mhz to 2.3. The 200FSB machine will rule yours.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    mmonnin said
    Well with an nForce2 mobo you can easily make that a 400mhz system with an OC of the FSB.

    Then you could lower multi to 11.5, up the FSB to 200 and you have a 2.3ghz system that will perform better than your system plus a few extra mhz to even the mhz to 2.3. The 200FSB machine will rule yours.

    Yeah, that's exactly why I want a nForce 2 board or nForce 3 (if going 64 bit) board
  • seversphereseversphere
    edited June 2003
    but he can run 195fsb NOW. Just being a oc wussy :P

    13.5X166 is fine - you probably just need to up your vcore another notch to finish these gromacs.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    seversphere said
    but he can run 195fsb NOW. Just being a oc wussy :P

    13.5X166 is fine - you probably just need to up your vcore another notch to finish these gromacs.

    Yes, your right there.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    I'm not sure what was going on that day, but it isn't terminating WU's early anymore.
  • muddocktormuddocktor
    edited June 2003
    You might have gotten a bad WU; some of the simulations will still turn out bad as this is still cutting-edge stuff and Stanford will still have some WU's that give them strange results that are not expected. Just watch how your machine performs over the next few days and check the fahlog regularly for early work end. If it folds correctly over the next few days, then you were the recipient of a genuine bad WU.
  • WuGgaRoOWuGgaRoO Not in the shower Icrontian
    edited June 2003
    does sse work better for pcs with AMD or with Pentiums?
    I wanna get the most out of my folding rigs...so plz tell me which client i should go with for which system
  • muddocktormuddocktor
    edited June 2003
    SSE definitely performs better than 3DNow!, by around 15-20% faster. However, there have been problems encountered with some Tbred XP's and the client using the SSE instructions; I have 1 such processor that will lock up while using SSE even running at stock speed but will fold it's butt off for weeks on end while overclocked when using 3DNow! extentions. I don't know if the problem is the implemetation of SSE by the client or a fault in some Tbred XP's though.

    The best way to find out if your Tbred is affected by this is to try running the client with SSE enbled by using the -forseasm flag and seeing if you are having lockup or stability problems versus folding with 3DNow! extentions being used.

    The problem is only with AMD procs, the P3 and P4 are unaffected by this and the client will automatically choose SSE extentions with them as Intel procs don't support 3DNow! anyways.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Ok, it seems to do it in runs, I got this one for example
  • muddocktormuddocktor
    edited June 2003
    If you are getting multiple failures fairly close together then you are either overclocked a hair too much for the vcore you are running or you are having a heat issue due to the summer heat or a combination of both. Try bumping the vcore up around .25 volts or backing the fsb down 1-2 MHz and see how it folds. Just remember, folding isn't making your computer fail, it is just showing you that you presently aren't totally stable.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Ok, My Vcore is .1v above default (1.70v over 1.60v) and I am at 166.6667x13.5=2250MHz. DDR voltage is at 2.65v over the default 2.55v. Should I bump it up .05v?

    Oh, BTW, Folding@Home console 3.24 is using SSE with -forceasm enabled. I went and downloaded 3.24 since I was running the beta 3.25 client
  • muddocktormuddocktor
    edited June 2003
    Bump your vcore up to 1.725-1.750v and see if this helps stability. Those voltages won't hurt the proc in the least as long as you have a good hsf. Also, switch back to using the beta console 3.25 if you plan to be using the SSE instruction set instead of 3DNow!; the only difference between the 2 versions is that Stanford added full-time support for enabling SSE with XP procs with 3.25 beta. With 3.24, the only WU that will use SSE while using the -forceasm flag will be the WU you are presently working on when starting the client. All subsequent WU's will use 3DNow! until the client is restarted. That is the reason why Stanford released the beta 3.25 client; to fix this bug with XP procs and enabling SSE instead of 3DNow! by default.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    Oh, ok Didn't know that.

    Oh, and the WU that the 3.24 client that was working on just fine quit with the usual Fatal Error 101 as soon as the 3.25 client started working on it.

    This is getting annoying, it has sent for 3 new WU's since downloading the 3.25 client
  • mmonninmmonnin Centreville, VA
    edited June 2003
    3.25 is not really a beta client. It is as stable as 3.24 and the only reason it is not final yet is because they want to get these early ends down figured out on the AMDs. There are not bugs in it like alpha and beta versions of software.
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    mmonnin said
    3.25 is not really a beta client. It is as stable as 3.24 and the only reason it is not stable yet is because they want to get these early ends down figured out on the AMDs. There are not bugs in it like alpha and beta versions of software.

    How can it be stable and not stable at the same time?
  • mmonninmmonnin Centreville, VA
    edited June 2003
    Opps I meant ...its not final because....
  • danball1976danball1976 Wichita Falls, TX
    edited June 2003
    I went into the BIOS, adjusted voltages.

    CPU Core to 1.725v, and DDR voltage to 2.65v, I found that my RAM voltage wasn't at 2.65v like it was supposed to be, it was at 2.55v, and then also set RAM timings to Turbo. (Was by SPD)

    //EDIT//
    Increasing voltage did the trick so far.

    //EDIT 2//
    Adding voltage did do the trick, no early end WU's
Sign In or Register to comment.