Author

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

legendary
Activity: 1386
Merit: 1097
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

Inaba, why so aggressive? I never meet you on #stratum channel, so I'm bit surprised with your sudden interest in "proper design" of the protocol.

Did you read https://bitcointalksearch.org/topic/m.1344456 ? AFAIK it fixes all previous problems with difficulty manipulation. I also didn't read any opinion to this by you, so I suppose you agree on this change. All existing miner software (cgminer, poclbm, proxy, I expect that bfgminer as well as it is derived from cgminer) is already compatible with this change, so feel free to implement it on your pool.

I only need to change documentation to cover this change. If we ever have days with 25 hours...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
To be clear, again I agree difficulty should be tied in with work on stratum instead of the current implementation. However pools can do a lot to alleviating the harm that has by tolerating a certain amount of hysteresis before retargetting diff. I'm sure emc can be tweaked some more with this in mind.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
Excuse me but 99.99% of the stratum code in bfgminer is from cgminer
Yes, but as with other code that BFGMiner inherited from cgminer, I've caused numerous bugs in the minor changes I've made.
You see - that's the correct version.

Please at least understand what you are talking about before making ludicrous posts that show how stupid you are.

This is the third time in here recently you've made posts that make you seem like a simpleton.
Here's two more:
https://bitcointalksearch.org/topic/m.1342045
https://bitcointalksearch.org/topic/m.1349309

You just post crap and never back up anything you say - and it is simply that - crap.
Coz you can't back it up.

There is a known issue with Stratum (that I brought up) that if you change difficulty, then the miner will lose a very small number of shares.
If you change it often, then of course that number increases.
Yes, this is my main issue with Stratum that I have brought up all over the place - feel free to copy me and help me get slush to accept the change.
But while your at it - at least understand what the fuck you are talking about Tongue

When I mine on OzCoin with Stratum I set difficulty fixed at 8 diff so there are no difficulty changes.
Works well.
Some days I only get a single Reject in 24 hours ...

--

There are also well known issues with GBT that you have been clearly explained.
Go fix them.
But no, your head is so far up your arse you don't hear anything anyone says.

Seriously (as I have said before) I wouldn't mind if there were 2 new competing protocols.
But at the moment there aren't - there's only one: Stratum - the other one is not worth considering.
legendary
Activity: 952
Merit: 1000
"Acknowledged" by whom?
who specifically is "everyone involved"?

My personal mining numbers show the opposite as shown on the pools actual websites. The only magical POOF I'm seeing is the end of that cool aid you've been sipping on.
Read thru this thread: https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533
legendary
Activity: 1260
Merit: 1000
"Everone invloved" would be Conman, Kano, Luke, Slush, myself and pretty much anyone who has anything to do with development and implementation of Stratum.  What is your authority to make a claim?

Of course you aren't seeing the poof, because it shows up as a rejected share when it shouldn't be.  But how would you know?
hero member
Activity: 988
Merit: 1000
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?

"Acknowledged" by whom?
who specifically is "everyone involved"?

My personal mining numbers show the opposite as shown on the pools actual websites. The only magical POOF I'm seeing is the end of that cool aid you've been sipping on.
legendary
Activity: 2576
Merit: 1186
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
Excuse me but 99.99% of the stratum code in bfgminer is from cgminer
Yes, but as with other code that BFGMiner inherited from cgminer, I've fixed numerous bugs in it.
legendary
Activity: 1260
Merit: 1000
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?


Excuse me but 99.99% of the stratum code in bfgminer is from cgminer

I'm not sure what that has to do with the fact that it works though? The problem is not with the Stratum code, it's with the Stratum protocol.  It's broken.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right.  EMC's implementation will NEVER throw away valid work.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?


Excuse me but 99.99% of the stratum code in bfgminer is from cgminer
legendary
Activity: 1260
Merit: 1000
No, it's an acknowledged problem with Stratum.  The original Stratum design is flawed.  Difficulty is decoupled from work and that is simply an incorrect way to handle mining.  Difficulty and work are inseparable from a mining perspective.  The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.

My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.

I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right because of the flawed difficulty design of Stratum.  So tell me which would you prefer?  Shares going POOF magically on your Stratum server of choice or you getting paid for your work?

hero member
Activity: 988
Merit: 1000
The semi-official Bitcoin Pool Comparison Chart only shows 2 stratum pools, BTCGuild and Slush's.  Are there others?
Most pools are in the process of implementing it. Of the other ones that already have it, ozcoin is my favourite, but emc also does it (though with too unstable a variable difficulty IMO).

Come on now, lets be honest.  The variable difficulty isn't the problem here, Stratum is the problem: it's difficulty to work relation is broken from the ground up and needs to be fixed.  If the difficulty were too unstable, why can GW and GBT keep up just fine?  CGminer doesn't seem to have any trouble keeping up with it in GW, right?



