• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Project 2619

alan2308

[H]ard|DCer of the Month - October 2008
Joined
Dec 13, 2005
Messages
4,110
Just picked up this chewy unit on my E6400. Cut my PpD on this box almost in half. Is this one of those units that needs more cache or does it just suck that bad?

 
I have a feeling that SMP will still be the way to go.....

However we are going to be getting, as you put it, "chewy" units like this mixed in.

 
I got 2 of them on my 2 VM and so far, they are very poor in ppd (1500 ppd vs 2100 ppd for 2653/2605). Also, they eat a lot of memory with over 800 MB per WU !! Vijay Pande and Kasson are looking at issues with the WU config since it got assigned to my box even if it have just 512 MB per instance so they crash till I upped to 1024 MB.

I also got 2 3050 WU at work as well and they produce just 800 vs 1200 for others. Hate those WU...

 
I got 2 of them on my 2 VM and so far, they are very poor in ppd (1500 ppd vs 2100 ppd for 2653/2605). Also, they eat a lot of memory with over 800 MB per WU !! Vijay Pande and Kasson are looking at issues with the WU config since it got assigned to my box even if it have just 512 MB per instance so they crash till I upped to 1024 MB.

I also got 2 3050 WU at work as well and they produce just 800 vs 1200 for others. Hate those WU...


I have a bad feeling this will be the norm from now on

 
Not to get all mushy and optimistic and all... but at least the work is still getting done...

Let's not forget why we're all here guys....it's only points, and if we're all getting similar points for similar amounts of work... what difference does it really make?

Just my thoughts... I'm sure there is more to it all than that, but like I said, just my thoughts.....

 
I got 2 of them on my 2 VM and so far, they are very poor in ppd (1500 ppd vs 2100 ppd for 2653/2605). Also, they eat a lot of memory with over 800 MB per WU !! Vijay Pande and Kasson are looking at issues with the WU config since it got assigned to my box even if it have just 512 MB per instance so they crash till I upped to 1024 MB.

I also got 2 3050 WU at work as well and they produce just 800 vs 1200 for others. Hate those WU...


800 MB per WU :eek: Do you think we will be able to run 2 SMP clients on a winxp box with only 2 GB? I still use those rigs for other things while the clients are running....

 
However we are going to be getting, as you put it, "chewy" units like this mixed in.

I have a bad feeling this will be the norm from now on
Probably, but it's to be expected. It was the same case a few years back when Stanford had released big WUs for the standard client and people were freaking that their older machines took so long to process them. I guess it's all the more reason to start thinking more about Penryn and newer hardware.

 
Not to get all mushy and optimistic and all... but at least the work is still getting done...

Let's not forget why we're all here guys....it's only points, and if we're all getting similar points for similar amounts of work... what difference does it really make?

Just my thoughts... I'm sure there is more to it all than that, but like I said, just my thoughts.....


QFT. Just a bit of an OMG!! moment after looking at FahMon. As I've said before, the points will come if you stick with it. Now everyone get over to the why we fold thread for a little reminder.

 
lol...you guys need to look at some of us old timers and our sigs....back then we struggled to do 100s of points per day.

The playing field is level, slow and steady wins the race.
 
I managed to get a couple of these. The first one is on my X2@3.0 and it's using 508 meg of RAM. That would be right for that machine since it's configged for all my RAM (1 gig) minus what is being used for the onboard video.

I also have one running on one of the VMs on one of my quads. I'm pretty sure I have it set for no more than 512 meg of RAM but I'm not 100% sure and I'm too lazy to hook up a monitor, keyboard and mouse to the system at the moment since the VNC program isn't working worth a shit on it at the moment. But if these WUs aren't supposed to be on machines configured with 512 meg of RAM, then there is going to be a problem.

I'm not sure of the PPD on the one on my X2 at the moment. FahMon is showing 1248.60 PPD on the X2@3.0 which is normally does 1368 PPD with the 1760 pointers I believe. However, I just updated the projects on the monitoring client so I'm not sure if the PPD it's showing at the moment is correct or not.

 
Well, this explains why one VMWare crashed on me last night with 2619. I'll increase the memory. Thanks guys.

If you're running 2619 in a VMWare, check out your CPU load. This new unit is actually pushing the VMWare to 100% load.

Also, what is TETHERED VESICLES? Sounds painful.

 
I've just looked at one of my VM's running this protien.
Memory useage is up from ~600 meg to ~1 gig.
Looks like I need to up the memory put aside for the VM's to ~1.2-1.5 Gig.

TETHERED VESICLES Are chewwy ........... :p

Luck ............. :D
 
If folks are having a RAM crunch, VMWare + Windows SMP works and you won't have to allocate so much RAM to two VMs.

Now Stanford is really making it clear that it wants brute force. I'm sensing a eulogy for dual VMs soon that was only hinted at with the 30xx units. Anyone want to play taps? I can't be too upset. I rode that loophole to almost 3 million points.

 
I had a unit the last 2 days from Project 3065 (Run 5, Clone 23, Gen 25) that was taking an extra 12 minutes per % to complete...dropped the ppd on my e6400 from 1400 to 1000 :eek:
 
If folks are having a RAM crunch, VMWare + Windows SMP works and you won't have to allocate so much RAM to two VMs.

Now Stanford is really making it clear that it wants brute force. I'm sensing a eulogy for dual VMs soon that was only hinted at with the 30xx units. Anyone want to play taps? I can't be too upset. I rode that loophole to almost 3 million points.


There is no reason to worry about dual VMs unless Stanford is going to say you can't run the SMP client on anything less than a quad core. I don't see this happening any time soon since there are a hell of a lot more dual core systems than quad core systems and it's going to be that way for a good long while yet.

Remember, the VMs are reporting that the system is only a dual core rig. Therefore, unless there is a screwup by Stanford, you should not be getting work units specifically for quad cores with a VM. Running dual SMP clients outside of VMs is where you run into the problems of getting quad core only work units and not having enough time to finish them. It's natural that it happens that way because each client is reporting that each one has 4 cores to make use of and should complete the work unit in time.

 
Actually, Stanford admitted there is a problem with the memory config of the WU. Normally, it shouldn't never be assigned to boxes with less than 900 MB of ram and currently, it's configured to upload to machines with 200 MB at least (linux and OSX). Windows is worse with 64 MB minimum.

If they fix that, a good trick to avoid them (if the ppd stink) is to not allocate more than 800 MB. Right now, even if your RAM is under 768 MB, it get assigned and will crash the VM unfortunately. However, they might rebench it since not only me see a drop of 500-1000 ppd with them even if the cache is 4 MB (it is supposed to be roughly equal to others with 4 MB).

 
We have to prepare for life after 2605/2653.




I was running SMP before the 2605 and 2653 projects were so prevalent. I ran through plenty of work units which didn't have the nice PPD values as those two and I'm not too worried about it. Stanford would slit its own throat if it discontinued the SMP client for dual core machines. As I said, there are a lot more dual core machines out there than quad core.

Besides, as of now I haven't had a problem with missing deadlines (that I know of) even with the 4 core required/short deadline work units. Yes, I've had several of them on my main system which I have running two clients but outside of VMs. Sure, running 3.6Ghz on that quad helps, but still.

 
Remember the 2610 WU which is very prevalent last summer and fall. Those WU take a PPD hit if you don't have 4 MB of cache and not everyone have 4 MB C2D/C2Q at the time but we all survived.

 
I was running SMP before the 2605 and 2653 projects were so prevalent. I ran through plenty of work units which didn't have the nice PPD values as those two and I'm not too worried about it. Stanford would slit its own throat if it discontinued the SMP client for dual core machines. As I said, there are a lot more dual core machines out there than quad core.

Regardless, work units aren't going to become simpler in the future. What you call slitting their throats, they might call progress.

Since you ran SMP before 2653, you should be very familiar with 2610. They needed memory bandwidth and cache and would not have done well in dual VMs. Future work units may need tons of memory and bandwidth. Will you continue to run dual SMP, even if there is no PPD advantage or even a penalty? I think this is coming.

If they fix that, a good trick to avoid them (if the ppd stink) is to not allocate more than 800 MB.

Avoiding the most complicated work units is probably bad for the project. Somebody has to crunch them.

 
Regardless, work units aren't going to become simpler in the future. What you call slitting their throats, they might call progress.

Since you ran SMP before 2653, you should be very familiar with 2610. They needed memory bandwidth and cache and would not have done well in dual VMs. Future work units may need tons of memory and bandwidth. Will you continue to run dual SMP, even if there is no PPD advantage or even a penalty? I think this is coming.



Avoiding the most complicated work units is probably bad for the project. Somebody has to crunch them.


Yes, I'm very familiar with the 2610. I've been running the SMP client since it was released to the public. I was also running an E6400 with 2 meg of cache at the time and I saw a large point hit running that unit. I'm not going to worry about work units as Stanford will not kill off the ability to run the SMP client on dual cores. If they did they would have to call it the quad core+ client.

I'll worry about PPD when things change drastically. I generally setup my clients to get the best PPD. Part of this has to do with the competition and the main part is that in general, the work units which give the best PPD are doing the most science.

I currently have my VMs limited to 512 meg of RAM and the clients running on them limited to the same. I normally do not need the extra gig of RAM for the host OS but it's there anyway. Part of the reason I limited it to 512 for the client was because that's what generally keeps me getting the 2605 and 2653 projects for the best PPD.

People running VMs and dual clients like many of us are are the minority. Few people want to take the extra time to learn or setup something like that. Trust me, there are plenty of people out there who will crunch these work units. I can get just about anything on my main machine since I'm only running dual clients with no VMs. I have plenty of RAM in that machine so I'm not worried. However, that machine rarely gets 2605 or 2653 proteins since both clients report as being on a quad core machine.

 
Yes, I'm very familiar with the 2610. I've been running the SMP client since it was released to the public. I was also running an E6400 with 2 meg of cache at the time and I saw a large point hit running that unit. I'm not going to worry about work units as Stanford will not kill off the ability to run the SMP client on dual cores. If they did they would have to call it the quad core+ client.

I'll worry about PPD when things change drastically. I generally setup my clients to get the best PPD. Part of this has to do with the competition and the main part is that in general, the work units which give the best PPD are doing the most science.

I currently have my VMs limited to 512 meg of RAM and the clients running on them limited to the same. I normally do not need the extra gig of RAM for the host OS but it's there anyway. Part of the reason I limited it to 512 for the client was because that's what generally keeps me getting the 2605 and 2653 projects for the best PPD.

People running VMs and dual clients like many of us are are the minority. Few people want to take the extra time to learn or setup something like that. Trust me, there are plenty of people out there who will crunch these work units. I can get just about anything on my main machine since I'm only running dual clients with no VMs. I have plenty of RAM in that machine so I'm not worried. However, that machine rarely gets 2605 or 2653 proteins since both clients report as being on a quad core machine.


Of course you're not worrying about it, you're already over a million points :p:D

 
aldamon, I'm stating this as a general comment, not that I will be avoiding them myself (I have 4 GB on that box so I don't mind allocating 1 GB per VM). Don't be surprised Stanford will change the trends with the new WU like the 306X, 3050, 2619 and possibly others later. Anyway, keep in mind that the 2619 might be rebenched since the points discrepancy even with 4 MB of cache is not normal (the deadline is 2 days and preferred deadline is just 1 day IIRC, so the points should be over 2000 but they are currently 1620 points each)...

Like SmokedRngs, those who tweak to get the best mix is in the minority and there is 80-90% of them who just setup and crunch on whatever Stanford throw at them.
 
Update: Kasson said they will put the A2 core back to advmethods instead of public due to memory usage issues. This confirm my observation I reported to them yesterday...
 
Anyway, keep in mind that the 2619 might be rebenched since the points discrepancy even with 4 MB of cache is not normal (the deadline is 2 days and preferred deadline is just 1 day IIRC, so the points should be over 2000 but they are currently 1620 points each)...

Unless it's been recently changed, 2619 has a preferred deadline of 4 days, not 1:

http://fah-web.stanford.edu/psummary.html

2619 171.64.65.56 p2619_tethered_vesicles 308047 4.00 4.00 1620.00 100 GROCVS Description kasson

Don't be surprised Stanford will change the trends with the new WU like the 306X, 3050, 2619 and possibly others later.

Change the trends how? Do you think they're going to get simpler or more complex? I've stated my case.

 
fahmon just said the deadline is 1 day but I'm pulling them from a different psummary :rolleyes: I'll recheck that tonight when I get back home.

I think it will get more complex, now that Stanford will be able to release WU for more than 4 cores. However, predicting the trend is like trying to determine where a ant is going from a anthill ;)

 
I think it will get more complex, now that Stanford will be able to release WU for more than 4 cores. However, predicting the trend is like trying to determine where a ant is going from a anthill ;)

Hehe, then I won't be surprised. That's what I think too.



 
Be very carefull about shutting this one down if running as a service via Finstall.
So far I'm 2 crash's for 2 stops useing ./folding stop.
Both times ERROR 0x1.

Luck ............... :D
 
Does anyone know if your running a diskless with 2x instances if your going to need more than a gig of RAM in the box? I'm kinda feeling that we do now.

 
No idea.. my diskless boxen has 2g and one instance, and it's crunching the 2619 just fine.. a little slow, but it's still going...

Of course, I suppose that's not really helpful at all sooooo........ ;)

 
No idea.. my diskless boxen has 2g and one instance, and it's crunching the 2619 just fine.. a little slow, but it's still going...

Of course, I suppose that's not really helpful at all sooooo........ ;)

I didn't have problems crunching. It crashed on submission at 100% without enough RAM. Worst case scenario.




 
I didn't have problems crunching. It crashed on submission at 100% without enough RAM. Worst case scenario.





Well that's better than blowing up, but to work on a WU to 100% then crash... that's not all that good.

I'll order ram when I have problems.

So far 1gig is enough in a quad box running 2 instances.

 
I got 3 more 2619 now so if they push them a lot (ie, the next 2653-like batch), be prepared to buy extra memory to run them...

 
I got 3 more 2619 now so if they push them a lot (ie, the next 2653-like batch), be prepared to buy extra memory to run them...


Have you upgraded your clients? I'm wondering if this was one of the causes for the update?

I haven't updated mine yet, I can't with most of mine till notfred comes out with a new version

 
Nothing I did... They started pushing the A2 core out of the blue so all linux boxes got them.

 
Nothing I did... They started pushing the A2 core out of the blue so all linux boxes got them.


I'll start getting them when I get the new diskless system. For it to download the new core I think it needs a reboot.

Also on my windows box..... I run 2x SMP clients and I have 2 gb of RAM

If I game and do all the other normal stuff do I need to up to 4gb. I run win XP, it can't address all of it can it?

 
For now, the A2 core is pulled from Windows SMP boxes due to issues.

 
Back
Top