Bitcoin Forum
April 16, 2014, 10:13:26 AM *
News: ♦♦ A bug in OpenSSL, used by Bitcoin-Qt/Bitcoin Core, could allow your bitcoins to be stolen. Immediately updating Bitcoin Core to 0.9.1 is required in some cases, especially if you're using 0.9.0. Download. More info.
The same bug also affected the forum. Changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
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 ... 749
  Print  
Author Topic: CGMINER ASIC miner monitoring RPC linux/win/osx/mips/arm/r-pi 4.2.3  (Read 2641771 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.
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile

Ignore
April 25, 2012, 09:48:52 PM
 #5081

Regarding ztex support, is dynamic frequency scaling supported (like with BTCMiner)?

Yes. There are a few things missing still:

- support for quad boards (1.15y)
- suspend
- high speed bitstream upload
- hotplug
- firmware upload (to support hot upgrade and the new bogus firmware feature)
- Support for the latest firmware (120417, bitstream 15d4) - This is already done but waiting on inclusion on the main repository

All of the above will be addressed as time permits. You can use the latest firmware if you compile cgminer yourself, grab it here -> https://github.com/nelisky/cgminer/tree/ztex-120417

There is a lot more I want to do but I've been mining with ztex 1.15x boards on cgminer for roughly one month now and it works great Smiley

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.
180GH/s ANTMINER S1 Classical mining rig by the trustworthy vendor BITMAIN
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397643206
Hero Member
*
Offline Offline

Posts: 1397643206

View Profile Personal Message (Offline)

Ignore
1397643206
Reply with quote  #2

1397643206
Report to moderator
1397643206
Hero Member
*
Offline Offline

Posts: 1397643206

View Profile Personal Message (Offline)

Ignore
1397643206
Reply with quote  #2

1397643206
Report to moderator
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile

Ignore
April 25, 2012, 11:34:01 PM
 #5082

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.

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Activity: 952



View Profile WWW

Ignore
April 25, 2012, 11:39:22 PM
 #5083

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.

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Activity: 952



View Profile WWW

Ignore
April 25, 2012, 11:42:25 PM
 #5084

If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0?

If submit-stale = true and  SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.

B is less of a problem but it results in bogus stats.  If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++).  If SS is also being incremented then the same share is being counted twice.

The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0.  It is a low % (say 0.5%) but it should always be 0 right?

On edit:  so I looked at all my rigs.  It seems only "newer" cgminer has SS > 0.
I have some rigs still on cgminer 2.1.2 (BAMT 0.4) they all properly show SS = 0 (one has been running 60 days w/ SS = 0).
I have some rigs on cgminer 2.3.1f (BAMT 0.5) they all have SS > 0.

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile

Ignore
April 25, 2012, 11:45:19 PM
 #5085

If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0.

If submit-stale = true and  SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.

B is less of a problem but it results in bogus stats.  If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++).  If SS is also being incremented then the same share is being counted twice.

The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0.  It is a low % (say 0.5%) but it should always be 0 right?

I have submit stale also on also.

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

Strange ...
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Activity: 952



View Profile WWW

Ignore
April 25, 2012, 11:48:02 PM
 #5086

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

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile

Ignore
April 25, 2012, 11:53:16 PM
 #5087

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

Activity: 952



View Profile WWW

Ignore
April 26, 2012, 12:01:34 AM
 #5088

Hmm.  Let me try 2.3.3 on one of the rigs.

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
ckolivas
Moderator
Hero Member
*
Offline Offline

Activity: 1036



View Profile WWW

Ignore
April 26, 2012, 12:38:26 AM
 #5089

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

Primary developer/maintainer for cgminer: https://bitcointalk.org/index.php?topic=28402.0  148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
ONLY ignoring luke-jr
-ck
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Activity: 952



View Profile WWW

Ignore
April 26, 2012, 12:49:53 AM
 #5090

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.

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
gyverlb
Hero Member
*****
Offline Offline

Activity: 840



View Profile

Ignore
April 26, 2012, 12:55:10 AM
 #5091

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

Activity: 1036



View Profile WWW

Ignore
April 26, 2012, 01:01:54 AM
 #5092

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.

Primary developer/maintainer for cgminer: https://bitcointalk.org/index.php?topic=28402.0  148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
ONLY ignoring luke-jr
-ck
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1204



View Profile

Ignore
April 26, 2012, 01:25:46 AM
 #5093

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

Activity: 1008


Linux since 1997 RedHat 4


View Profile

Ignore
April 26, 2012, 01:44:04 AM
 #5094

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)

BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CGMiner developer,  IRC FreeNode #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1204



View Profile

Ignore
April 26, 2012, 01:45:32 AM
 #5095

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: 840



View Profile

Ignore
April 26, 2012, 02:31:48 AM
 #5096

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

Activity: 1204



View Profile

Ignore
April 26, 2012, 02:46:30 AM
 #5097

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


View Profile

Ignore
April 26, 2012, 08:09:20 AM
 #5098

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

Activity: 1218


View Profile

Ignore
April 26, 2012, 08:28:06 AM
 #5099

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?

we measure long periods of time in bitcoin blocks, and short ones in vodka tonics
DividendRippler  | DICEonCRACK | The Amazing Anonymous Bitcoin Lottery
nelisky
Hero Member
*****
Online Online

Activity: 1218


View Profile

Ignore
April 26, 2012, 08:34:24 AM
 #5100

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.

we measure long periods of time in bitcoin blocks, and short ones in vodka tonics
DividendRippler  | DICEonCRACK | The Amazing Anonymous Bitcoin Lottery
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 ... 749
  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!