Bitcoin Forum
December 04, 2016, 04:34:25 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4816950 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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 29, 2012, 01:44:27 AM
 #5981

semi-hostile fork
I don't really consider it hostile or even semi-hostile. I forked to accomplish two goals, both of which IMO have been successful to some degree:
  • working miner for Icarus FPGAs (since you let kano remove important bugfixes from cgminer, so I had no choice if I wanted to keep Icarus working)
  • minimize everyone's time wasted arguing over changes (now if there's a disagreement, I can just merge it to BFGMiner and not worry about whether CGMiner takes it or not)

I'll be disappointed if you decide to stop contributing, but I can understand your point of view.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DILLIGAF
Full Member
***
Offline Offline

Activity: 168



View Profile
June 29, 2012, 02:05:02 AM
 #5982

Dude can't read.

I can read perfectly fine, so a release that is not a release when it is customary to increment the number of the build to avoid confusion, yet somehow when I asked that question I knew I would get asshole responses to it as is customary around here...
...
Yeah coz it aint released it doesn't have a new version number yet.
Simple.

Do I Look Like I Give A Fuck <- I'm sure most people are thinking

Ask a simple question and the moron brigade is out in force, up yours asshole.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
June 29, 2012, 03:17:00 AM
 #5983

I'm really hoping you don't stop developing, as I would rather use your software over a fork. You've done a great job so far, and I'm hoping that I can use CGMiner when ASICs start coming out.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 29, 2012, 03:26:52 AM
 #5984

I'm really hoping you don't stop developing, as I would rather use your software over a fork. You've done a great job so far, and I'm hoping that I can use CGMiner when ASICs start coming out.
CGMiner was originally a fork of CPUMiner for the CPU->GPU migration. BFGMiner is basically the same thing from GPU->FPGA/ASIC, except that I opted to try keeping CGMiner in sync instead of just flat out forking from the start.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 29, 2012, 03:29:40 AM
 #5985

While that may be true, cgminer is now only about 5% of the original cpuminer code since 20 times more code replaced what was there, so it's hardly a comparison.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 29, 2012, 04:30:32 AM
 #5986

Dude can't read.

I can read perfectly fine, so a release that is not a release when it is customary to increment the number of the build to avoid confusion, yet somehow when I asked that question I knew I would get asshole responses to it as is customary around here...
...
Yeah coz it aint released it doesn't have a new version number yet.
Simple.

Do I Look Like I Give A Fuck <- I'm sure most people are thinking

Ask a simple question and the moron brigade is out in force, up yours asshole.
Heh - well that is your forum name ... so why the hostility Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
June 29, 2012, 04:59:19 AM
 #5987

semi-hostile fork
I don't really consider it hostile or even semi-hostile. I forked to accomplish two goals, both of which IMO have been successful to some degree:
  • working miner for Icarus FPGAs (since you let kano remove important bugfixes from cgminer, so I had no choice if I wanted to keep Icarus working)
...
You see Luke-jr - in my opinion that is the exact reason why no one should trust any fork you are in charge of (as I stated in your thread)
That statement is a flat out lie.
And it is easy to prove that it is a lie.
People can grab that commit of yours that was committed into cgminer, compile a windows version and plug in an Icarus and run cgminer.
cgminer will hang - die - stop working - nada.
You never even tried to run/test it on windows as you yourself said and on windows it hung.
I had already written a new icarus code and put it in my git and been using it for weeks with xiangfu on his Icarus farm.
I had not committed it because I still had not yet tested the code on windows (my windows dev vm didn't work)
Up came you with your own version of icarus changes.
I pointed out other bugs in your code and then simply said to you to forget it I'll test my code on windows and put my version up asap.
Your version was accepted by ckolivas before you tested it so when I went to test it and found it hung I simply put my version in replace of it.
The IRC logs of these discussions and git logs are quite straight forward in showing this.

I will also add that your github git has my changes ...

...
  • minimize everyone's time wasted arguing over changes (now if there's a disagreement, I can just merge it to BFGMiner and not worry about whether CGMiner takes it or not)
...
Yes that is the issue - and again it even happened in the last week or so.
You committed some new replacement code for an important windows fix.
(aside: the same fix I wrote that we previously argued about and you stopped from going into the cgminer version, yet also put in your own fork)
Your new replacement code didn't work (any sort of test run of it shows that)
Oddly, you had a fix in your fork, but had not put it in cgminer ... ... ...
So I put that fix into cgminer.

