Let's talk about BigPackets and -advmethods

We need a definitive study on the what cpu should or shouldn't use BigPackets(BP) and -advmethods (-adv). So I'll start:

Test setup:

Test rig was my dually. A dual XP2500+ Barton bridge modded to run MP in an MSI K7D master with 1.5GB of registered PC21000 RAM.

I use the full boat of -local -service -verbostiy 9 -forceasm flags on all clients.

Each test was ran for at least a week and I used FAH Log Stats to keep track of the resulting PPD/PPW (get it here.

The results:

Test One, BP:

I initially began my testing using client 5.00, no -adv, and one client running BP while the other did not. The results were definitely in favor of BP wherein the result PPD/PPW were roughly 12.5-25% higher with BP enabled (600 PPW versus 700-750 PPW). This was even before Stanford changed the point values to further increase the production of BP's.

Test Two, -adv:

I changed both clients to "yes" for BP, added -adv to one client while switching to FAH5.02 assuming that the new client would benefit BP even more so than the 5.00. My results show that the client with -adv is out performing the non -adv by another 20-30% (700 PPW versus 850-900 PPW).

Therefore, my results indicate that a Barton 2500+ should go with both BP and -adv enabled.

What are your results?

All the BPs I have received have finished early and I always end up getting small point values for them. I have not used FAH log to compare though.

just explain to me how to run the test and I will

Run 1 machine with the "Big Packets" option on and record frame times, PPW, PPD, etc etc - and one machine without.

I'm messing around with that program you linked to Wedo, does it take awhile to update your estimated point values?

Mr. Chambers said:

Run 1 machine with the "Big Packets" option on and record frame times, PPW, PPD, etc etc - and one machine without.

I'm messing around with that program you linked to Wedo, does it take awhile to update your estimated point values?

Click to expand...

It has to do one or two frames to get the estimate.

when I get a desktop up, I'll do it(currently on a lappy, tis pimp, but not folding on it, worth to much*4k*)

Wedo, I've been running the big wu's for a while now; since before they were released to -advmethods. I find that they will benefit both AMD and HT P4 rigs over regular work units with 1 exception. If you could feed an XP a steady diet of the big Tinkers, they would outpoint the big wu's, but there's no way to do this that I know of that isn't unethical (like editing the hosts file). One other thing I've noticed is that my Dothan laptop just chews the big packet wu's up like candy; my lappy is a Dothan 2.0 P-M and it folds the 1300-1302 wu's as fast as my 2600 mobile on a NF7-S at over 2350 MHz.

Some other points to remark about on these big wu's is memory usage. I've seen an average memory usage of around 150 MB per client. With a dedicated AMD machine, 1 client with 256 MB ram works just fine. I also tried running 2 console clients on a P4 machine with 256 MB ram and it was able to run them but was extremely laggy and slow to respond to inputs. However, when I bumped it up to 512 MB ram, 2 consoles had no problems at all with both consoles processing big packet work. One other point to make on memory and the big packet wu's is that the cleint specifically checks to see the amount of ram in the machine and the assignment server will not assign big packet work to if your machine doesn't meet the minimum amount of ram. Last I heard it was 240 MB ram minimum for the v5 cleint and before they stopped sending them out to the v4 clients, it was around 500 MB for a v4 client to be eligible for big packet work.

muddocktor said:

Wedo, I've been running the big wu's for a while now; since before they were released to -advmethods. I find that they will benefit both AMD and HT P4 rigs over regular work units with 1 exception...

Click to expand...

Great work Mudd. I have a feeling that anything over 2Ghz (or 2000+ for AMD) and at least 256MB RAM will be faster with BP's and -adv.

I want everybody's input before I whip up the next batch of One-Clicks with the new 5.02 client. I'm thinking that BP's and -adv are going to be the default install but maybe I'll make one without -adv as well.

Very cool.

I still wouldn't use the BP on a machine that's still stuck on dial-up, obviously. Are you working now on the new one-click with the new core Wedo?

Not performance related, but I noticed a rash of EARLY_UNIT_END's (LINCS)when I switched my dual to bigpackets. I can't even remember the last time I had gotten one previously and the system has been absolutely stable. I thought I had heard someone else mention they had this problem.

-Rav

Well, personally I don't use bigpackets on my main rig, because when I play warcraft 3 it makes me get fatal errors related to memory. So, I would turn it off once installed, but I'd say leave bigpackets on for default since most people don't have my problem.

Rav said:

Not performance related, but I noticed a rash of EARLY_UNIT_END's (LINCS)when I switched my dual to bigpackets. I can't even remember the last time I had gotten one previously and the system has been absolutely stable. I thought I had heard someone else mention they had this problem.

-Rav

Click to expand...

Rav, that is fairly normal for the p1301's and p1302's and it's not a sign that your machine is unstable. Stanford says that they are learning a bunch even with the EARLY_UNIT_END's work, trying to figure out how this newer folding process does. You will see less early ends with the 1302 than with 1301 and you do get credit for the amount of the wu folded when the early end happens(at least that's what Stanford says, got too many rigs running them to keep track of it).

Bon3thugz43v3r said:

Well, personally I don't use bigpackets on my main rig, because when I play warcraft 3 it makes me get fatal errors related to memory. So, I would turn it off once installed, but I'd say leave bigpackets on for default since most people don't have my problem.

Click to expand...

I turn off both clients on my main rig when I get ready to play Doom3, just so I don't run into that problem.

i have big packets, but i don't seem to be getting anything larger than i used to... how can i check if its a big packet wu?

Look in Task Manager. BP WUs will use approx 145 - 175MB of memory (normally 150MB). Funny thing I noticed with BP enabled: if -advmethods isn't used, I may not get BP WUs; with -advmethods, p1301 & p1302 are all I get. BTW, I get Early Unit End quite a bit on all rigs with p13xx WUs, but not other WUs. I even backed off my OC but still got it; then I read Stanford's statement about this being common with those WUs.

Another interesting sidenote: I thought my Prescott would handle BP WUs faster due to better memory management (being that BP WUs use so much memory), but it's getting whooped by my slower 2.8C (by up to 2.5 min per frame).

oh those are bigpackets? ok well then bigpackets are giving me about 100-150 ppw more than the regular gromacs. this is on an P4HT rig. One of the instances has had 3 dgromacs in a row ... YESSS!!!

noobie question alert* how do i turn on -advmethods ? I have bigpackets on, but I keep getting these tiny 50 or 100 step work units. I've got a tbred b at 200x10, and 512 ram, so I don't see why I'm not getting bigpackets.

I hate these stupid retarded big packets!!!!!!!!!!! They almost cause me to have a very bad start at school today. I wanted to print my summer work this morning because it was due at school today. When I tried to open up microsoft word with the document, it told me that there was not enough memory. What a load of crap. If on a comp with 512MB of ram I cannot even open word documents, what is next? I could open word however, just not not with too much type. I had to disconnect the printer and try installing it to my comp in the basement while the time is ticking away. I missed the bus and my mom had to drive me to school, furious. It almost makes me want to delete folding from that comp. The reason I couldn't just turn folding off was that I don't have administrative rights on that computer after my brother nearly trashed the OS from his downloading and installing spree. The rest of my first day of school sucked, but was unrelated to this folding crap.

is this on an HT rig? maybe you should enable big packets on just one of the instances.?

lol.... a big packet rant... awesome.

Yeah, you shouldn't need admin rights to edit the client.cfg to switch off big packets. Just change the "bigpackets=yes" to "bigpackets=no" using notepad.

How to turn on -advmethods

*Note: This was all taken from The Ultimate FAH Install sticky

The "Flags" explained

**warning** The following discusses editing your registry which can be harmful to your computer if done incorreclty thereby resulting in possible horked-ness. Wedo, this forum, and anyone affiliated with Wedo Inc. are not responsible for botched regedits. You've been warned.

To edit the registry, hit start/run and type regedit. Go to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\FAH\Parameters

Therein lies a little line called "AppParamters" which contains the much talked about option flags for running FAH. Flags can be added or removed by right clicking the "AppParameters" key and hitting "edit". You will then type the appropriate flags you wish to use.

Here is your guide to the flags:

-local: Used with multiple cpu rigs (dually, HT, quad cpus etc) to set up FAH as one client per one cpu. If this flag isn't used on a dually and two instances are running, your rig will show up as running at 50% in task manager as both instances will split the processing power of one cpu leaving the other to sit at idle.

-service: Sets FAH as a service. Very important flag that will tell your rig to use srvany.exe to run FAH4Console.exe as a service instead of running the client in the console window. Thereby keeping your rig folding even when no one is logged on.

-forceSSE: Forces SSE use for AMD's. P4's do not need this flag, but it doesn't hurt so it's including in most automated FAH installs like the One-Click.

-forceasm: Forces the use of 3DNow instead of SSE. Good for older AMD's that do not support SSE and for machines that are mission critical as some AMD's will lock up with -forceSSE and -advmethods enabled.

-advmethods: The gromacs flag. This flag tells FAH to only seek out Gromacs (a type of protein) from the Stanford servers. Gromacs used to be the end-all-be-all of point production. However, recent changes to the point value for Tinkers have made this flag counter-productive on AMD rigs.

-verbosity 9: Gives you the uber update in your log files. More info will be written in case your having issues or are just interested in what FAH is doing.

Big packets blow chunks on machines with only 256MB of ram. That is all. Carry on.