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

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.

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.

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.

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.

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

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

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 think this is a great idea.

I think it's a good idea it's easier for you to receive revenue you can count out the major miners however you should do a pole and see what number will maximize your revenue.  Also include in the pole the donation amount of zero so you can count those people out.

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.

Regards

Davinci

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.

Yes I haven't put anything explicitly in place separating out management of GPUs from the cards only being mined on. I have to fix that.

Windows 7
catalyst 11.9 RC (with corresponding SDK, produced no CPU use or very little with other miners, but i had to put the 4650 back on my pc for the issues i had while gaming)

I tried the following:


That seemed to work fine (those are the same settings i use with other miners, my 5830 runs @50 to 52 c).

It did crash my pc once when i closed cgmine's window (i started using Q to quit from there on).

Then i decided to try to take advantage of the auto fan modes, and i went with:


I specified the fan speeds manually, even for the 4650 because if i did not, its fans would go to 100% (or 85% maybe).

Another thing i noticed was that my 5830 would use its fans always on the upper limit (i originally set it from 20 to 75 and the noise difference was there).

Using the auto modes, my pc surely crashes really fast.

rcocchiararo, what OS, SDK and driver are you using? what flags?

this miner made me happy for a short time, it uses little or no cpu xD

it might even give me a few more MHAshes

What bothers me, at least on my main (desktop) rig, is that i have 2 cards:

hd5800
hd4650

I must keep BOTH because my main display is a 27 inches DELL rocking 2560x1440 pixels, and for SOME reason (and i tested 3 different 5800, both with dual link DVI and mini displayport cables), if i also connect my secondary display (20 inches Dell display), i get weird lines on the 27 inches one while playing, and the screen even goes black from time to time, randomly.

Having one display on each card causes no issues (both displays on the 4650 have the same problems).

All this problems happen more often while gaming.

------------

Now, to my issue with this great miner:

even if i set -d 0, it seems the app decides to try to use/overclock/control the fans of my 4650 ( i want its fans to remain on AUTOmatic, and its clocks untouched, its just there to power my secondary display, not gaiming, not mining).

If i set its fan to a fixed speed, my PC BSODS

Works for me.

For kano: Luke-Jr forbid mirroring in the ebuild, that's a way to abide by the "always download from AMD" as long as the license doesn't require the user to download manually. This way Gentoo doesn't host the file on its mirrors and Gentoo users don't try to download the file from them. So the install was fully automated for me.

Added a simple ebuild for dev-util/amd-adl-sdk to the bitcoin overlay. Please test. (no manual downloading required)

Yes thanks that's what I meant
You will have to actually get them yourself from AMD you can't have them provided by any other source.

That's not a problem for Gentoo. It supports software like that by allowing the users to download the original package themselves (you put the file in /usr/portage/distfiles by default before installing) and can ask the user to agree to a license if it's mandatory. The rest of the process (actual install, lib and config maintenance, keeping track of files installed, ... is still done by the package manager).

Thankfully, I don't need a license to write an ebuild.

Ever heard of the term foot-in-mouth?
AMD-APP-SDK-v2.4-lnx64/docs/opencl/LICENSES

Edit: (and if you want the specific ADL version: ADL_SDK_3.0/Public-Documents/ADL SDK EULA.pdf )