...
I'll be disappointed if you decide to stop contributing, but I can understand your point of view.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
miscreanity
Legendary
*
Offline Offline

Activity: 1078


View Profile
June 29, 2012, 06:57:39 AM
 #5988

re: The ASIC revolution

...

I will most definitely be maintaining cgminer and actively developing it right up to the moment some real ASIC hardware appears, so don't think I'm abandoning anything any time soon. Ironically a lot of the recent development has been towards making cgminer scale to massive hashrates, devices and pools.

Comments please.

As far as BFL's ASICS - I'll believe it when I see it, just like it was with their FPGAs. Initial stumbles can be forgiven if they really do produce a quality piece of hardware, then follow up with support and community involvement. If not, there are other ASIC projects.

The 7970 crowd sourcing went pretty well, and that was for a $500+ component. A 3.5 Gh/s BFL Jalapeno is only $187 including international shipping...

You could set up an address, and when it gets to 30 BTC, order a unit.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 29, 2012, 07:18:29 AM
 #5989

The 7970 crowd sourcing went pretty well, and that was for a $500+ component. A 3.5 Gh/s BFL Jalapeno is only $187 including international shipping...

You could set up an address, and when it gets to 30 BTC, order a unit.
It did indeed and I was most impressed by the community's generosity at the time. I had issues with FPGA and never wanted to invest or even develop for them because they really did not look like they'd ever pay themselves off - and indeed if ASIC really does come in any time in the next year, pretty much not one single FPGA will have made a profit before they're defunct technology and just doorstops. On the other hand I can still sell my GPUs if they become defunct technology and they've never made a loss. ASIC is a different beast entirely. They polarise the issue into one of being 100% you MUST bet on bitcoin being successful, like FPGAs, but they are very different in that they will also be the ONLY way to make a profit mining should they eventuate.

Personally I don't like sending money into a black hole and hoping the universe will spit out a device in response. I'm disappointed, but not remotely surprised, by BFL's silence in response to my emails and polite posts on the forum. To be able to code a meaningful set of device drivers for their devices I would need access to each of the devices on offer. I'm not expecting anyone to donate a $30k device, but the lower spec devices would be very reasonable sponsorship for the work, and at least giving me temporary remote access to develop for the $30k device would be beneficial for all in my opinion. On the other hand, if the community doesn't care one bit about what software they're mining with, and a software solution arises that is a "turn on and it just mines", I'm just wasting my time here. That is definitely a huge factor in my thought process.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
June 29, 2012, 07:36:12 AM
 #5990

BFL will be losing my business if they don't supporting CG Miner

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 29, 2012, 09:38:28 AM
 #5991

BFL will be losing my business if they don't supporting CG Miner
Very kind words about supporting cgminer they be, thank you. Alas BFL care not.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
June 29, 2012, 09:40:54 AM
 #5992

I noticed something was fishy when they recommended another miner, I tried it, disgusting!

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
tnkflx
Sr. Member
****
Offline Offline

Activity: 346


View Profile
June 29, 2012, 12:37:52 PM
 #5993

re: The ASIC revolution

I'm in two minds about what I'll do if/when the ASIC revolution comes. I've tried to engage BFL as potentially developing software for their hardware somehow sponsored by them, but they're completely silent in response. Furthermore any software developed to drive them will likely be based on existing fgpa code which I had no input into, which means that if I don't do the development, it will be luke-jr who does as the fpga code was done by luke-jr who now maintains a semi-hostile fork of cgminer and I guess he's ideally positioned to take over maintainership of the project entirely as that fork if I pull out. I'd hate my baby to end entirely in his hands but it's looking inevitable unless I fork cash out to BFL who I don't even trust, to do the code for their own hardware. They obviously realise they'll corner the market in the interim regardless of what their software and community support will be like so they are guaranteed to make huge profits and they need not engage the community and developer(s) in a positive way.

I will most definitely be maintaining cgminer and actively developing it right up to the moment some real ASIC hardware appears, so don't think I'm abandoning anything any time soon. Ironically a lot of the recent development has been towards making cgminer scale to massive hashrates, devices and pools.

Comments please.

Couple of questions come to mind...
- Will getting you a BFL ASIC based something help with developing cgminer for it?
- OpenASIC?

| Operating electrum.be & us.electrum.be |
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
June 29, 2012, 10:32:46 PM
 #5994

Couple of questions come to mind...
- Will getting you a BFL ASIC based something help with developing cgminer for it?
- OpenASIC?
1. Precisely why I tried getting sponsorship from BFL themselves in the form of hardware, so yes.
2. Not my area of expertise and the project progress appears slow...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 30, 2012, 03:09:51 PM
 #5995

