Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 406. (Read 5805537 times)

Couldn't you cut down on rejects by having cgminer immediately start working on shares for the pool that sends out new work before the other ones?

When spreading shares out to multiple pools it is guaranteed your reject rate will be higher because every pool has a slightly different time they see the block change. How to best manage that is a point of contention. It was far more useful for shares to "leak" with the old getwork protocol because it would be common one pool could not keep up the work for all miners especially across longpoll. I do recall one lucky user in this thread had shares leak to his local bitcoind and actually found a block with one of those! Since stratum (and gbt) use completely local work generation, there is not much point to this any more.

If you use miner.php, you can see how many shares you've sent to each pool really easily.

I tried balancing 3 servers (us.ozco.in, stratum.ozco.in and MtRed's stratum server) and got decent results, but my reject rate was slightly higher across the board; about 0.2% rather than 0.1%. MtRed was also getting quite a bit more shares (hence why I added 2 Ozcoin servers), probably something to do with the server only sending out new work about once a minute. I wonder if there's really any benefits to balancing DGM and PPS...

So I'm testing it out by running my 7970 on 5 stratum pools using balance. At the top, its says "Connected to multiple pools without LP", which I take to be a good thing, as all the pools are using Stratum. My question is how to look at the number of accepted shares for each individual pool, without pressing "P -> I -> 0" and going on thru the line. Is there a pool summary page where I can compare the submitted shares too all pools?

I build cgminer 2.10.4 on my MK802, which is also an ARM CPU. It's exactly the same steps as building from source on almost any other version of Linux, and the steps are in the CGMiner readme if you need a refresher.

So i can start this as if i were on any linux machine? In Pshep's cgminer port the program runs as a service and thats why I'm asking ?

Ok, thanks. First time I'm going to compile something for an AllWinner A10 (ARMv7 apparently). Does it differ a lot from a 32bit x86 compile process?

There are no 32 bit linux binaries, so yes you do have to compile them.

./cgminer-2.10.5 --no-submit-stale --api-listen --api-allow W:127.0.0.1,R:192.168.0.0/24

Hello,
I have a Hackberry (ARMHF) Allwinner A10 dev board.
Where can I find the 32bit binaries of cgminer? Do I have to compile them for ubuntu 12.10, likely 32bit, if these don't exist?

Someone here that has cgminer on a ddwrt?

I'm unable how to start cgminer with the flags "--api-listen and --api-network".
Normal starting procedure looks like this "service cgminer start"....

Where do i put these flags?

+1 

That was great writing Con. I now understand some things I've been seeing from time to time.

Perfectly clear. Thanks one million.

Stratum always starts at diff 1, even if you have asked for a different diff. So cgminer starts sending diff 1 shares until it is told to change diffs, and even then, if there are any shares that it has already found, it still submits them. The stratum protocol specifies that these should be valid shares and accepted if submitted with the original work item. Now cgminer does NOT log shares submitted at the time they're submitted, unless you're in verbose mode. It only shows the response from pool when it accepts or rejects the share submitted. Otherwise it would have to show them twice. Instead it keeps a database of shares submitted and waits till it gets a response before saying accepted or rejected. If the share has been submitted, and the pool never responds to it, you will never see any record of it. If a connection is dropped, cgminer discards all recollection of old shares submitted and considers them lost, because most of those shares will be lost somewhere in networking, and the pool will not accept shares from old connections until stratum develops a robust resume mechanism (which I'm trying to push forward at the moment). If any shares come back from the old connection as accepted or rejected, cgminer will call them "untracked shares" because it will have discarded any record of them.

Thanks for your quick reply.

Sorry to bother you. Since I don't know anything about the protocol and about your code, let me know whether I understand correctly (so I will contact HHTT and I will be able to explain better the issue): that nonce isn't real, is it? Cgminer never found it and never sent it: it is faked by HHTT.
Otherwise I don't understand why cgminer didn't log it.

Thanks again.

Sounds to me like a HHTT stratum implementation issue rather than anything else.

64 bit ming (the cross platform tools used to make windows binaries from linuxy software) is subtly broken for starters, it uses more ram than the 32 bit binaries, and it actually provides precisely zero benefit. So if anything, you're better off with the 32 bit binaries.

I've noticed a strange behaviour. Perhaps, in some circumstances, some shares are sent to the wrong pool.

Please look at my cgminer log:

Where has that share gone?

HHTT pool log says:

BTW: 9:58 on my log, 8:58 on HHTT log. That's correct, there's one hour difference.

This is why i've been able to notice it: only 999 (and above) difficulty shares should go to HHTT, and 00000000 faacb474 815f8e93 of course has a much lower difficulty. It shouldn't have gone there: most probably that nonce had been generated for Deepbit, I think, but in the meantime cgminer switched back to HHTT, so somehow the share was sent to  HHTT. It's strange, too, that cgminer never logged that nonce (I mean, it never said: "... Rejected faacb474..."):

From time to time, I have some of these "H-not-zero" hashes on HHTT logs. This has been happening since HHTT switched to stratum. I never saw an "H-not-zero" before. My only other stratum pool is slush: but slush doesn't show a log of all received shares: so I cannot know if this same behaviour is common to slush too.

I'm a bit concerned: if a 1 difficulty share goes to the wrong pool, who cares? But if one of my 999 difficulty shares goes to the wrong pool (let's say it goes to slush instead of going to HHTT, while cgminer is switching between these two pools), I'd be surely pretty sad.

Thanks.

Is there somewhere a Windows 64bit binary available?
Or does it not make very much difference if I am running the 32-bit executable on 64 bit ?

Please report back your findings/experience/opinion.