Seems to be your implementation of variable difficulty with stratum. It works fine on all the other implementations that were not influenced by GBT.
hero member
Activity: 988
Merit: 1000
The semi-official Bitcoin Pool Comparison Chart only shows 2 stratum pools, BTCGuild and Slush's.  Are there others?
Most pools are in the process of implementing it. Of the other ones that already have it, ozcoin is my favourite, but emc also does it (though with too unstable a variable difficulty IMO).

Come on now, lets be honest.  The variable difficulty isn't the problem here, Stratum is the problem: it's difficulty to work relation is broken from the ground up and needs to be fixed.  If the difficulty were too unstable, why can GW and GBT keep up just fine?  CGminer doesn't seem to have any trouble keeping up with it in GW, right?


stratum and variable difficulty are 2 different pieces of code
Ozcoin implemented stratum then coded the vardiff- not sure what you consider "broken" but we have it working fine, maybe the vardiff you coded before implementing stratum is the issue?

The implementation of stratum and vardiff on OZCO is running flawlessly with cgminer
vip
Activity: 980
Merit: 1001
The semi-official Bitcoin Pool Comparison Chart only shows 2 stratum pools, BTCGuild and Slush's.  Are there others?
Most pools are in the process of implementing it. Of the other ones that already have it, ozcoin is my favourite, but emc also does it (though with too unstable a variable difficulty IMO).

Come on now, lets be honest.  The variable difficulty isn't the problem here, Stratum is the problem: it's difficulty to work relation is broken from the ground up and needs to be fixed.  If the difficulty were too unstable, why can GW and GBT keep up just fine?  CGminer doesn't seem to have any trouble keeping up with it in GW, right?


stratum and variable difficulty are 2 different pieces of code
Ozcoin implemented stratum then coded the vardiff- not sure what you consider "broken" but we have it working fine, maybe the vardiff you coded before implementing stratum is the issue?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
cut/paste ...

2.9.5
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.9.5a
https://github.com/kanoi/cgminer/downloads
(it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my '2xGPU' or 'BFL+2xICA' (90 minutes so far)
GPUs (687Mh/s) on solo and BFL+ICAs (1.6GH/s) on OzCoin Stratum with fixed 8 diff
(MMQ is doing new code testing)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make


--

(and yes I made a 2.9.4a but didn't post about it)

--

sharky112065's post above is actually (indirectly) about ASIC.

I've rewritten the MMQ driver (as I've said a few times) and the problems with windows drivers included a problem with libusbx so I switched to libusb (thanks for help from the libusb developer) and the last problem was gone.
So when I finally get my changes into the main git - we need to use libusb not libusbx on windows.
Those changes include early code for the up coming ASICs.
sr. member
Activity: 383
Merit: 250
New Windows build instructions.

http://pastebin.com/3pzivj32

Can someone with a Windows rig that has a Ztex test the new libusb section?
Need to know if you can mine successfully using libusb instead of libusbx because that is what cgminer will be going to in the future supposedly.
legendary
Activity: 916
Merit: 1003
There ya go!  Thanks, it works now.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
The auto-gpu switch is no longer recognized.
I assume you mean on windows? I may have built it without adl support, lemme check

EDIT: yes my fault. Repackaged the windows binaries. Try redownloading.
legendary
Activity: 916
Merit: 1003
The auto-gpu switch is no longer recognized.
hero member
Activity: 497
Merit: 500
Thanks once again for all your hard work. I will send a donation tomorrow when I get back to my wallet!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New release - 2.9.5, 25th November 2012

Bugfix release.


Human readable changelog:

Fixed the crash when a GBT pool was used either as primary or backup when its gbt coinbase was very large.
Fixed the ztex submits lots of dupes bug based on an idea by luke-jr
Fixed the much larger amount of shares being leaked to backup pools
"getworks" will not be counted now from backup pools when they're just being used to see the pool is alive
Mips openwrt fixes


Full changelog:

- fixes target calc for mips openwrt
- openwrt needs roundl
- Get rid of unused last_work in opencl thread data.
- Do away with the flaky free_work api in the driver code which would often lose
the work data in opencl and simply flush it before exiting the opencl scanhash.
- Use base_work for comparison just for cleanness in __copy_work
- Remove all static work structs, using the make and free functions.
- Add pool no. to stale share detected message.
- Add info about which pool share became stale while resubmitting.
- Copy the work on opencl_free_work
- Add an extra slot in the max backlog for ztex to minimise dupes.
- Do not use or count the getworks submitted which are simply testing that pools
are still up. This was increasing share leakage and making stats not reflect
real work.
- Track all dynamically allocated memory within the work struct by copying work
structs in a common place, creating freshly allocated heap ram for all arrays
within the copied struct. Clear all work structs from the same place to ensure
memory does not leak from arrays within the struct. Convert the gbt coinbase and
stratum strings within the work struct to heap ram. This will allow arbitrary
lengths without an upper limit for the strings, preventing the overflows that
happen with GBT.
- libztex: Work around ZTEX USB firmware bug exposed by the FreeBSD libusb
- opencl: Use new dev_error function for REASON_DEV_NOSTART
Jump to: