Thanks Luke!

Will modify when I get home tonight.

Looking to bring my configs up to current standards and seeing this message at startup:

[2014-02-23 11:44:19] temp-target is deprecated! Use --set-device for better control

What are the modern --set-device parameters I should be using?

Example command currently being issued:  

./bfgminer -S opencl:auto --gpu-fan 100 --auto-gpu --intensity 17,17 --temp-overheat 90 --temp-cutoff 100 --temp-target 80 --scrypt

OK... here is the secret that took me literally weeks to discover:  Use the [H]elp key <lol!  but its true!>  That does a pretty good job explaining the fields.  Essentially that are short term performance, longer term performance, effective performance after rejects, hardware errors, etc.

Here is the full command line I use, complete with a bunch of pools just to show how you can string them together.  I use "--balance" because I host a coin and need to send cycles to both my profit making pool and my coin pools (to show support).  [Pools names modified so that this doesn't come across as an advertisement.]  In a similar vein to my first comment, I've spent more than a few minutes reading the output of "./bfgminer --help".

./bfgminer -S opencl:auto --gpu-fan 100 --auto-gpu --intensity 17,17 --temp-overheat 90 --temp-cutoff 100 --temp-target 80 --scrypt --balance -S cpu:auto -o stratum+tcp://multicoin.poolmod.org:3310 -O Cassey.miner2:pass -o stratum+tcp://yacc.poolmod2.com:3777 -O Cassey.miner2:pass -o stratum+tcp://yacc.poolmod3.net:3337 -O Cassey.miner2:pass

I'm toying with this for long term usage:

./bfgminer -S opencl:auto --gpu-fan 100 --auto-gpu --intensity 17,17 --temp-overheat 90 --temp-cutoff 100 --temp-target 80 --scrypt --balance --text-only --quiet --syslog --cmd-sick /sbin/reboot --cmd-dead /sbin/reboot -S cpu:auto -o stratum+tcp://multicoin.poolmod.org:3310 -O Cassey.miner2:pass -o stratum+tcp://yacc.poolmod2.com:3777 -O Cassey.miner2:pass -o stratum+tcp://yacc.poolmod3.net:3337 -O Cassey.miner2:pass

I'd be using it but the syslog option is generating some stratum+tcp libcurl message I don't see anywhere else, and does so several times a second, generating a lot more syslog traffic than I like.

Since I run a number of different cards in each of my miners (typically 2 or 3), I just stick with the Intensity (-I) parameter to control their heat.  I too target a 80C temp.  Cooling can be a bitch btw, all but one of my miners is open-rack, and the only cased one has a single GPU.

Ignore that third number until things stabilize a bit (like its run for at least 10-20 minutes).  What I was more focused on is the 0.04 MHash (40 KHash) shorter term numbers that are displayed.  That is a bit low, but possible with an "-I 9" setting.  Try it about "-I 15" and see how it does.  Inch it up one-by-one until you either see a hardware error (very bad) or performance becomes unacceptable. 

On the side:  Please don't be thinking about playing graphics games while mining - the two are NOT compatible.  Shut down mining when you are going to do so.  However you should be able to find a setting where basic web browsing, excel, powerpoint, etc. will work fine.

Cassey

Very cool.  Thanks.

Ah, ok, well, at least there is one!

I tried doing both GPU and CPU Scrypt mining at the same time, it was looking encouraging, but I didn't see bfgminer eating any cycles.  Do I need something like "-S opencl:auto cpu:auto" to do both at once?

Played around a bit today and ONLY see these message if I do the --syslog option, and then only in the log file (ok, guess that is no big surprise!).

Is CPU mining with bfgminer possible for scrypt?  I see the algo setting for SSH256 cpu mining, but only do ASICs for that now.  Would like to have bfgminer do both GPU and CPU scrypt mining in one instance if possible.

Is dynamic intensity being turned on when we do an "--auto-gpu"?  If so, I'm using the feature, but not tweaking it with gpu-dyninternal, having never made the connection.

Thanks Pi, that was our feeling.  Basically the coin has gone through its initial "shake out" period.

Hi all.  Just wanted to make it official by posting here:  YACCoin is up and running.

We launched at ~1000 blocks on February 12th, had a great few hours of CPU miners being very happy before the pools sprung up and the normal launch hell broke lose.  We have successfully converted to Kimoto Gravity Well, and, of course, wish we had launched with it, but that is now history.

Pools came and went and came again.  We now have one stable public pool, at least one private pool, and many individual miners.

Please visit our website at http://www.yaccoin.org for more details.

As of this posting:

{
"blocks" : 14307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.35780583,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 2253,
"networkhashps" : 17159634,
"pooledtx" : 0,
"testnet" : false
}

An artwork contest is informally under way and we expect to release at least one update (See the forum for the currently leading contender) that will just be a more formalized "coin look" release.

Basic info:

    Scrypt Algo
    1024 coins per block found
    23.5 years of coin generation
    2 year half life
    1.5 minute block time (90 second generation time target)
    Kimoto Gravity Well based difficulty adjustments
    8.4 Billion total coins
    100 confirmations for new blocks
    6 confirmations for transactions

We have a blockchain explorer available, the public pool, full DNSseed support (5 nodes), a forum, twitter account, Windows, Linux & MacOS wallets, full github source code access, etc.

Cheers!

Cassey (yaccoin@gmail.com)

Getting several of these a second now:

Feb 21 16:38:46 miner2 bfgminer[29929]: Testing pool stratum+tcp://multicoin.zapto.org:3320
Feb 21 16:38:46 miner2 bfgminer[29929]: HTTP request failed: Protocol stratum+tcp not supported or disabled in libcurl
Feb 21 16:38:46 miner2 bfgminer[29929]: Testing pool stratum+tcp://multicoin.zapto.org:3320
Feb 21 16:38:46 miner2 bfgminer[29929]: HTTP request failed: Protocol stratum+tcp not supported or disabled in libcurl
Feb 21 16:38:46 miner2 bfgminer[29929]: Testing pool stratum+tcp://multicoin.zapto.org:3320
Feb 21 16:38:46 miner2 bfgminer[29929]: HTTP request failed: Protocol stratum+tcp not supported or disabled in libcurl
^C
miner2 local.d # 20s: 7.13 avg:11.29 u:11.81 Gh/s | A:19 R:0+0(none) HW:0/none 

As you can see from the last line, bfgminer is connecting and doing work with the pool.

Any way to quiet it up?

From "ps ax":  29929 pts/0    Sl     0:00 ./bfgminer -S antminer:all --set-device antminer:clock=x0981 --text-only --real-quiet --syslog --cmd-sick /sbin/reboot --cmd-dead /sbin/reboot --balance -o stratum+tcp://us-east.multipool.us:8888 -O Cassey.miner2am:x -o stratum+tcp://multicoin.zapto.org:3320 -O Cassey.miner2am:x

When you build the github source, and do the .configure line, you should get final output that looks something like this:

Enabled..Drivers.....: antminer avalon bifury bigpic bitforce bitforce:uio bitfury_gpio cairnsmore drillbit erupter hashbusterusb hashfast icarus klondike littlefury modminer proxy proxy:stratum twinfury x6500 ztex

Note the antminer at the front of that list.  Your list may vary of course, depending on what options you passed configure.

Trying out --quiet --syslog --text-only as above and seeing a LOT of these in the log:

Feb 21 07:29:16 miner2 bfgminer[23705]: Testing pool stratum+tcp://yacc.westlist.com:3777
Feb 21 07:29:16 miner2 bfgminer[23705]: HTTP request failed: Protocol stratum+tcp not supported or disabled in libcurl

The pools I connect to are all reporting my miners present and accepting work, so I'm confused.

Any suggested or required parameters for running bfgminer in the background, launched by the system startup scripts?

Normally I run with the ncurses library and monitor temps and whatnot, but if my monitoring PC dies, so do the windows.  When I travel, I'd like to go ahead and launch in backgroups, to break that dependancy.  Just launching with & seems to work, sometimes, but often my pools report one or more of the machines missing.

I was thinking of "--text-only --quiet --syslog" and maybe even "--cmd-sick /sbin/reboot --cmd-dead /sbin/reboot"

Thoughts?

Cassey

try moving it up above /src - that is where mine is.

Perhaps a bit blunt, but the point is valid.  Creating a coin is NOT for the faint of heart - I know I just launched one last week.  Probably put in 32+ hours and more likely 60+ (it was a blurry several weeks) making slow incremental progress followed by long periods of frustrations.   Yes, getting your genesis key build is a highlight, but there are dozens of other things to consider, like which difficulty algorithm your going to use to try and thwart the raiders, or at least make healing after them go smoother.  Are you going to have a support website?  How about a support forum? Where are you going to announce?  Can you get all the various QT wallets built?  Do you know any pool operators?  Will you be setting up a twitter account?  Are you comfortable with using github?  How many coins, it any will you pre-mine?  If you don't pre-mine are you willing to lose control of your coin?  How often will you add checkpoint records?  Which coin are you cloning from and why?  Do you understand the math behind it all and why you don't want a 10 second block time?  etc.

People can not hand hold you through all of that.  Plan on spending a LOT of time on Google and not just looking at page one results.

If your not comfortable with that, take the original response to heart.

Doing the name change is the easy part.  (Mind you, I still find old references occasionally after a good dozen grep scans, like when a friend tried building the Mac QT wallet for me.)

Site will soon be expanding from Scypt only to include SHA256 coins.  Service is being tested now and expected to be released soon.

I'm happy to report that the hardware errors have virtually disappeared with an intensity of 18 - they are now below 0.5%  (11 out of 2807 Accepts)

Ok - thanks.  Just tried turning the intensity down to 18 on those two cards, but will try that next if the intensity change doesn't fix it.