That is also wrong information. The current official version of cgminer is 4.3.4 and does NOT take bmsc-options nor does it take bmsc-freq nor did it ever take them (only an unofficial fork did). Only the anu-freq command is in the official cgminer, and yes 250 is a good choice to the person asking.

Sounds to me like you're not remotely using the current version of cgminer and are using an unofficial or ancient one or something. Grab the latest which is 4.3.4 and follow the instructions as what you're passing to cgminer aren't even options on cgminer.

There are a number of new accounts created with minor changes to well known members (in this case the reverse apostrophe at the end). Please report these to moderators when you see them, and don't quote their btc address when posting here.

For starters that device isn't supported by the older cgminer so it's barely working thinking it's a different device. Latest cgminer is 4.3.4, upgrade. Nonetheless I dont think that's your ghash problem.

I'm not being aggressive, I'm being critical which is what all changes deserve these days as the stability in pooled mining has come hard fought and you'll get much more resistance from the pool ops than me.  If there was universal support for anything I'd add support myself, but I don't see it forthcoming with this one.

"client.reconnect" discussion


Example:
The parameters are [URL, port, wait time] as string, integer, integer

If client.reconnect is sent without parameters, the miner is to assume it's to reconnect to the same port and URL.

There is no official documentation apart from the current implementation in cgminer and various bitcoin pools however there is generous discussion.

I put together a summary of documentation here:
https://bitcointalk.org/index.php?topic=557866.0

The closest we have to an RFC is this thread here where extensions got discussed along with standards.
https://bitcointalk.org/index.php?topic=108533.0
If you don't like the defacto standards I'm sorry.

If you wish to extend the protocol for your coin's mining software and pool, go nuts. No one's stopping you, but as I said what you are asking serves zero utility in bitcoin mining so no one here will care to adopt it or extend the defacto standard to include it.

By the way, the search facility only looks at the section and any child threads from where you start your search. So if you're currently looking at this Spondoolies thread, it will only search this thread.

Last time it did a big jump like that it was the attack that was redirecting people's hashes from other pools to their own p2pool node.

Kano has an S2 now and is working on official code for cgminer that hopefully will rectify the behaviour of the driver they included with it.

Quite a few of these accounts have been nuked. Just keep reporting them.

Any chance you could split this thread into two? The altcoin mining support stuff really doesn't belong here.

This is a solution looking for a problem. Stratum servers are obliged to send you work updates no farther than 60 seconds apart and I doubt they'd appreciate a way for you to spam them with requests. If this is some workaround for some altcoin design or pool issue you'll get no love here.

Thanks. There's not much information in that. Did you use the debug cgminer.exe binary from that directory as well?

No, they're honestly trying to protect new people who come here thinking they're going to make money. Mining is not a profitable business, but as a hobby, where else can you buy computer hardware for a hobby that partially pays itself off? Most people think however they're going to magically recoup the costs of the hardware and then make bucketloads more when it's not remotely like that. I've been trying to warn people of it for ... well years now since I maintain mining software but people stopped listening a long time ago, convinced through some magic of the value of BTC rising that they'll make money.

There is one indisputable fact that people spend far too much energy trying to disprove by explaining it through value of exchange changing.

FACT: You cannot buy any bitcoin mining hardware that mines more bitcoin in the future than the amount of bitcoin you would have by simply converting dollars into bitcoin now.

The only way you can make a profit with mining hardware is to buy it, mine with it for a bit, and then sell it.

The principle behind the optimisation I understood, but the timeframe sounds like there's something fundamentally wrong. It should only take milliseconds for bitcoind to be able to generate a new template. I've never looked at the code so now I'm just speculating, but I can't imagine why it would take that long. It's not that complicated a workload for a modern CPU. Does it need some kind of confirmation from other nodes?

Yes, but only admins, not moderators. They can see all edits and deletions and all history.

I wasn't, I honestly thought that's what you were referring to because I had no idea bitcoind was too slow to generate a new set of transactions after you've submitted a block to it that would delay you sending out new work based on it.

Interesting. I know eligius has always chosen its own transactions to include when mining but I didn't realise you thought the default choices of the bitcoind client were so bad as to call them spam.

Then you need technical support with the bitcoin client, not mining support.