The 7970 crowd sourcing went pretty well, and that was for a $500+ component. A 3.5 Gh/s BFL Jalapeno is only $187 including international shipping...

You could set up an address, and when it gets to 30 BTC, order a unit.
It did indeed and I was most impressed by the community's generosity at the time. I had issues with FPGA and never wanted to invest or even develop for them because they really did not look like they'd ever pay themselves off - and indeed if ASIC really does come in any time in the next year, pretty much not one single FPGA will have made a profit before they're defunct technology and just doorstops. On the other hand I can still sell my GPUs if they become defunct technology and they've never made a loss. ASIC is a different beast entirely. They polarise the issue into one of being 100% you MUST bet on bitcoin being successful, like FPGAs, but they are very different in that they will also be the ONLY way to make a profit mining should they eventuate.

Personally I don't like sending money into a black hole and hoping the universe will spit out a device in response. I'm disappointed, but not remotely surprised, by BFL's silence in response to my emails and polite posts on the forum. To be able to code a meaningful set of device drivers for their devices I would need access to each of the devices on offer. I'm not expecting anyone to donate a $30k device, but the lower spec devices would be very reasonable sponsorship for the work, and at least giving me temporary remote access to develop for the $30k device would be beneficial for all in my opinion. On the other hand, if the community doesn't care one bit about what software they're mining with, and a software solution arises that is a "turn on and it just mines", I'm just wasting my time here. That is definitely a huge factor in my thought process.
BFL devices are already supported. It seems there is a general misunderstanding on this topic here: while Con has always done a great job maintaining CGMiner as a GPU miner, including the core code dealing with pool requests and ncurses TUI... his involvement with CGMiner support for FPGAs has always been minimal; FPGA and multi-device support in CGMiner is my work, and I plan to continue maintaining it (including maintaining the pool/ncurses code if Con leaves) as well as extend it to work with ASICs. In other words, even if Con does receive FPGAs/ASICs and begins contributing code for them, that is a change from the status quo. Perhaps it was a mistake to label BFGMiner as a fork of CGMiner - while true from a "who has the repository" perspective, the opposite is true in a more practical sense of maintainership: in that respect, CGMiner-of-today is a fork of BFGMiner.

So while I appreciate Con's contributions, and would welcome his joining in on the FPGA/ASIC driver side, it isn't fair to say "the community doesn't care one bit about what software they're mining with" just because they don't see a need to buy hardware for a new developer for what is already working fine and maintained. That being said, don't let this stop anyone from buying Con some FPGAs or ASICs - his contributions to CGMiner are more than worth what they cost.

In short:
  • FPGA support in CGMiner has always been my work, and plan to keep maintaining it in any case
  • Con's contributions to general CGMiner code (and GPUs!) is appreciated and great quality code; I'd love to have him contribute to FPGA/ASIC drivers in the future
  • Please do donate to Con, including FPGAs/ASICs, for his past and possibly future contributions - but don't get the wrong impression that FPGA/ASIC support will change or degrade if you choose not to

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
July 01, 2012, 01:03:25 AM
 #5996

...
So while I appreciate Con's contributions, and would welcome his joining in on the FPGA/ASIC driver side, it isn't fair to say "the community doesn't care one bit about what software they're mining with" just because they don't see a need to buy hardware for a new developer for what is already working fine and maintained. That being said, don't let this stop anyone from buying Con some FPGAs or ASICs - his contributions to CGMiner are more than worth what they cost.

In short:
  • FPGA support in CGMiner has always been my work, and plan to keep maintaining it in any case
  • Con's contributions to general CGMiner code (and GPUs!) is appreciated and great quality code; I'd love to have him contribute to FPGA/ASIC drivers in the future
  • Please do donate to Con, including FPGAs/ASICs, for his past and possibly future contributions - but don't get the wrong impression that FPGA/ASIC support will change or degrade if you choose not to
Unfortunately, this is actually clearly an exaggeration to the point of being incorrect.

luke-jr wrote the first FPGA module which was support for the BFL.

Xiangfu wrote the first support for the Icarus based on Luke-jr's BFL code but even back then had to rewrite enough of it to make it work properly - back with the first release of the Icarus code my involvement was to help debug Xiangfu's code and get it working.

nelisky wrote the entire ztex support and luke-jr has had nothing to do with that at all.

