OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[The00Dustin]

I asked a few posts ago if you could change something in your code, I'm not asking you to agree just an answer and your opinion if you don't mind giving it.

I got lost in the angry discussions following it. Was it the IP address issues, the working with a proxy server, the requiring built-in support for merged mining, the mining on multiple block chains, your one pool that doesn't like cgminer, or something else? In summary I'm not abject to fixing issues, but I don't work around unique pool designs and will never support multiple different block chains (that's not the same as merged mining, I know). That leaves the others up to discussion.

I'm pretty sure he only requested that you latch on to an IP because he is trying to use round-robin DNS.  I subsequently suggested a possible alternative that might work even better.  I would argue that round-robin DNS isn't a pool issue, but someone pointed out that his servers should be communicating amongst themselves to know what work has been handed out / returned so that it wouldn't matter.  I guess whether the issue lies with cgminer or PoolServerJ is really subjective, though I believe it is typical for any type of client to latch onto a specific IP and not bounce around 'mongst those listed as available in DNS where ther eis no connectivity issue.  I could be wrong about that, but I have certainly had plenty of negative non-mining experiences from proxies that don't latch onto an IP address (in both the source and destination senses).

[1715367241]

1715367241

[1715367241]

1715367241

[1715367241]

1715367241

[1715367241]

1715367241

[1715367241]

1715367241

[DavinciJ15]

I asked a few posts ago if you could change something in your code, I'm not asking you to agree just an answer and your opinion if you don't mind giving it.

I got lost in the angry discussions following it. Was it the IP address issues, the working with a proxy server, the requiring built-in support for merged mining, the mining on multiple block chains, your one pool that doesn't like cgminer, or something else? In summary I'm not abject to fixing issues, but I don't work around unique pool designs and will never support multiple different block chains (that's not the same as merged mining, I know). That leaves the others up to discussion.

The issue was not multi block chains and had nothing to do with that at all, merge mining works with no change to miner code.  The argument spiraled out of control and it was hard for anyone to understand what I was asking for after people jumped in yelling at me for a request I did not ask for as if I committed a immoral crime.  With that said what I am asking for is unique to my pool but would help other pools and mining in general.  My objective is to make it easy for anyone to create a mining pool thus ensuring the survival of bitcoin with choices.  In the end I can should you choose not to change your code I will fix it on my side however it would be more effective and efficient for miners to change it.

Allow me to explain again...

I have designed my pool around clustering small PCs together instead of having one or 2 large ones.  This significantly reduces cost of entry and thus allowing for more pools to come into the space.  I can afford a large server, I can afford to do it the same way everyone else is doing it but I wanted to do something different and this is not the main feature of my enhancements to pool operations but one of them.

Thus the issue is with clustering many servers together, one of the ways to access multiple servers is round robin.  However with hashing all request to hash data must go back to the same server or the work load must be shared.  As far as I can tell shared work data is effective for a larger pool but not for smaller ones starting off.  Thus easiest method is for round robin to work is for each miner to stick to an IP address until there is a problem.  Poclbm does this already so no changes are need for that miner software.

Now my plan if I am unable to convince you to make the change is to create a balancer based on user name this will work in 98% of the cases except when someone uses the same username for all of their miners.  

But that will have to do if I'm unable to convince you of the merits of changing the software to support round robin DNS servers.

Whatever you choose to do thanks for taking the time to consider it.

Best Regards

Davinci

[-ck]

I've considered your request and believe that the responsibility should, unfortunately, rely with the proxy software. cgminer is simply given a url and works with that. Resolving the IP address per work item has the potential to actually be quite slow. As far as I'm aware, some big pools use a round robin system of their own without problems.

[gyverlb]

I've considered your request and believe that the responsibility should, unfortunately, rely with the proxy software. cgminer is simply given a url and works with that. Resolving the IP address per work item has the potential to actually be quite slow. As far as I'm aware, some big pools use a round robin system of their own without problems.

From a pure architecture standpoint, I'm not so sure the responsibility should rely with the server side. It's very hard to bring redundancy to the server side when it has to maintain clients' states (in this case the link between submitted shares and getwork requests if I understand correctly). It's usually far more robust if the client handles the redundant part itself because in many cases it's usually simpler to code it there.

