OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 766.

DBordello

sr. member

Activity: 349

Merit: 250

BTCPak.com - Exchange your Bitcoins for MP!

Quote from: Luke-Jr on September 27, 2011, 11:07:33 AM

Quote from: DBordello on September 27, 2011, 10:50:26 AM

I just installed 2.0.5 from git, running smoothly as always.

I guess that I will start the features-for-donations requests:

1) The ability to pause/unpause mining. Ideally this would be easily done by another program (without sending keystrokes). I am thinking perhaps a SIGINT or SIGCONT could stop and start mining respectively.

I recently switched to hourly based electricity pricing and plan on evaluating the feasibility of mining every hour. That is what inspires this request to be able to pause mining during peak electricity demand.

Thoughts?

SIGSTOP/SIGCONT don't work?

Perhaps my limited knowledge of signals misinterpreted them. I thought that it was up to the program to choose what to do when they got those. Perhaps the are the wrong mechanisms for communicating with the process. I am running cgminer in screen, if it receives SIGSTOP, screen (I believe) restarts it.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DBordello on September 27, 2011, 10:50:26 AM

I just installed 2.0.5 from git, running smoothly as always.

I guess that I will start the features-for-donations requests:

1) The ability to pause/unpause mining. Ideally this would be easily done by another program (without sending keystrokes). I am thinking perhaps a SIGINT or SIGCONT could stop and start mining respectively.

I recently switched to hourly based electricity pricing and plan on evaluating the feasibility of mining every hour. That is what inspires this request to be able to pause mining during peak electricity demand.

Thoughts?

SIGSTOP/SIGCONT don't work?

DBordello

sr. member

Activity: 349

Merit: 250

BTCPak.com - Exchange your Bitcoins for MP!

I just installed 2.0.5 from git, running smoothly as always.

I guess that I will start the features-for-donations requests:

1) The ability to pause/unpause mining. Ideally this would be easily done by another program (without sending keystrokes). I am thinking perhaps a SIGINT or SIGCONT could stop and start mining respectively.

I recently switched to hourly based electricity pricing and plan on evaluating the feasibility of mining every hour. That is what inspires this request to be able to pause mining during peak electricity demand.

Thoughts?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

New version: 2.0.5 Grin

Links in top post. The linux binary archive also includes a cpuonly binary.

- Intensity can now be set to dynamic or static values per-device.
- New donation feature --donation sends a proportion of shares to author's
account of choice, but is disabled by default!
- The hash being displayed and block detection has been fixed.
- Devices not being mined on will not attempt to be ADL managed.
- Intensity is now displayed per GPU device.
- Make longpoll attempt to restart as often as opt_retries specifies.
- We weren't rolling work as often as we could.
- Correct some memory management issues.
- Build fixes.
- Don't mess with GPUs if we don't have them.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Thank you for the bug reports Wink

ancow

full member

Activity: 373

Merit: 100

The last couple of commits fixed these, thanks.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

ancow

full member

Activity: 373

Merit: 100

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: iopq on September 26, 2011, 04:31:40 PM

Quote from: -ck on September 26, 2011, 02:38:45 AM

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

iopq

hero member

Activity: 658

Merit: 500

Quote from: -ck on September 26, 2011, 02:38:45 AM

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

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

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.

Sp0tter

sr. member

Activity: 285

Merit: 250

Quote from: -ck on September 26, 2011, 03:26:59 AM

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

DutchBrat

hero member

Activity: 868

Merit: 1000

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

DavinciJ15

hero member

Activity: 780

Merit: 510

Bitcoin - helping to end bankster enslavement.

Quote from: -ck on September 26, 2011, 12:33:51 AM

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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.

flower1024

legendary

Activity: 1428

Merit: 1000

Quote from: -ck on September 26, 2011, 03:26:59 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

flower1024

legendary

Activity: 1428

Merit: 1000

Quote from: -ck on September 26, 2011, 02:38:45 AM

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?

shads

sr. member

Activity: 266

Merit: 254

Quote from: -ck on September 26, 2011, 12:33:51 AM

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.

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