By this point I had rewritten some of the Icarus code, extended it and also added the only performance gains to it so far: LP abort, 10x setup speed and optimising the abort time to reduce getworks
The only non-trivial change that luke-jr initiated for Icarus (even in his fork) was to close and re-open the serial port every time it sent work to the Icarus to avoid a problem with the serial port not working due to a problem with his linux kernel he was using - which I requested he instead determine when there was a serial port problem and then close and re-open it (since it was such a rare problem) - but he refused to.

I requested he change the BFL code to abort work on an LP to stop wasting work (on average half a nonce per LP) - of course only if the pool doesn't accept or need stale work - but again he refused to do it (and still hasn't)
The side affect for anyone mining on a pool that doesn't pay stale shares, is that the BFL code now gets 5x the stale shares compared to GPU and Icarus when you factor in the MH/s speed
(i.e. if you incorrectly ignore the MH/s difference BFL is 10x the number of stale shares vs Icarus)
Feel free to view my rigs (2xICA, 1xBFL, 1x6950) to verify this:
http://207.36.180.49/miner.php?ref=0&pg=Mobile
(N.B. that page is very slow to load and I will remove it from this post some time in the future)

His excuse for this was: June-1 GMT+10 log discussion:
The next MOD that decides to remove this BETTER HELL ASK ME FIRST OR HAVE A GOOD EXCUSE
other than pandering to a bull shit request from Luke-jr and helping hide his lies ... got that gmaxwell?
The PUBLIC FreeNode IRC #cgminer channel that anyone can be in - including you have been in - is NOT private in any way

[Private log reposted without permission removed]
Code:
12:50 < luke-jr> kanoi: Bitforce still can't interrupt work like Icarus can
12:50 <@kanoi> it can't abort work at all?
12:51 < luke-jr> not the same way Icarus does
12:51 <@kanoi> I know that
12:51  * luke-jr isn't really interested in working around BFL's screwups, especially when there's a proper fix coming "any day now"
12:51 <@kanoi> if the work isn't submit-stale and cgminer isn't submit stale then aborting the work will be a clear increase in performance
12:52 <@kanoi> very simple and obvious
12:52 < luke-jr> that's nice, but it isn't what I'm doing.
12:53 <@kanoi> you don't like obvious simple performance increases ... :P
12:53 <@kanoi> lol
12:53 < luke-jr> no, I do. I just don't push it upstream when it's an ugly hack that gives BFL a way out of fixing it properly.
12:53 < luke-jr> my private branch aborts BF jobs when the block hash changes

Still no sign of that 'private' code he wrote more than a month ago ...
So everyone using BFL on a pool that doesn't pay stale shares is getting 5x the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x)

luke-jr wrote the support for MMQ
(I wont get into the issues with that code now ...)

luke-jr added support for the BFL Rig Box (similar to the BFL single)

Now for the actual commits in the commit log with our names on them I did:
 git log | grep Author | grep -i (kolivas or kano or luke)
Matching the following words:
kolivas: 1659
kano: 198
luke: 78

This of course includes git management by ckolivas, however, git management is just as important as writing code for the git

Now I wont make any exact meaning of those numbers - but feel free to analyse the results if you wish.

I clearly have trust issues with anything luke-jr says ... maybe others do too? Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 01, 2012, 01:29:22 AM
 #5997

I clearly have trust issues with anything luke-jr says ... maybe others do too? Smiley
You should work on those issues. Would be more productive than posting lies on the forum.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
July 01, 2012, 02:05:38 AM
 #5998

I clearly have trust issues with anything luke-jr says ... maybe others do too? Smiley
You should work on those issues. Would be more productive than posting lies on the forum.
The problem with that statement is:
Prove anywhere one lie you say I have said ... anywhere ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
July 01, 2012, 02:52:00 AM
 #5999

New version - 2.4.4, 1st July 2012

I plugged my main PC's hard drive into an external USB reader to allow me to build this on my laptop since I really wanted this release out.

Human readable changelog:
Massive overhaul of the nrolltime mechanism now should cause a huge rise in efficiency on pools that support it. This allows much lower getwork bandwidth for much higher hashrates.
Support for the expire= feature. This works in concert with nrolltime when pools support it to allow more local generation of work.
Support for the x-mining-hashrate feature. I'm sure some pool somewhere cares about this, even though I'm not convinced, but it was trivial to add.
Better damping of GPU temperature changes should cause much less overshoot when temps rise or fall outside the optimal range in autofan mode.
Reinstated the application restart should adl fail - disabling this did not fix the crashes for those who had cgminer crash after 1 week of uptime in windows fail land when their ATI driver would fail, and disabled the advantage of it fixing the problem for those who simply lost their fanspeed.
API groups features - this is squarely aimed at grouping privileges for remote access for services like P4man's hopping puppetmaster service.
Support for unlimited devices
Support for unlimited pools
Massive fix for the "dynamic" feature for GPUs. Somehow in the many device abstractions it had gotten broken and wasn't really doing what it was intended. It should be much more dynamic now.
FPGA fixes.
Fixes for builds on other platforms.
Lots of other things under the hood.


