Client slower?

[Michael H.W. Weber]

I have the strong feeling that the client calculates more slowly with the current and the previous protein compared to the one before. First, there was a massive speed increase after the library was expandable into RAM. But then - as stated - with the last two CASP5 targets, this has changed. Why is this? Have others experienced the same? I noted that this "calculating energy" message appears very often now. Was not the case before. What is going on here? I have asked for feedback in our team - people have made the same observation on different systems with different OS.

To give some data - although I don't have exact values anymore - the current protein is less than half the size of the previous one. Still, within 9 hours on my [email protected] approx. 30.000 structures are generated, so it will be around 80.000 per day. That's comparable (but not identical) to what I had generated for the much larger protein on the same machine.


Michael. :scared:

[wirthi]

Hi,

as far as I remember this question was asked before; The size of the protein has little to do with the time it takes the algorithm to generate it. For the speed of construction it is much more important what the shape of the protein is, and thus, how often the program has to backtack during the construction.

[Michael H.W. Weber]

Calculation clearly should be strongly dependent on protein size, too.

Michael.

[runestar]

H.W.,

Are you SURE you mean the CURRENT protein. The current protein actually moves pretty fast, I'd say at least roughly twice as fast as the last protein. That was a complex one but it made for some great ASCII art at times. If you look at the charts, you'll notice that everyone got a speed boost over previous days.

If you visit the PBB Forum, I track the Top 10 in addition to our own team: http://groups.yahoo.com/group/pbbproteinfoldingproject/files/Daily%20Stats%20Change/
You'll notice everyone's structures took a nice jump after the current update. Also, in addition, if you are using dfGUI, you'll definitely notice the change.

However, I too also did notice it performs the "Calulating Energy" much more often than previous proteins we've been folding. However, because this a smaller and less complex protein, the energy calculation despite occuring more often doesn't signficantly offset the reduced time to cook the structures.

TTFN,

RS½

[Michael H.W. Weber]

I don't know the reason for this, but on my machine the new client with the current (and especially the previous) protein is proportionally (!) slower in a manner that I can detect it without even precisely measuring the generated structures. That's why I dropped by to check out experience of others. The fact that this "calculating..." appears is just another indication that something is different. In our forum other reported this, too - although we also have participants that do not see this. Maybe something went wrong during the last update? But how and what? I don't know. I just downloaded a fresh copy manually. :D

Michael.

[runestar]

Your post reminded me of something. On the last protein, something seemed amiss with the auto-update. I actually went and downloaded the new client from the website. Their was a noticeable although not overwhelming difference.

One thing I do is delete any old db2 files that are sitting around. If there's no filelist.txt file sitting around, they are just leftover files that won't do anything. You might also check the foldit.bat file to make sure nothing is amiss in there. And of course make sure the majority of the files correspond to the date of the release.

I don't if any of these really make any difference, but it certainly doesn't hurt to double-check if you think something is amiss.

Best,

RS½
PBB

[MAD-ness]

On a 1.3 tbird on the current protein using the RAM option you should be over 100k/day

130k or so maybe? Rough guess.

Make sure you have the RAM option set. SOmeone reported that DFgui 1.8 might alter your foldit.bat file, so double check that just in case.

With the -rt option you should use about 70 megs of ram, to give you another way to check.

[runestar]

Originally posted by MAD-ness
On a 1.3 tbird on the current protein using the RAM option you should be over 100k/day

130k or so maybe? Rough guess.

Make sure you have the RAM option set. SOmeone reported that DFgui 1.8 might alter your foldit.bat file, so double check that just in case.

With the -rt option you should use about 70 megs of ram, to give you another way to check.


On my T-Bird 850 oc'ed to 892, I get 106931 daily estimated from dfGUI based on the last benchmark I wrote to disk.

I found if you make changes in dfGUI, sometimes its best to exit the client and the monitor, then restart dfGUI. Sometimes its seems dfGUI doesn't write the foldit.bat with all the correct options you picked., but exiting dfGUI and restarting it (and DF) should fix that.

If all else fails just overwrite everything with a fresh copy off the server. You might keep the one line calling foldtrajlite(?) in a seperate text file someplace for refrence purposes.


TTFN,

RS½

[Digital Parasite]

Originally posted by runestar½
I found if you make changes in dfGUI, sometimes its best to exit the client and the monitor, then restart dfGUI. Sometimes its seems dfGUI doesn't write the foldit.bat with all the correct options you picked., but exiting dfGUI and restarting it (and DF) should fix that.

Really? I haven't noticed this before. dfGUI will only modify your foldit.bat file when you hit Start/Upload/Recover. After you have modified options did you hit Start (or Stop then Start if the DF Client was already running) to launch the client again with the new options you had selected?

Can you reproduce this bug and if yes send me the exact steps you performed to do this?

Jeff.

[runestar]

Originally posted by Digital Parasite


Really? I haven't noticed this before. dfGUI will only modify your foldit.bat file when you hit Start/Upload/Recover. After you have modified options did you hit Start (or Stop then Start if the DF Client was already running) to launch the client again with the new options you had selected?