From what I understand of your answer, for simplicity the code links DNS resolution and HTTP connection in one single step. Most "heavy" HTTP clients (by heavy I mean programs that have to establish many connections to a single service with a decent level of interactivity, like web browsers or http proxies) usually separate the two and maintain a reputation for each IP in a local cache (see Squid's code for example).

It probably would need a significant level of refactoring though so I understand your reluctance to code it for one single pool.
Each pool -> one list of IP addresses with [ availability, DNS expiration time ]. Don't try to getwork from unavailable IPs. A getwork is linked to the IP not the pool. If a share can't be submitted to an IP, try another one (in case the pool supports sharing client's state between servers) once. These "pool -> ip set" may be refreshed by a separate thread looking for IPs about to expire and unavailable IPs to check if they come back to life.
This may only scratch the surface of the refactoring but it's more or less how HTTP client code deals with the problem...

One simpler way is to avoid all this IP reputation refactoring and simply link a getwork response with the IP address it came from in addition to the pool and submit shares to this IP (and other IPs of the pool if the initial submit fails). It would work at the expense of more failed connections when a pool has lost one of its IPs.

[gyverlb]

Quite a number of people have suggested to me adding a donation option to cgminer as an opt-out feature. This would redirect a nominal amount of shares, say 0.5% to myself, which could be disabled on the command line. I've been resisting taking such an approach, but how do other people feel about that? It would certainly make me happier to keep supporting this project.

Hum, I'd prefer opt-in or even no donation option for several reasons :
- I prefer to donate directly (as I already did),
- I assume you'll have to make cgminer connect to a specific pool and I don't like having connections to a server being done by default by a soft when it's not needed,
- It probably won't be good for cgminer's reputation and may deter new users from trying it.

[-ck]

I would not make donation mandatory. The intent would be for --donate 0 to be no donation. Human nature tends to accept defaults, and if I set zero by default, I'd say no one will donate. On the other hand, I don't like forcing people to donate by making the default on. So I'm torn on this issue too.

[shads]

I've considered your request and believe that the responsibility should, unfortunately, rely with the proxy software. cgminer is simply given a url and works with that. Resolving the IP address per work item has the potential to actually be quite slow. As far as I'm aware, some big pools use a round robin system of their own without problems.

Implementing the sharing of delivered work between servers would be non-trivial and error prone not to mention adding significant extra load to the most stretched resource in the chain.  I'm not aware of any round-robin DNS load sharing in big pools (not to say there isn't any).  Load balancing that handles the stickyness at the load balancer is probably the best pool side solution but the load balancer needs to have a lot more grunt than a round robin DNS server.  From the miner side the simplest solution would be to simply respect the TTL of the DNS response and the pool op can set a long TTL.  Doesn't give as much realtime adaptability as a short TTL but neither would client side stickyness.

[flower1024]

I would not make donation mandatory. The intent would be for --donate 0 to be no donation. Human nature tends to accept defaults, and if I set zero by default, I'd say no one will donate. On the other hand, I don't like forcing people to donate by making the default on. So I'm torn on this issue too.

what do you think about this solution:

if parameter is specified you take its value (obvious)

if its not supplied you just ask the user when cgminer starts (as you do with pool url)

btw: which pool do you hardcode? i dont like the idea very much about a direct share donation.
will it affect reject count if the donation pool rejects a share?

[-ck]

That's not a bad idea as a way of notifying people, but it could easily appear to be nagware. I'm thinking that anything I do no matter what will be criticised so fuck it, I'll just make it opt-in by setting the default to 0. Likely I'll earn maybe 1BTC from doing this in the next decade, but at least I'll give people the option. It wasn't even my idea in the first place so those who suggested it hopefully will use it 

As for its effect on your statistics, the locally visible accepted/reject rate will include any donated shares, but it will have absolutely no effect on your statistics with your own server since it will be separate. My plan was to query my own server for login credentials and then use those, in case conditions change in the future, but for now I was planning on using ozcoin. The only issue is it will only work on bitcoin, since the block chain has to match.


...On the other hand I could just forget it. These are the issues I didn't want to have to tackle and it's starting to piss me off dealing with them  At least if I don't get any donations I don't feel obliged to do stuff. The time I dedicated to developing this miner was extreme, and I no longer have that much spare time to dedicate.

[flower1024]

...On the other hand I could just forget it. These are the issues I didn't want to have to tackle and it's starting to piss me off dealing with them   At least if I don't get any donations I don't feel obliged to do stuff. The time I dedicated to developing this miner was extreme, and I no longer have that much spare time to dedicate.

+1
when i come home you'll get another 1BTC (i dont have much hash so this is probably more that i would ever donate through your miner)

EDIT: sent http://blockexplorer.com/tx/c420c9aefe5892590d0ae89b67e306cbb60a634904755f0c830cce97c29da2d4

[Luke-Jr]

I agree there are optimizations that could be made by reusing the getwork HTTP connection for subsequent share submissions, but it is also a server bug if it can't handle clients changing to another IP on the same DNS entry. There are header-based getwork extensions to allow pools to control where future getworks go (either failover or "please change to this server _now_") that CGminer might (or might not) implement.

[DavinciJ15]

I've considered your request and believe that the responsibility should, unfortunately, rely with the proxy software. cgminer is simply given a url and works with that. Resolving the IP address per work item has the potential to actually be quite slow. As far as I'm aware, some big pools use a round robin system of their own without problems.

Thanks for taking the time to consider my request.  Should you change you mind please PM me with details.

Regards

Davinci

[DutchBrat]

Ckolivas,

Thanks for your superb miner !

I mined at Davinci's pool (http://nmcbit.com) for days on end with stales less then 0.25% (also Kudos to Davinci for getting his pool optimized of course +1)

I just sent you 1.62658754 BTC as a small thank you

It will be worth more when BTC is back above $30 

Brat

[Sp0tter]

..On the other hand I could just forget it. These are the issues I didn't want to have to tackle and it's starting to piss me off dealing with them  At least if I don't get any donations I don't feel obliged to do stuff. The time I dedicated to developing this miner was extreme, and I no longer have that much spare time to dedicate.

This sounds like the best idea.   I don't think most people want extra code/features like auto donations.  Its simple to donate to your address provided by sending btc.  Adding  in donations (default on or not) into the miner is not a good idea.

[DeathAndTaxes]

An alternative I might suggest to auto-donation is a bitcoin poll.

Generate say 5 new bitcoin addresses (never been used for anything 0BTC balance).   Then come up to with some ideas for improvement/enhancement (maybe ask the forum for suggestions).

Let people "vote" with their donated bitcoins.

Something like.

What feature/bug should be implemented/fixed next:
option 1 - donate to 1E3kqtQQr4L7dcp5M2ynBGbovsKj7fmZhd
option 2 - donate to 1P3kqtJQr4L7M28M2ynBGbovsKj7fdmZhd
...
option 5 - donate to 1E3kqZZZ38jf0F99fM2ynBGbovsKj7fmZhd

I someone wants to suggest something different let them for a 2BTC donate.

You get to see which direction your community wants to go.
You get more donations.
Donators get to feel like they have some say in direction of the software.

Win-win-win.

[iopq]

I would not make donation mandatory. The intent would be for --donate 0 to be no donation. Human nature tends to accept defaults, and if I set zero by default, I'd say no one will donate. On the other hand, I don't like forcing people to donate by making the default on. So I'm torn on this issue too.

people also don't like upgrading and finding out they're donating because they didn't read the forum and have to add extra shit to the command line

[Luke-Jr]

I would not make donation mandatory. The intent would be for --donate 0 to be no donation. Human nature tends to accept defaults, and if I set zero by default, I'd say no one will donate. On the other hand, I don't like forcing people to donate by making the default on. So I'm torn on this issue too.

people also don't like upgrading and finding out they're donating because they didn't read the forum and have to add extra shit to the command line

So he can put a UI element "Thanks for your N% donation" (or "Please donate " if disabled) somewhere, and do his % last (ie, if donating 0.5%, do his work after 199 of theirs).

[-ck]

Thanks guys! Nothing like threatening to make donation part of the code to bring out the donations! I haven't seen this many donations in a while

I really like the "vote with a donation" idea, that's awesome   However pretty much every feature that I'm interested in implementing has been done

Anyway adding the donation "feature" isn't that hard, and some people have expressed that they would use it, so I will include it next version, but after much consideration I've decided that it will default to 0.0

EDIT: The --donation feature is now in the git tree.

[ancow]

I'm not sure whether this is just because of some intermediate state, but since this code hasn't changed in a few hours, two bugs with the latest version from git:

GPU 0: 0.0 / 0.0 Mh/s | A:0  R:0  HW:0  U:0.00/m
60.0 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 97% P: 0%
Last initialised: [2011-09-27 05:42:45]
Intensity: Dynamic
Thread 0: 0.0 Mh/s Enabled ALIVE
Thread 1: 0.0 Mh/s Enabled ALIVE

Since my command line was

Code:

cgminer -c path/to/config -I -1

I would expect this to be initialised to -1. (Mh/s confirms this is set to dynamic)

[E]nable [D]isable [ I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
Set GPU scan intensity (d or -10 -> 10):
-1
Intensity on gpu 0 set to -1
GPU 0: 0.0 / 0.0 Mh/s | A:0  R:0  HW:0  U:0.00/m
59.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 98% P: 0%
Last initialised: [2011-09-27 05:42:45]
Intensity: 4294967295
Thread 0: 0.0 Mh/s Enabled ALIVE
Thread 1: 0.0 Mh/s Enabled ALIVE

[E]nable [D]isable [ I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue

Seems like a display bug, Mh/s is appropriate for this intensity.


Also, since intensity is now per-GPU and at least my GPU stats line has quite some space in it, could you add it there?

Edit: setting intensity on the command line seems to be completely ignored.

[-ck]

Thanks. For some reason some printfs seem to interpret %% as some kind of control character instead of showing percent  . That was meant to be a fan percentage. I'll investigate further ... sigh. The random different interpretations of apparently portable code never ceases to amaze me with its level of fail.