Laxness ????

[PinHead]

I've read some threads where people mention a problem and then say "no laxness" or "some laxness".

What numbers from the filelist.txt file tell the laxness and what are their ranges or meanings?

dfGUI shows three laxness levels, so are there 3 numbers in filelist.txt file that tell the laxness?

[bwkaz]

In filelist.txt, look at the second-to-last line (the one before the MD5 -- or whatever it is -- checksum). Just before all the hyphens and H's, there are three numbers. These are the laxness levels (they're the last 3 numbers on that line).

There is no maximum on them -- the 100% level in dfGUI is just a number that Howard thought the client would rarely exceed.

[PinHead]

Is 58K out of range?

[PinHead]

I guess not????

[bwkaz]

Well like I said, there's no maximum. So no, no number that you could possibly ever see is out of range. ;)

But yes, 58K and 66K are quite high. Looks like that client is getting stuck quite often -- on the bright side though, it should burn right through the next bunch of generations (with a high laxness, the structures can be slightly worse, but they get folded a lot faster because it can't get stuck nearly as easily).

[IronBits]

PinHead
What is program is that you are using??? :)
Looks good!

[PinHead]

Originally posted by IronBits
PinHead
What is program is that you are using??? :)
Looks good!

It's a program that I am trying to write in order to monitor my boxen, but I still need info on the lax settings.

Also need to do something with all those blank tabs.:blush:

[IronBits]

If you would, please email me a copy when it's ready ;) :thumbs:
ironbits AT dBestern.com

[PinHead]

For the curious, here's the "Quick Stats" part.

[IronBits]

:smoking:

[rsbriggs]

But yes, 58K and 66K are quite high. Looks like that client is getting stuck quite often -- on the bright side though, it should burn right through the next bunch of generations (with a high laxness, the structures can be slightly worse, but they get folded a lot faster because it can't get stuck nearly as easily).

I suspect this has something to do with why a box that normally takes 2 minutes per generation sometimes takes over 800 minutes to complete one ????

If you do the math, you'll find that you don't come out ahead on completing the next bunch of generations - you've spent 5 hours more on that single cycle than the entire 250 generations should have taken.

Looking at the energy graphs versus the time graphs from most of my machines, I would be very tempted to say that there is something severely wrong going on.....

[rsbriggs]

Also need to do something with all those blank tabs.
It looks very usable, blank tabs or not. I'd bet there are LOTS of people that would find it useful as is. If you made it generally available, I suspect you would get various suggestions about what people would find useful in those other tabs.... :thumbs:

[bwkaz]

Originally posted by rsbriggs
If you do the math, you'll find that you don't come out ahead on completing the next bunch of generations - you've spent 5 hours more on that single cycle than the entire 250 generations should have taken. I'm not saying you come out ahead, though. :)

I'm just saying that the next bunch (likely until you start over at gen 0, or at least that was the way it worked in the betas) will complete a lot faster.