Client gets stuck - can this really be correct behavior???

[rsbriggs]

I'm not convinced that some of the client behaviors are correct - it often gets "stuck" for LONG periods - for longer than I believe it should.

For example, on a machine that normally does a generation in a couple of minutes ( 2 to 3 ), and on which the "energy" has wandered down from 14 to about 9, there are times when it gets stuck for HOURS:



Sorry, but somehow this behavior just doesn't seem correct. Come on now - stuck on one generation for 5 hours and then for over 10 hours ????

[Tawcan]

What kind of energy did you get for that generation and generation after? Usually when that happens to me I get a very low energy either at that specific generation or the next few generations. Furthermore, the next few generations take very little time.

[rsbriggs]

The energy for that particular generation was 8.386

The sequence went like so:

8.663
8.386 (10+ hours)
8.494
8.726

I don't consider this a meaningful use of over ten hours of computing time on that box. Especially considering the 5+ hours it spent in this sequence a little earlier:

9.904
9.754 (5 hours !)
9.761
9.437

IMO I'd have done better with the computer shut off, saving the planet the 15 hours worth of electrical consumption......

[nickbrownsfan]

I have noticed the same thing. It will get "stuck" for lack of a better word but the part that has had me is that it will not always pick up the pace after a long generation. Yesterday I saw the laxness levels at 45-66-100 and yet it was taking close to 2 hours per generation (normal avg time is about 15-20 minutes after a full set of 250) and the energy value was in the low 8's to high 7's.
I think the only reason that I dont see times as high as you have is that I use dfgui to restart the client after 15mins of inactivity.

[Scoofy12]

im sure by now you have been admonished that the algorithm is such that the longer "stuck" times should, on average, yield better structures. obviously in this case it didnt necessarily do so, but this is just one generation set. obviously the parameters of the algorithm are chosen such that the best results are yielded overall rather than to make sure nobody ever has a generation longer than an hour, or however long. with 2700 users, simple statistics will guarantee that a) at any given time, a few computers have very long generations, and b) given enough time, every computer will have a long generation (or some combination thereof if you are one user with a lot of computers.) if the algorithm needs tweaking based on the total results returned, then it will be tweaked. furthermore, prematurely ending generations will only skew the results and make it more difficult for them to make the decsions they need to make. besides i'm sure howard, elena, and co. are plenty busy right now as it is.

[gistech1978]

perhaps these are times when the client is "stuck" and using as low as 3-25 megs.

[rsbriggs]

And I will simply assert, given my current understanding of laxness levels, that there is something wrong when laxness values are reaching values like 7*10^11. (Would someone please tell me what value translates to being "100%"?)

Had I hit some reasonably low RSMD - say 5.0 as a result - it would have been a different story, but I can't see any useful science being done in the situation here.

Maybe the current generation should pay some attention to what it has set the laxness levels to, especially after it has gotten stuck in the same place a few tens-of-thousands of times....

[FoBoT]

its a feature

just be glad it isn't crashing

[bwkaz]

Originally posted by rsbriggs
(Would someone please tell me what value translates to being "100%"?)

"100%" is a function of dfGUI, not the algorithm itself. There is no maximum on the numbers.

Take a look at the sources for dfGUI to find the answer to your question. Basically, Jeff talked to Howard, and Howard gave him some numbers that he thought (at the time) would not get hit very often. I'm using 10.0, 10.0, and 5000.0 for the maxima for the three bars in the Linux version, but the official sources may have made any of those numbers bigger (haven't looked in quite some time).

[Dyyryath]

Speaking of which...where's our updated Linux port, you slacker!

[Stardragon]

As we have explained, and as Scoofy was kind enough to point out, this behaviour is planned and inteneded, and it is not wasted computer time, as it actually imporves the results (even if not always visible to you immediately).

We will be adding tweaks to some parameters after this protein is completed.

[Brian the Fist]

Please also see www.distributedfolding.org/phaseiifaq.html Why does the protein get stuck?

[bwkaz]

Originally posted by Dyyryath
Speaking of which...where's our updated Linux port, you slacker!

Sorry! Stupid Real Life and Day Job! I think I need to can it all one of these days, and get going on this again...



(On the plus side, the first graph and all the energy-per-gen stuff is working, except that it doesn't save the stats to a file yet. Unfortunately none of the other 3.1 changes have gotten done... )

[Dyyryath]

Yeah, real life's a real pain in the ass.

No worries, I'm happy to hear that it's still under development.