Note: Changing #2.a. needs a restart for changes to be effective ... File -> restart
Do we need to allocate/spare a thread to crunch M-12?

MOBAJOBG is correct.  The CPU is really only used during archiving/compressing of completed buckets before they are sent back to the server.  Using a low bandwidth setup like the one in the first post (by the way, those are pretty much my settings except for the schedule of when to let it run, which I can detail later if necessary), whatever core does the archiving should be mostly free for other crunching.  Now, when you start loading up a 40 Mb line, there will be a core busier with more archiving.

In addition, please remember to activate your preferred software firewall.

For those not wanting to fuss with setting it up yourself, there's a guy , refic who has been with the project for nearly 7 years who is renting nodes.  All you have to do is provide him with your username so he can configure it (and provide him with the monthly fee ).  He says the nodes average about 12 Mbps.  One person who rented a node this past month reported 182,967,119 URLs and 4.75TB of crawling from that node.  That one node in 30 days did enough to be ranked in the top 60 teams.

I took my own advice (seen two posts up - don't make me hotlink it ) and have rented a couple nodes from refic.
 
Keep an eye on the team's output here and here.
 
See the impact it has on my daily output here.
 
Hopefully this scores us a lot of points in the Vault and gets us respectable in the project overall.  

I'd say it would be better to use a lower percentage first.  Take my response with a large grain of salt, as I've never had that much bandwidth to play with on my own.  But if you're running the client on a Windows box, I think you'd be hard pressed to have the CPU keep up with your crawling.  The Windows client is not multi-threaded, so you only have 1 core to do all the archiving of everything you've crawled.  You can set up more than one client, but since you're dealing with Windows and the TCP/IP stack, that means a virtual machines as well.  Linux is a different story, but that's really straying from any sort of experience or reading I've done.
 
Also, it's important to note that your modem and router play an important role in crawling.   (Thank you, Captain Obvious!)  A lot of consumer grade hardware pukes when hit with too many requests, leaving your client unable to do real work or even fetch/flush work.
 
My suggestion is to start out trying to use 5-10% of your bandwidth.   The easy part of that is to set your downstream and upstream in the client's Connection tab, and then set the slider for "use to be limited to" at 10%.  The more experimental part is figuring out how many Buckets and Workers you need to set in the Crawler tab to maximize your working while getting good results (ie, not choking your connection).  I aim for an overall success rate of about 83%.  (Found on the Status tab.)
 
So let's say you're aiming for roughly 10% of your connection.  I would 2.5x the numbers for Buckets and Workers  MOBAJOBG suggested in the OP.  See what your success rate is.  I always try to keep a Workers to Buckets ratio of 2:1 - 3:1.  If you're cruising along with a high success rate, then allow more buckets and workers to get the most efficient setup.  Once you have that sorted, you can scale up the bandwidth usage, increasing the workers and buckets appropriately.
 
It may sound tedious or complicated at first, but it actually is pretty easy and a quick process.  And as the project director himself says, a node crawling a slow pace for a long time is better than a large crawl in a couple days.  It all adds up over time, and obviously the Internet is an ever-changing beast.
 
As for downloading and executing malware, I've been following the project for over 5 years and running it for most of that time.  There's never been an outbreak of system issues due to this.  The crawler doesn't execute code found in webpages it crawls, it just looks for backlinks inside an isolated object.  Alex (the project director) has a pretty good explanation of why it's safe....if I could find it.
 
Sorry for the long post.  

Great discussion!, team8s ...that's what I really like about this place. We turn up to offer valuable bits of information or make a solid effort to help each other.

Opolis

Thinking about doing some occasional MJ-12 since I do have a 45/35Mbps fiber connection.  How much CPU usage are we talking if I use the majority of my bandwith?  Would it be better to use something lower, like 15Mbps, if I am crunching on the CPU along with MJ-12?  How many workers would I use for those two options?  I am also kind of reserved about downloading possible pron pages or pages that contain viruses, even though I read on the MJ-12 site that it shouldn't be dangerous.

Perhaps, "Maximum number of async workers:*" = 225 and "Maximum open URL buckets" = 95 to 100 is my rough estimate. As Col323 has pointed out, the MJ12node client can saturate just one CPU core only.
 
It's not advisable to allocate more than 16Mbps bandwidth connection per client installation. Furthermore, it's preferable to setup virtual machine(s) assigned with 1 logical core, 2GB RAM and a max of 16Mbps bandwidth connection to work with more than 1 client installation.

Thank you for the replies, all very good info!  When I have some time I will try a small amount of bandwidth and see how it goes, slowly working my way up.  I am on Windows 7, generic Verizon FiOS modem/router combo, and don't have much VM experience but I do like to learn.   Setting this up sounds like overclocking (which I find enjoyable).
 
I was mostly looking for some sort of baseline or general settings to start from and compare to, so thanks guys!

I use a cable to connect the spot between the back of my home computer and modem + wireless router that is within a distance in length of 1 meter yesterday. The outcome has been encouraging with an increase of "crawled successes" to 83.2% and also, "overall downloading rate" to 1430Kbps thereby recording a gain of 4.7% and 80Kbps respectively.

MOBAJOBG
Before I forget, I wish to register my sincere appreciation to our other team8s as well. So, to kawika57, duboisi, RHMash, Punchy, planetclown and also, everybody that will join us soon enough or later on ...superThank$U.  

Absolutely!  It's great to see an active team.  Small contributions add up in time and help the climb up the ranks!  And there's always room for more to contribute as they can.
 
MOBAJOBG, I didn't have to do any fiddling with my settings to get this output.  refic has a lot of experience with high speed nodes, so he install and configured these  nodes then gave me the login for each so I could input my user info and keep an eye on them.  I'm sure he has a pretty good idea of default settings to get the output we're seeing.  Overall it was a really simple (and relatively cheap) experience.  I really wanted to try it since my first plan to boost the team fell flat on its face.

I see you on board.  Welcome!  That 7Mbs will be a huge help!  Your error rate sounds fine.  I've noticed some low quality buckets lately, so don't be alarmed if your success rate fluctuates.
 
I can't wait to see a full day of your production!  

For those interested, you can build a GIF stats siggy from dcstat.com for MJ-12 and DIMES.

I'm not a sig guy (witness the vast whitespace beneath my posts ), but Free-DC has a tool to generate one see the first 5 questions.  That will get you something which looks like rilian's shown here:  http://stats.free-dc.org/tag.php?name=rilian&img=.png
 

I believe you can customize the appearance.
 
Nice output from your Verizon line so far, and from the team in general!  We're approaching 10 users, and every person signed up helps carry the load and get us to the top!

Thanks for the shout, MM.  You're a class act the way you root on other teams in their DC efforts.
 
Nice crawling, Opolis!  You broke through the 2 Million barrier yesterday.  How is your setup treating you?  

It appears Col323 is neo.

Col323

I took my own advice [...] and have rented a couple nodes from refic.

[...]

See the impact it has on my daily output here.