Bitcoin Forum
March 19, 2024, 06:16:34 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 [255] 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805147 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. (3 posts by 1+ user deleted.)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
April 25, 2012, 11:48:02 PM
 #5081

I have submit stale also on also.

About 700 000 shares total submitted and SS still 0 like it should be.

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2
1710828994
Hero Member
*
Offline Offline

Posts: 1710828994

View Profile Personal Message (Offline)

Ignore
1710828994
Reply with quote  #2

1710828994
Report to moderator
1710828994
Hero Member
*
Offline Offline

Posts: 1710828994

View Profile Personal Message (Offline)

Ignore
1710828994
Reply with quote  #2

1710828994
Report to moderator
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
bulanula
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
April 25, 2012, 11:53:16 PM
 #5082

I have submit stale also on also.

About 700 000 shares total submitted and SS still 0 like it should be.

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2

2.3.3

I only update if I need a feature that is not available in the current release or if the new release brings improvements etc.

No need to use 2.3.4 because I don't run a ZTEX Wink
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
April 26, 2012, 12:01:34 AM
 #5083

Hmm.  Let me try 2.3.3 on one of the rigs.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
April 26, 2012, 12:38:26 AM
 #5084

I have submit stale also on also.

About 700 000 shares total submitted and SS still 0 like it should be.

What version of cgminer?
I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2
It was fixed in 2.3.3

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
April 26, 2012, 12:49:53 AM
Last edit: April 26, 2012, 01:21:20 AM by DeathAndTaxes
 #5085

It [SS incrementing with submit stale on] was fixed in 2.3.3

Thanks. I can confirm 2.3.4 is working on my system as expected.

Donation coming your way.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
April 26, 2012, 12:55:10 AM
 #5086

Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.
The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare.
I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins).
You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.
Couldn't agree more.

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 (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
April 26, 2012, 01:01:54 AM
 #5087

ckolivas, it's your baby, do what you want with it.  If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins.  Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000?  Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.

THIS.
Thanks guys, much appreciated comments. As for plugins, the code is already very modular, and true "plugin" architectures written in c aren't really very practical. I will continue to develop the areas I'm most interested in, and find donations very effective at making me interested in things too Wink The bitcoin community on the whole has been generous in that regard, and of course the incentive of a feature being implemented appears to be one of the greatest motivators for donations.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
April 26, 2012, 01:25:46 AM
 #5088

If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.
The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality?
Duly ignored.
Sorry, I think people have a right to know if their donations really won't affect the status quo of regression you've adopted. I don't know any other way to interpret your response than "I want people to donate to me, but I don't want to change the status quo".

Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.
The code seems rather modular already : you can compile support for various things in or not if you wish. Plugins might be a good idea, but they require to design a plugin interface. Accommodating the various peculiarities of each hardware type in the interface might be difficult and designing it to make plugins load in a portable way (Linux/Windows/...) is probably a nightmare.
I'd be pleasantly surprised if ckolivas and cgminer contributors think otherwise and as I think it would benefit myself if possible I even pledge 40BTC for an hardware plugin interface and migration of current GPU/FPGA code to plugins (20 BTC for the cgminer work, 20BTC to split evenly among hardware plugins).
I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating?

kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 26, 2012, 01:44:04 AM
Last edit: April 26, 2012, 04:05:58 AM by kano
 #5089

Luke - I'm pretty sure everyone (but you) understands what he means by a plugin.
In case you weren't up with current technology, here's an explanation that's not too bad:
http://en.wikipedia.org/wiki/Plug-in_%28computing%29

Edit: ... though you could sort of say that the RPC API is like a plugin Smiley
(No I'm not trying to weasel BTC out of nor do I want any BTC from gyverlb's Tongue)

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
April 26, 2012, 01:45:32 AM
 #5090

Luke - I'm pretty sure everyone (but you) understands what he means by a plugin.
In case you weren't up with current technology, here's an explanation that's not too bad:
http://en.wikipedia.org/wiki/Plug-in_%28computing%29
Yeah, and that's exactly what I did. What's your point?

gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
April 26, 2012, 02:31:48 AM
 #5091

I already migrated cgminer to a plugin interface. That was necessary to add FPGA support in the first place. Admittedly, the CPU and GPU code could be pulled out of core better, but the FPGAs have been modular from the start. If you still want to give me the 20 BTC donation for the modularization, you can send it to 1KqGgsE2fHn5MdwAMmYjjwknSvFRZPRAWs. If there's something somehow still lacking, would you mind elaborating?
I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves. Some ways to do so I can think of :
  • an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
  • a binary API that would allow a dynamic library load
A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code. This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things :
  • defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)
  • passing information from the hardware to the display/log layers of the code in a common way.
