Bitcoin Forum
December 03, 2016, 03:52:57 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 [82] 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4815255 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
September 25, 2011, 11:47:57 PM
 #1621

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).
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
September 26, 2011, 01:38:09 AM
 #1622

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
September 26, 2011, 05:33:51 AM
 #1623

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
September 26, 2011, 07:18:50 AM
 #1624

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.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
September 26, 2011, 07:29:32 AM
 #1625

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.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
September 26, 2011, 07:38:45 AM
 #1626

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
September 26, 2011, 07:49:15 AM
 #1627

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.

PoolServerJ Home Page - High performance java mining pool engine

1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq - http://payb.tc/shads

Quote from: Matthew N. Wright
Stop wasting the internet.
flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
September 26, 2011, 07:55:52 AM
 #1628

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
September 26, 2011, 08:26:59 AM
 #1629

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  Tongue

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  Undecided 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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
September 26, 2011, 08:44:01 AM
 #1630

...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  Undecided 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
Legendary
*
Offline Offline

Activity: 2086



View Profile
September 26, 2011, 12:24:53 PM
 #1631

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
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
September 26, 2011, 01:58:18 PM
 #1632

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
Hero Member
*****
Offline Offline

Activity: 868


View Profile
September 26, 2011, 03:51:22 PM
 #1633

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  Wink

Brat
Sp0tter
Sr. Member
****
Offline Offline

Activity: 285


View Profile
September 26, 2011, 05:29:30 PM
 #1634

..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  Undecided 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.


http://allchains.info - First to provide difficulty estimates for forks.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
September 26, 2011, 06:44:19 PM
 #1635

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
Hero Member
*****
Offline Offline

Activity: 644


View Profile
September 26, 2011, 09:31:40 PM
 #1636

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
September 26, 2011, 09:51:12 PM
 #1637

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 Sad" if disabled) somewhere, and do his % last (ie, if donating 0.5%, do his work after 199 of theirs).

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
September 26, 2011, 10:30:45 PM
 #1638

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 Cheesy

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

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
September 27, 2011, 04:04:57 AM
 #1639

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:
Quote
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)

Quote
[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.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
September 27, 2011, 04:11:23 AM
 #1640

Thanks. For some reason some printfs seem to interpret %% as some kind of control character instead of showing percent  Angry. 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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 [82] 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!