QMD's Back

[[Spectre]]

Monday July 18. You have to have 1GB or more of system memory.

 

[Carnival Forces]

is this a slap in the face to OC-AMD and others who have quit?..sounds like a dangerous move from Vijay...

 

[marty9876]

I would not view it as a slap in the face. To me, it's more of a knee jerk reaction to a problem, which was/is not really the core issue. QMD's are memory hogs and are getting a "bad" rap from this.

Overall, memory usage (QMD's and other WU's) is increasing and some folks just want better ways of controlling this.

 

[psychosonik]

I would not view it as a slap in the face. To me, it's more of a knee jerk reaction to a problem, which was/is not really the core issue. QMD's are memory hogs and are getting a "bad" rap from this.

Overall, memory usage (QMD's and other WU's) is increasing and some folks just want better ways of controlling this.

Ya, I agree. This is acadamia, not some barnyard home-brew program. They need a level of control and precision with their results, getting hung up by some high school freshmen running QMD's on their pentium 3 would get me a little irked too. As they say, if you can't play with the big dogs.. stay on the porch...

 

[Strikemaster]

I'm sorry? As someone who 1: has two fast P4 borgs with >1 gig of memory and 2: has had QMD slam them on their bellies to crawl for a day or two, this is not whining. The machines *are* "Big Dogs", and I for one don't care for them being beaten down like back-alley mutts. The change in performance today, once the QMDs had finished and been replaced by other projects, was staggering. The workstation (2.2 ghz P4) actually responded to input again, and I didn't have to use a calendar to time it!

The QMD memory usage has got to be reined in, or handled in some other fashion than the core is doing at this time. Tinkers and the big Gromacs back off a helluva lot more gracefully and faster than QMD, and that is the crux of the problem as far as I'm concerned. I've shared time on my A64 gamer with a P1144 600-pointer on occasion, and that comp was far, far more responsive given the load than a QMD / P4-HT combination.

My take? QMD should stay as "beta" and "experimental" until Stanford fixes the client. No patch jobs like "1 gig of memory required" warnings to the operators, the CLIENT itself should know this by polling the machine's activity and adjust the request for WU accordingly. So what if the machine has 3.5 gig of RAM? If the machine has a history of using 3 gig for normal program operation, FAH502 should NOT ask for, or allow WU with a footprint that will exceed historical physical RAM usage.

Sorry, Stanford. These two "Big Dogs" are going to be allowed to stay on the porch until you quit putting lead framing on the QMD sled.

 

[SmokeRngs]

I don't think that the client should be able to examine the memory usage of a machine. I have no problem with it being able to see how much RAM the machine has. I think the fix definitely needs to be in the client but I think it should be as an option to limit the amount of RAM the client is capable of making use of. In other words, instead of the client reporting how much RAM the machine has, it would look at how much RAM the machine has and then report back the amount of RAM that was indicated in the setting as long as it's not more than the physical amount of RAM the machine has.

I believe this would take care of a lot of the problems with RAM usage. If after that was implemented, someone wanted to bitch about RAM, then it would be all on their head. They can go back and reconfigure the correct amount of RAM for the machine to report it has.

I'm not going to say this is an overall fix. It obviously won't stop Stanford from putting out WU's that want a shitload of RAM. But it will stop people that don't want them from getting them.

I have also seen mention of the memory bus being saturated. I will assume that this is happening with the QMD cores and it's not necesarily a problem with the amount of RAM being used. For that I don't have a solution and I guess that problem is something I have not taken into account. I'm sure a fix can be made for that if enough people brainstormed about it.

I guess it all boils down to the fact that the client just doesn't have enough options to configure it properly and tailor to a specific user's or client's needs. I have noticed this more and more lately. The client itself just keeps feeling more and more archaic and is not keeping up anywhere near as fast as they are putting out new cores and WU's.

I would love to have a client that would allow me to choose Tinkers, Ambers and bigpacket Gromacs for my AMD SSE capable machines. Those are what seem to run the best on them and almost all my machines and borgs fall into that category. My favorite WU's are the bigpackets Gromacs and the Ambers for points. My main machines just tear through them. I also prefer to keep Tinkers on my non-SSE Athlons but as far as points are concerned, the timeless Tinkers just don't seem to put out the points the regular Tinkers do. I have noticed this on my 1.4 Ghz T-Bird borg. I had it for a day and a half to mess with the other day and it can't put out as many points as a 1 Ghz SSE capable Duron that was running a normal Tinker. I know the AthlonXP and Morgan core Durons are a bit more efficient that the old T-Bird and Spitfire cores but the difference can't be as much as the points production was showing.

 

[HOCP4ME]

I'm new to folding, what excatly is a QMD?

 

[Kvothe]

QMD's are currently beta proteins that run on fahcore_96.exe. Info on these protiens can be found here. These are in the range of the 1900's. There have been some issues in regards to RAM usage and such, but it requires running with big WU's and -advmethods to get them. Currently these are only available for the Intel platform.

 

[Codegen]

I swear my last one was a QMD....

I know I saw it somewhere. Right now I'm on a double gromacs.
edit: Oh wait, it was PMD

 

[marty9876]

I'm sorry? As someone who 1: has two fast P4 borgs with >1 gig of memory and 2: has had QMD slam them on their bellies to crawl for a day or two, this is not whining. The machines *are* "Big Dogs", and I for one don't care for them being beaten down like back-alley mutts. The change in performance today, once the QMDs had finished and been replaced by other projects, was staggering. The workstation (2.2 ghz P4) actually responded to input again, and I didn't have to use a calendar to time it!

The QMD memory usage has got to be reined in, or handled in some other fashion than the core is doing at this time. Tinkers and the big Gromacs back off a helluva lot more gracefully and faster than QMD, and that is the crux of the problem as far as I'm concerned. I've shared time on my A64 gamer with a P1144 600-pointer on occasion, and that comp was far, far more responsive given the load than a QMD / P4-HT combination.

My take? QMD should stay as "beta" and "experimental" until Stanford fixes the client. No patch jobs like "1 gig of memory required" warnings to the operators, the CLIENT itself should know this by polling the machine's activity and adjust the request for WU accordingly. So what if the machine has 3.5 gig of RAM? If the machine has a history of using 3 gig for normal program operation, FAH502 should NOT ask for, or allow WU with a footprint that will exceed historical physical RAM usage.

Sorry, Stanford. These two "Big Dogs" are going to be allowed to stay on the porch until you quit putting lead framing on the QMD sled.

Huh, pull the -adv flag if you don't want QMD's. Yea, hack for now but it *does* work.

 

[psychosonik]

I just turn on my machines and launch the client. What stanford does with my machine after that is their business. You have to accept that when joining a project run by someone else. Our business is boring... and business is gooood.