Full changelog
- Fix builds on non gnu platforms.
- api.c ensure old mode is always available when not using --api-groups + quit()
on param errors
- Implement rudimentary X-Mining-Hashrate support.
- Detect large swings in temperature when below the target temperature range and
change fan by amounts dependant on the value of tdiff.
- Adjust the fanspeed by the magnitude of the temperature difference when in the
optimal range.
- Revert "Restarting cgminer from within after ADL has been corrupted only leads
to a crash. Display a warning only and disable fanspeed monitoring."
- api.c fix json already closed
- implement and document API option --api-groups
- Put upper bounds to under 2 hours that work can be rolled into the future for
bitcoind will deem it invalid beyond that.
- define API option --api-groups
- api.c allow unwell devices to be enabled so they can be cured
- miner.php - fix/enable autorefresh for custom pages
- miner.php allow custom summary pages - new 'Mobile' summary
- Work around pools that advertise very low expire= time inappropriately as this
leads to many false positives for stale shares detected.
- Only show ztex board count if any exist.
- There is no need for work to be a union in struct workio_cmd
- fpgautils.c include a debug message for all unknown open errors
- Don't keep rolling work right up to the expire= cut off. Use 2/3 of the time
between the scantime and the expiry as cutoff for reusing work.
- Log a specific error when serial opens fail due to lack of user permissions
- Increase GPU timing resolution to microsecond and add sanity check to ensure
times are positive.
- Opencl code may start executing before the clfinish order is given to it so
get the start timing used for dynamic intensity from before the kernel is
queued.
- fpgautils.c - set BAUD rate according to termio spec
- fpgautils.c - linux ordering back to the correct way
- miner.php remove unneeded '.'s
- miner.php add auto refresh options
- miner.php add 'restart' next to 'quit'
- miner.php make fontname/size configurable with myminer.php
- Make the pools array a dynamically allocated array to allow unlimited pools to
be added.
- Make the devices array a dynamically allocated array of pointers to allow
unlimited devices.
- Dynamic intensity for GPUs should be calculated on a per device basis. Clean
up the code to only calculate it if required as well.
- Use a queueing bool set under control_lock to prevent multiple calls to
queue_request racing.
- Use the work clone flag to determine if we should subtract it from the total
queued variable and provide a subtract queued function to prevent looping over
locked code.
- Don't decrement staged extras count from longpoll work.
- Count longpoll's contribution to the queue.
- Increase queued count before pushing message.
- Test we have enough work queued for pools with and without rolltime
capability.
- As work is sorted by age, we can discard the oldest work at regular intervals
to keep only 1 of the newest work items per mining thread.
- Roll work again after duplicating it to prevent duplicates on return to the
clone function.
- Abstract out work cloning and clone $mining_threads copies whenever a rollable
work item is found and return a clone instead.
- api.c display Pool Av in json
- Take into account average getwork delay as a marker of pool communications
when considering work stale.
- Work out a rolling average getwork delay stored in pool_stats.
- Getwork delay in stats should include retries for each getwork call.
- Walk through the thread list instead of searching for them when disabling
threads for dynamic mode.
- Extend nrolltime to support the expiry= parameter. Do this by turning the
rolltime bool into an integer set to the expiry time. If the pool supports
rolltime but not expiry= then set the expiry time to the standard scantime.
- When disabling fanspeed monitoring on adl failure, remove any twin GPU
association. This could have been leading to hangs on machines with dual GPU
cards when ADL failed.
- modminer: Don't delay 2nd+ FPGAs during work restart
- Disable OpenCL code when not available.
- Fix openwrt crashing on regeneratehash() by making check_solve a noop.
- FPGA - allow device detect override without an open failure
- Fix sign warning.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
July 01, 2012, 04:56:34 AM
 #6000

... and anyone looking for an Xubuntu 11.04 compile of 2.4.4
-> cgminer-2.4.4a at the top of https://github.com/kanoi/cgminer/downloads
(I'm running this executable at the moment on both my rigs)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 ... 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 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 ... 830 »
  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!