I don't care much if the plugin interface is a binary or source one : what matters to me is the ease of maintenance of a separate piece of code. So the interface must completely isolate the internal workings of the plugin and the ones of cgminer only allowing communication through a documented, restricted interface. The complexity (from my point of view, I might overestimate this) is that the interface must be flexible enough that it can accommodate current hardware types and even foreseeable future ones. Questions someone designing the interface could ask herself : « would the plugin interface work without any cgminer code change if I need to write a plugin for an ASIC on a PCIe card/a mining appliance communicating through HTTP ? » ... whatever she can think of.
Retrocompatibility would be nice, cgminer should allow plugins not to answer a subset of the interface (ie: some functions would be mandatory for a plugin and others optional). The actual mining process is obviously mandatory, the statistics reported in the UI/command line parameters might be optional
for example.

Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short.
The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).[/list]

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

Activity: 2576
Merit: 1186



View Profile
April 26, 2012, 02:46:30 AM
 #5092

I'm not sure we speak of the kind of plugin interface I'm thinking of (unless you have a fork of cgminer implementing the kind of interface I'm elaborating below).
What I'm looking for is an interface that make it easy for a third party to develop an hardware plugin that should work (mostly) unmodified when cgminer code evolves.
Yep, it does. There have been a few minor API changes since then, but I've tried to retain compatibility.

Some ways to do so I can think of :
  • an autoconf system that would allow configuring a cgminer build to include an arbitrary new plugin whose code would be distributed separately
  • a binary API that would allow a dynamic library load
A solution must be designed so that the single interface through which any hardware plugin would be used must allow what we already have today without modifying cgminer's code.
Ok, it's not too easy (for end users) to add/remove drivers right now. Adding support for that is mostly trivial, though (a dlopen and a driver registration function).

This isn't restricted to the pure mining process if we want "true" plugins independent from the core code. I can think of a few things :
  • defining command line parameters/JSON keys to parse to configure the hardware (how to select them, how to set clocks, ...)
I think this is already possible, but I haven't tried it yet.

  • passing information from the hardware to the display/log layers of the code in a common way.
Yep, this is completely done already. Doing so for JSON API data is also written, but Kano refuses to merge it because he doesn't want outside code providing new stuff for the JSON API or something silly like that.

Maybe you could describe how your plugin interface work (or better point me to the source files implementing the plugin interface in cgminer and the one interfacing with it in a plugin) : if it does what I want you'll have new BTCs (the amount would depend of the actual content of your changesets so that if there's still work to be done I can reserve some BTCs as described in my earlier post) if not I may be better able to see where my explanations fall short.
Sure, here is the current driver interface, the original refactoring, and the first FPGA driver.

The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).
Would a properly maintained cgminer fork be sufficient?

hi
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 26, 2012, 08:09:20 AM
 #5093

why do the older version like 2.0.8 run faster then the 2.3.3?  I get 20 million more hashes with same bat file using 2.0.8.
nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
April 26, 2012, 08:28:06 AM
 #5094

Great stuff !

Just let me know when I can flash my GPU BIOSes without using RBE and using only cgminer.

Also let me know when I can attach cgminer to my grill to cook me some eggs as well !

Too many features in cgminer will not be beneficial for anyone. cgminer is good for one thing : mining.

If you start also allowing it to flash FPGA bitstream and firmware then why not expand it to a household alarm monitor as well etc.

Look at BFL and their "easyminer" software. That is what every FPGA dev should develop instead of piggybacking onto cgminer with puny donations like 10 BTC.

Thanks for the kind words. It is always great to see the community getting together towards building something that is good and useful for... you Smiley

You don't understand open source, that's ok. You do state a lot of good points but then just overdo it and go on to plain and obvious trolling. But I'll bite:

You already have opencl kernels being "pushed" to the GPUs, that's the closest equivalent to the FPGA bitstreams. The firmware is needed because the FPGA interface to its microcontroller isn't standards and changes with bitstreams, sometimes.