Can you reproduce this bug and if yes send me the exact steps you performed to do this?

Jeff.
Hi D.P.,

Well, let me put it this way, I've seen it happen more than once. Its not something happens consistently it terms of every other time or every x times, but I had a few times when something I set was not matching what was coming up on the ASCII screen.

I'm suspecting if you make too many changes at one time or you make changes too fast that dfGUI doesn't properly set things up for the next launch. I do know once this starts occuring, that dfGUI doesn't want to seem to self-heal, so to speak, until you shut it down and restart it.

I'll see if I can round up that bug for you.

BTW, I'm starting to suspect the DF may run less stable with dfGUI up... There's been times I come back to this CPU and DF is just not up... no error msgs... just not there and dfGUI thinks its still running until I hit stop. foldtrajlite is not in memory... Last couple days I left dfGUI off after launching DF and the DF ASCII client has stayed there without problem... HOWEVER, I can't prove or disprove this for sure yet.

TTFN,

RuneStar½

[Digital Parasite]

Originally posted by runestar½
BTW, I'm starting to suspect the DF may run less stable with dfGUI up... There's been times I come back to this CPU and DF is just not up... no error msgs... just not there and dfGUI thinks its still running until I hit stop. foldtrajlite is not in memory... Last couple days I left dfGUI off after launching DF and the DF ASCII client has stayed there without problem... HOWEVER, I can't prove or disprove this for sure yet.

I have dfGUI running all the time on all my machines and so far I haven't had any problems with DF either starting without the proper options or being less stable.

dfGUI looks for foldtrajlite.lock to guess if it is running which is not 100% accurate because if DF dies and doesn't delete the foldtrajlite.lock file like it is supposed to on a graceful exit dfGUI will think it is still running. That is why dfGUI reports that "it appears to be running" not "it is running". When you hit STOP, dfGUI deletes foldtrajlite.lock which if DF was running would tell it to quit after it finished the current protein and if it had crashed would clear things up to start properly next time.

dfGUI is just an interface to launch/monitor DF. It doesn't actually run DF itself so it can't make DF any less stable than any other program you have running on your system can.

What OS are you seeing this on anyway? If it is Win95/98/ME the OS isn't that great at running 100% CPU usage jobs so anything could be destabalizing it. If you find anything reproducable, let me know.

Jeff.

[Paratima]

Hi, Jeff. I've got dfGUI running 24x7 on at least 10 Win2K machines...like a dream! :thumbs:

A teensy thing: I just installed V1.8 on a newly-built Win98SE box, and it just reports ??? in the MHz field. I complained about this about 5 or 6 versions ago and you fixed it right up. I could probably dig back through the archives here and find out exactly when that was. Anyway, somehow it got unfixed in the interim & I just now noticed it.

Thanks again for a great tool! (at a great price!!)

[runestar]

Hey D.P.,

Its W2K box I'm on... I didn't have a problem on any other system so far with the client disappearing, just this one.

Maybe my system is just being idiosyncratic. =)

BTW, someone suggested to me that if you used a DirectX call you could get the processor information. Indeed, if you could use the same routine DirectX uses to get the system information, it seems DirectX shows the processor information.

TTFN,

RS½
PBB

[Digital Parasite]

Originally posted by Paratima
A teensy thing: I just installed V1.8 on a newly-built Win98SE box, and it just reports ??? in the MHz field. I complained about this about 5 or 6 versions ago and you fixed it right up. I could probably dig back through the archives here and find out exactly when that was. Anyway, somehow it got unfixed in the interim & I just now noticed it.[/B]

dfGUI right now just reads a registry entry that Windows seems to create when you install the OS that contains the MHz rating for your machine. It doesn't always exist in Win9x machines for some reason and if you upgrade your hardware at all it will not get updated and contain the old value. The only way to fix it is to create/modify the registry entry:
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz

Jeff.

[Digital Parasite]

Originally posted by runestar½
[BTW, someone suggested to me that if you used a DirectX call you could get the processor information. Indeed, if you could use the same routine DirectX uses to get the system information, it seems DirectX shows the processor information.

Do you/they happen to know what the DirectX call is to get such information?

Jeff.

[runestar]

No, it was just an observation he was making. I do have a friend who is a programmer and I'll ask if he knows how it can be done.

Best,

RS½
PBB

[dtsang]

This protein is slightly faster than the previous one.

Last protein: 33,000/day
This protein: 41,200/day

I am running a Power Mac G4 with a 466 MHz processor and with -rt enabled.

[bwkaz]

Originally posted by Digital Parasite
Do you/they happen to know what the DirectX call is to get such information?

Jeff. Searching the MSDN library for MHz yields a couple of pages:

This one says it works on NT4SP4 and later, no mention of 95 or 98:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_processor.asp

It's based on WMI, and I have no idea how that works, but maybe....

Here's one for 2K and Me:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/Shell/reference/objects/ishelldispatch2/getsysteminformation.asp

That seems to be about it, unfortunately...