View Full Version : Big Packets?
maxxoverclocker
01-27-05, 12:34 AM
"Big packets are an option if you have enough ram (256MB+) and will double the production of SSE capable CPU's." - Arkaine23
I would like to enable "big packets" but i do not see this option in the graphical client, is big packets able to be used on the graphical client? (have 1gb or ram and want it to be put to use lol) also my 2.8 @ 3.22 is only getting 56% cpu usage, while this is fine i would like to be using 100% while i'm away from the pc (under options the cpu utilization is at 100%) thanks for your help
apunkrockmonk
01-27-05, 01:10 AM
Sorry to not answer your question (I have no clue what the answer is) but how come I read elsewhere that if you have 1gb of ram or less you should not use big packets.... did I miss somthing?
TidyBowl
01-27-05, 02:04 AM
I'm new to this too but I will try and help the experts can correct both of us if i'm wrong.
To enable bigpackets you need to do 2 things to the graphical client.
Step 1: You need to add the -advmethods to the Shortcut Target so it looks sort of like this. "C:\Program Files\Folding@Home\winFAH.exe" -advmethods
Step 2: You need to change your client.cfg in tyour Folding@home folder. open it in NOTEPAD only. look for the bigpackets entry and change it from no to yes.
Rule of thumb seems to be that you need 1GB memory for bigpckets.
As for the 100% thing -- that's more complicated -- you can go with Wedo'd one-click version for HT (in the stickies above) it installs the program as a service. I guess you could turn one of the services off while you are working and reenable it when you stop.
Or I heard a rumor that you can install another graphical client in a different directory and stop it whenever you want but I hear you have to put in a different directory.
Good luck
T
maxxoverclocker
01-27-05, 02:11 AM
thanks that helped
The reason for that large estimate for memory usage is b/c if you're using dual (or more) instances of FAH, BigPackets will consume a lot of your memory.....I'm running dual instances of FAH and the two BP's use about 160-250MB of memory just by themselves..... so if you only have 512MB of ram, and if 120MB if used by Windows and 250 is used by FAH, you don't have much ram left for gaming.
If you only installed one instance of FAH with BP's on, that's a little different..... then you can have only 512MB of ram and be fine.
veryhumid
01-27-05, 07:32 AM
The reason for that large estimate for memory usage is b/c if you're using dual (or more) instances of FAH, BigPackets will consume a lot of your memory.....I'm running dual instances of FAH and the two BP's use about 160-250MB of memory just by themselves..... so if you only have 512MB of ram, and if 120MB if used by Windows and 250 is used by FAH, you don't have much ram left for gaming.
If you only installed one instance of FAH with BP's on, that's a little different..... then you can have only 512MB of ram and be fine.
plus if you have a hyperthreaded machine that could possibly doing 2 different big packets work units at once you will want even more memory. That is where the 1gb recommendation comes in. :thup:
apunkrockmonk
01-27-05, 09:07 AM
I have an amd with 1gb of ram so big packets should be no problem then! Thanks, I have no clue what a big packet is, but I'm sure its better then a small packet.
Now for a new question, would big packets be beneficial for an amd 1900+ (1.6ghz) with 768mb of ram? The only reason I ask is because I read that adv methods should only be used on processors of 2ghz or more.
I.M.O.G.
01-27-05, 09:11 AM
Big packets are just work units which consume more memory when processed and are larger to download and upload... There is probably specifically more information about bigpacket protein projects on the stanford folding site.
Now for a new question, would big packets be beneficial for an amd 1900+ (1.6ghz) with 768mb of ram? The only reason I ask is because I read that adv methods should only be used on processors of 2ghz or more.
The only issue would be meeting the deadlines and you wouldn't be in danger of missing the deadline unless you're running very few hours or a lot of cpu/memory intensive apps. 24/7 - no problem. I'd guess you should produce big WUs at something near 55 min per frame, about the same as one of two instances on a P4c 3.0.
I was pretty sure those BP's had a time limit of around two weeks....... running two instances of FAH, it takes me around 80 hours to finish a 600 pointer, so you should be well within the time limit for the WU with your cpu.
seadave77
01-27-05, 10:23 AM
I'm running 2 instances of big packets on my 2200+ with 768Mb RAM and it does just fine on deadlines.
Arkaine23
01-27-05, 10:29 AM
Big packet projects take between about 60MB ram and 160Mb ram. The current batch using 60-100MB. If you have 512mb ram, you should be fine for one or two clinets doing big packets. You can actually do a single client with big packets if you only have 256mb ram, it just means you won't have a whole lot of ram free.
Easiest for gui or text clients is probably just to edit client.cfg with notepad, and change bigpackets=no to bigpackets=yes. Also edit the shortcut used to start folding (in the C:/documents and settings/all users/program files/startup folder for the gui client), add -advmethods -forceasm to the end of the target line. Then close folding and restart it from the edited shortcut.
apunkrockmonk
01-27-05, 10:40 AM
That box sits in my basement until one of my parents feels like going on the internet for 10 minutes, then it sits for a week until they want to go on again. Or I feel like watching a movie on the tv down there.
Its my old e-machines. I was trying to think of ways I could OC it to make it fold faster to help more but the bios on that thing is definately crippled.
Mustanley
01-27-05, 11:49 AM
As long as it will make the deadlines and the machine has enough ram, I would always enable bigpackets becuase they are worth double the points.
maxxoverclocker
01-27-05, 05:18 PM
Can you run more than one instance of the graphical client? if so how? thanks
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.