Household alarm monitor... yes, proper FPGA handling is too much and unneeded for mining. Why don't we remove LongPoll from cgminer? You can mine without it... not optimal, but hey.

I'm not looking at BFL easyminer for anything, this is a different (and much better imho) product.

Oh, and as for cooking eggs, you can already do that, just crack them on top of your GPUs, cgminer even shows you the optimal cooking temperature!

Reading through your comments I come to the conclusion you don't care about what other people may need from a mining software, so why not ask ckolivas to remove support for every GPU you don't use? That would simplify the code a lot! Also, what's with the "piggybacking" and the puny donations comments? Are you serious? Really?
nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
April 26, 2012, 08:34:24 AM
 #5095

To many people fighting about what should, or should not be included.  Fighting about what the display should look like, fighting about what information should be displayed and what shouldn't.  This is getting to be a pain in the ass.

ckolivas, it's your baby, do what you want with it.  If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins.  Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000?  Get someone to write a plugin for it.  Want Luke and Kano to stop fighting?  Let them write their own separate plugins.

You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.

Fighting about what others should do for you is stupid, but be careful with your assumptions. Plugin support is not trivial and cgminer is already very modular. You can pretty much compile it to your exact needs.

And I must agree that ckolivas writes great software, it has been a pleasure for me to work on top of it but again, careful with the assumptions. The day ckolivas decided to open source it the baby, while still his, began being parented by many other great tutors. I may not always agree with luke-jr or kano (or ckolivas for that matter Smiley ) but luke-jr did a great job improving the modularization of cgminer and creating what became the base for FPGA workers there and kano is making the API better, greater and more useful and everyone combined is finding and fixing bugs that would otherwise be much harder to track if this were a one man show.

ckolivas owns the thing, he knows the code better than anyone else and if it weren't for his great effort we would most likely not have this great piece of software. Major kudos to him!

... but don't make the mistake believing that without everyone else (coders and general community) the code would be the same.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
April 26, 2012, 06:16:27 PM
 #5096

The changes must be accepted by ckolivas (my goal is obviously that future enhancements of cgminer would not systematically break the plugin interface).
Would a properly maintained cgminer fork be sufficient?
Nope. A fork would be unfair to you (one 40 BTC donation for maintaining a fork with such internal changes is basically a steal) and my goal is not only technical but also to help distribute the work by making it easier (documented stable interface) which may attract new contributors and by helping lift some burden from ckolivas' shoulders.

That said, I recognize your existing contribution is going in the general direction I think is good for the project. So I'll send 4BTC right now to you, 4BTC to ckolivas for including it and leave 32BTC as my pledge for a plugin interface that is integrated by ckolivas.

I'm in a donating mood right now so I'll look at the recent changesets to find other contributors to reward. If you are such a contributor don't be upset if you don't get anything : if I don't think your code is or will be used by me, I won't donate or donate a very small contribution.

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

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
April 26, 2012, 07:53:45 PM
 #5097

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
April 26, 2012, 08:12:31 PM
 #5098

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

There is nothing new on the conf file for ztex, you just need to have them running with a compatible firmware (use BTCMiner or FWLoader from ztex to load it up), which means 15d1 to 15d3 for ckolivas release and if you want 15d4 you'll have to build from source found in https://github.com/nelisky/cgminer/tree/ztex-120417

The boards are detected at cgminer start. Let me know if that doesn't work for you.
Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
April 26, 2012, 08:54:52 PM
 #5099

@nelisky how do i use the ztex boards with cgminer ? What are the commands for the conf file ?

There is nothing new on the conf file for ztex, you just need to have them running with a compatible firmware (use BTCMiner or FWLoader from ztex to load it up), which means 15d1 to 15d3 for ckolivas release and if you want 15d4 you'll have to build from source found in https://github.com/nelisky/cgminer/tree/ztex-120417

The boards are detected at cgminer start. Let me know if that doesn't work for you.

Thanks for the info. I use the newest firmware. That seems to be the reason for the errors. Looking forward for the next release.

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
April 26, 2012, 09:05:18 PM
 #5100


Thanks for the info. I use the newest firmware. That seems to be the reason for the errors. Looking forward for the next release.

You can also just use the previous BTCMiner (120221) and flash the 15d3 firmware which will allow you to use cgminer as released right now. There is no speed gain in 15d4 that I can see.
Pages: « 1 ... 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 [255] 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!