Folding Forum

Hi I was wanting to install FAH however I have a data cap on my internet of just 2GB per month (shit I know - rural 3G connection), and its kindof expensive for more data (esp being a student).

I was wondering how much data FAH would typically transmit across the net...

I suppose it depends upon a few factors such as how often and how fast the data is processed. I am on the internet everyday, the link speed is usually between 1 and 3 mbits and I run a quad core i7 with an nvidia 9800GT (with Ubuntu 11). I use it mostly for web development so the processes running would be mysql/apache/netbeans/firefox so I think there should be a bit of CPU time free.

Is it possible to determine the usage from these details alone?

Very difficult to give any meaningful estimate for you, since types of WU and folding habits may vary a great deal. For example, considering my 24/7 folding but supposedly quite typical internet usage patterns otherwise, I would expect FAH to dominate in the sent bytes category in my case. Here's what my router logs report for my WAN sent MBytes:

• June: 606MB
• July: 640MB
• August: 754MB
• Average: ~667MB/month

Since your setup would be much more powerful at folding than mine, I'd expect the bandwidth usage to be higher as well. Most likely way too high for the 2GB cap if you start folding 24/7 at full blast. At the very least you'd have to monitor the bandwidth usage really closely. Also bear in mind, this is just what I send, the FAH client needs to download work too. Can't provide similar estimates regarding my FAH downloads, though, I assume FAH plays a very minor role in my received bytes category.

You might want to try a single uniprocessor client first, configure it for "small" WUs and see how it goes. The production (PPD, Points Per Day) will be far from stellar, but that will most likely give you plenty of time to react in case the bandwidth use starts to get out of hand.

GPU units seem to be quite small, most less than 1MB, and a 9800GT will not do many of them too fast. GPU Linux also tends to be a lot of work to get/keep running. Might want to keep GPU on the back burner until you're sure your cap can handle SMP.

SMP tends to be quite a bit larger, 5-20MB. You can choke the SMP client down to as few as 2 cores by using config flags. Catch there is you are not supposed to change core count mid-unit since it can hose the integrity of the results. "Typical" i7 running "-SMP 8" will do 1 WU every 4-6 hours. at 10MB a pop, you're looking at 1.4GB/mo. That is probably a high side estimate. Actual may be half that. Cutting down to -SMP 4 will drop your production by maybe 10%. Once you start cutting real cores(-SMP 3,2), it's pretty near linear.

I'd like the OP to give some more detail on the usage patterns. First, does the 2GB cap apply to upload, download, or both combined? Second, is the machine running 24/7? Third, how important is it to always stay below the 2GB cap? I am aware of deals which can be very nice if you stay below the quota, but cost you arm and leg if you exceed it even slightly.

BTW, welcome to the forum, hamstar.

The size of each download and each upload depends on which project is assigned. Of course total bandwidth depends both on the size of the data packages and the rate at which your hardware completes them. With no bandwidth cap, a quad core i7 is well suited for SMP folding, but some SMP projects have larger data packages than others. Since your CPU is about twice as fast as his Atom330 @2.1GHz you'll be exceeding your bandwidth cap unless you choose to fold at less than peak throughput -- and it will vary.

One option would be to limit your folding to two cores. You can specify "-smp 2" which, if you fold 24x7, will probably produce close to your cap.

Another choice is to choose to run one or more uniprocessor clients by NOT specifying -smp. In fact, that's probably the best place to start. The WUs assigned to uniprocessor clients are generally pretty small and you can experiment with the the advanced configuration setting for WU packet setting [Small/Normal/Big] before electing to install a second uniprocessor client.

Hey Napolean, the 2GB is download and upload. Extra data is pretty expensive and I'm just a student so can't really afford to go over it. Damn incumbent telco holding our country to ransom.

The machine runs probably average 16/7.

Cheers for the replies, really helpful.

Also, I just found out its not an i7. Its a Q6600 Core2Quad.

Most people think of an i7 as 8-thread machine rather than a 4-core machine (or 12- / 6- for the top of the line model). I've got a couple of Core2Quads similar to your Q6600. Except for being somewhat slower than the i7, everything I said still applies.

Reviewing the log files from a Q6600 running Linux 24x7, I extracted the following typical lines containing upload/download data for the last 30 days

[16:57:51] Initial: 0000; - Receiving payload (expected size: 1775233)
[16:57:54] Working on queue slot 07 [September 12 16:57:54 UTC]
[03:31:18] - Reading file work/wuresults_07.dat from core
[03:31:18] (Read 3532848 bytes from disk)

In the example above, 1.8 meg was downloaded, and 3.5 meg was uploaded. As was pointed out earlier in this thread, work unit sizes vary from project to project and even a little bit from run to run.

A total of 64 work units were downloaded, computed and returned

I calculated this particular machine had 117 meg downloaded, and 440 meg uploaded. Your results will likely vary

C2Q 6600 doesn't really change anything in terms of bandwidth.

Start with -SMP 2 and see if you ca increase from there.

Judging by parkut's performance data (about 12h per WU on a dedicated setup?), normal SMP folding doing one WU per day might also be a good option. The -oneunit flag helps there, with said flag in effect the client will download, compute and upload a single WU, then quit. Start the client with -smp -oneunit flags immediately after you've started your computer, and see if you're consistently capable of returning single SMP WU within the average 16h daily uptime. Also, if you're getting uncomfortably close to the cap, solution is dead simple - just refrain from folding for the rest of the billing period.

If the OP is feeling really brave he could try running the GPU under wine - minimal (~200Kb) WU size, will give about 5k PPD and use maybe 60mb per month