Bitcoin Forum
December 04, 2016, 10:24:27 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 244960 times)
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
April 28, 2012, 03:30:39 AM
 #41

Firstly the TL;DR version: I consider it unlikely for a project run by Luke-jr to continually spit out reliable code
That may mean that you wont have any problems so it may not matter to you.

The long version:
The base code in cgminer is the scheduling and threading of dealing with mining devices and pools
That was designed and written by ckolivas - who also wrote a linux kernel scheduler that eventually led to the linux kernel 'gurus' rewriting their's coz ckolivas was better.

The FPGA code in cgminer is not really that big a deal.
Anyone can write that - hell - even I can Smiley
Adding support for the latest greatest patch by 'Luke-jr' is rarely if EVER going to mean you will get more BTC than pico bit cents.
Of course getting those extra pico bit cents is good - but in my case, I'm more wary of bugs going into the code first then the pico bit cent gains can go in next when it's tested and debugged

There is definitely no problem with arguing about opinions.
My problem came when luke-jr argues about bugs being bugs due to the "I'm always right" issue he has.

I wrote changes for Icarus but hadn't tested them on Windows so I didn't put them up for a pull request
Xiangfu and I ran that code for a few weeks that I had discussed often in IRC also (but I didn't do a pull request as I said a few times in IRC coz I had no working Windows test environment to compile or run it)

Luke-jr submitted a pull request to ckolivas to do the same thing weeks after I wrote it and had it in my git

In my first look at the code there were 2 bugs (from simply just looking at the code) that I brought up with Luke-jr
I knew they were bugs because I had already written my own version of the code (as he knew)
That turned into a long running argument of him saying they weren't bugs and that I was wrong
Nowhere in that first discussion did he consider testing what I pointed out or consider that what I said was correct.

I was correct, they were bugs and he eventually changed it (not the end of the bugs ... read below)

The reason I ended up outright rejecting his Icarus code, and writing mine over it, was the Windows issue:
I finally did get my windows environment working again by deleting it and starting again using Sharky's windows script
(which I hadn't wanted to do Sad but obviously was necessary since I was taking way to long to fix my windows test area for cgminer)
Next, I firstly tried to run Luke-jr's Icarus code since it was ALREADY committed into cgminer (and DIRECTLY admitted by him already that he had never tested it on windows)
His version just hanged cgminer in windows (stopped dead mid code and didn't report an error or exit or abort)
I tried my version (2nd) and found that it failed to detect the icarus (and the code said so) then of course said it found nothing to mine with and exited.
What this of course meant was the initial detection code had an issue and I next implemented changes like af_newbie had suggested to initialise the Serial-USB and found that fixed it.
That didn't fix Luke-jr version (that was already committed into cgminer) so I wasn't really all that interested in debugging his code (and having another argument with him about whatever the bug was), his code that he hadn't even tested in windows (as he had stated himself) so since my code worked and I had written it weeks before and run it for weeks on 43 Icarus devices in linux - I simply requested my pull request be committed directly into cgminer (effectively undo luke-jr's changes) since the current code in there didn't even work on windows and hung cgminer

I'm not sure what anyone else would have done, but after the issue with him the week before arguing about him saying the text saying "ICA" instead of "PGA" being a MAJOR BUG and he wouldn't agree to anything that he said he would agree to about that text, I was jack of it and just overwrote his non-working icarus code (that I had myself written weeks before him anyway)

What this fork will have is "He is always right" so he will allow any code he writes even if he hasn't tested it properly (or tested it at all)
If he says "no that won't happen any more" then why the fuck did it happen OFTEN before - and how has that suddenly changed when no one else is checking his code?

Lastly, you don't need to believe me - but I can supply IRC logs and pull request logs that clearly show all this.
(I'm just not really interested in spending hours to go through all that - though the pull requests are all there for anyone to see and the irclog of Freenode/#cgminer - well yeah I have a majority of the last 8 months of that ...)

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

Posts: 1480847067

View Profile Personal Message (Offline)

Ignore
1480847067
Reply with quote  #2

1480847067
Report to moderator
1480847067
Hero Member
*
Offline Offline

Posts: 1480847067

View Profile Personal Message (Offline)

Ignore
1480847067
Reply with quote  #2

1480847067
Report to moderator
1480847067
Hero Member
*
Offline Offline

Posts: 1480847067

View Profile Personal Message (Offline)

Ignore
1480847067
Reply with quote  #2

1480847067
Report to moderator
There are several different types of Bitcoin clients. Hybrid server-assisted clients like Electrum get a lot of their network information from centralized servers, but they also check the server's results using blockchain header data. This is perhaps somewhat more secure than either server-assisted clients or header-only clients.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
April 28, 2012, 04:42:00 AM
 #42

NEW VERSION 2.3.5, APRIL 28 2012

This release of BFGMiner addresses the source release's configure issues, and includes most of the changes from CGMiner 2.3.5.
One notable exception is that BFGMiner retains the --no-longpoll option, since I found it useful for testing/development.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
April 28, 2012, 05:33:11 AM
 #43

Aw, come on, do a proper release post.
If it's just 'cgminer' go read the release over there, then it's pretty much ... and go use cgminer also Tongue

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

Activity: 107


View Profile
April 28, 2012, 05:19:08 PM
 #44

lol ... kano is such a cry baby
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
April 28, 2012, 11:03:08 PM
 #45

Unable to test it atm .... working on some of my Singles that have some weird problems (one thinks to be a quad 1.15y and the other one seems to be dead for no reason?) 

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
April 29, 2012, 12:37:47 AM
 #46

NEW VERSION 2.3.6, APRIL 29 2012


Note this is a "upstream changes from CGMiner only" release.

Human readable changelog
  • Important: --submit-stale option no longer exists. Con has replaced it with --no-submit-stale and made it submit stale shares by default now. The reason for this change is that with the new longpoll code in cgminer, it can detect block changes if you have backup pools almost always faster than the primary pool can detect the block change (unless the primary pool found the block). This means the primary pool is still accepting shares for the old block, so it won't consider them stale yet.
  • Con has further revised the networking code to be able to cope with multigigahash machines that can overwhelm the one upstream and one downstream connection that was introduced into 2.3.5. Now it tries to get the best of all worlds. It does this by keeping one connection open for up and one for down and reuses that at all times, but, when it detects a backlog of share submission or getworks will occur, it starts recruiting extra connections. Thus it will be as nice as it can be to networks, but get nasty if it needs to.
  • Two crashes were fixed: One was that hot-adding of pools was broken in 2.3.5. The second crash would very rarely occur across a longpoll when many pools were set up.
  • The double longpoll message from the same pool should be fixed.
  • Slight changes to make the screen output even neater.

Full changelog:
  • Shorten stale share messages slightly.
  • Protect the freeing of current_hash under mutex_lock to prevent racing on it when set_curblock is hit concurrently.
  • Change default behaviour to submitting stale, removing the --submit-stale option and adding a --no-submit-stale option.
  • Make sure to start the getwork and submit threads when a pool is added on the fly. This fixes a crash when a pool is added to running cgminer and then switched to.
  • Faster hardware can easily outstrip the speed we can get work and submit shares when using only one connection per pool.
  • Test the queued list to see if any get/submits are already queued and if they are, start recruiting extra connections by generating new threads.
  • This allows us to reuse network connections at low loads but recuit new open connections as they're needed, so that cgminer can scale to hardware of any size.

preparation
Member
**
Offline Offline

Activity: 63


View Profile
May 02, 2012, 06:58:59 AM
 #47

I'd like to request a protection of BFGMiner in case a BFL unit will be disconnected. If you unplug the usb cable the miner crashes as 'BFwrite failed'.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 02, 2012, 01:06:35 PM
 #48

I'd like to request a protection of BFGMiner in case a BFL unit will be disconnected. If you unplug the usb cable the miner crashes as 'BFwrite failed'.
What would you expect it to do? BFGMiner isn't hotplug-capable (yet). Maybe it could disable the device...

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
May 02, 2012, 01:54:44 PM
 #49

Yes, please... if one of my units fails or otherwise goes off line, it basically brings the entire cluster down... very annoying. 

Hotplug would be the best, but disabling the device is a second best, since the rest can keep mining at the point.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
preparation
Member
**
Offline Offline

Activity: 63


View Profile
May 02, 2012, 02:34:46 PM
 #50

Yes, please... if one of my units fails or otherwise goes off line, it basically brings the entire cluster down... very annoying. 

Hotplug would be the best, but disabling the device is a second best, since the rest can keep mining at the point.

this is exactly what I wanted to say
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 02, 2012, 02:37:28 PM
 #51

OK, I wrote the code to do it and sent it to Con for CGMiner. Whether he merges it or not, it'll be in the next BFGMiner.

Hpman
Full Member
***
Offline Offline

Activity: 176



View Profile
May 02, 2012, 02:57:15 PM
 #52

Hi, I'm using ubuntu 12.04. For preparation i'm using ./configure --enable-ztex but it stops with
Code:
checking for libusb_init in -lusb-1.0... no
configure: error: Could not find usb library - please install libusb
I thought libusb is already installed per default on ubuntu ? Do i need to copy any header file in the bfgminer directory ?
I installed libsusb-dev too but it doesn't help.

Thanks Hpman
PS: BTCMiner works, i guess without libusb it would not.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
May 02, 2012, 03:05:45 PM
 #53

Yes, please... if one of my units fails or otherwise goes off line, it basically brings the entire cluster down... very annoying. 

this is exactly what I wanted to say

Guys, as a temporary workaround, you can wrap your cgminer call in a .bat file (Windows), or the Linux equivalent. Something like this (again, Windows code):

Code:
:loop
cgminer <your parameters>
waitfor /t 10 signame
goto loop

If cgminer quits for any reason (such as a Single going offline), the batch file will pause for 10 seconds (adjust this to whatever you want) and then runs cgminer again. If you ever want to stop the infinite loop and get out of the batch file, hit <ctrl-c> and answer 'y' to the prompt that appears (again, Windows).

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
May 02, 2012, 03:20:31 PM
 #54

Yes, please... if one of my units fails or otherwise goes off line, it basically brings the entire cluster down... very annoying.  

this is exactly what I wanted to say

Guys, as a temporary workaround, you can wrap your cgminer call in a .bat file (Windows), or the Linux equivalent. Something like this (again, Windows code):

Code:
:loop
cgminer <your parameters>
waitfor /t 10 signame
goto loop

If cgminer quits for any reason (such as a Single going offline), the batch file will pause for 10 seconds (adjust this to whatever you want) and then runs cgminer again. If you ever want to stop the infinite loop and get out of the batch file, hit <ctrl-c> and answer 'y' to the prompt that appears (again, Windows).

Epoch, cgminer crashes.  If process is still running, your script will not work.
It will only work when cgminer quits gracefully or calls exit()/abort().
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
May 02, 2012, 03:41:18 PM
 #55

Yes, please... if one of my units fails or otherwise goes off line, it basically brings the entire cluster down... very annoying.  

this is exactly what I wanted to say

Guys, as a temporary workaround, you can wrap your cgminer call in a .bat file (Windows), or the Linux equivalent. Something like this (again, Windows code):

Code:
:loop
cgminer <your parameters>
waitfor /t 10 signame
goto loop

If cgminer quits for any reason (such as a Single going offline), the batch file will pause for 10 seconds (adjust this to whatever you want) and then runs cgminer again. If you ever want to stop the infinite loop and get out of the batch file, hit <ctrl-c> and answer 'y' to the prompt that appears (again, Windows).

Epoch, cgminer crashes.  If process is still running, your script will not work.
It will only work when cgminer quits gracefully or calls exit()/abort().

That is not what I am seeing. I have tried this exact scenario on 4 separate Windows 7/64 machines. When I unplug one of the Singles, cgminer simply quits. Perhaps not gracefully, but it does not hang or lock up. It merely quits ... essentially back to the command prompt. My script then gets control and loops back to re-run it; it has worked fine on 4 different machines.

Some of the recent earlier versions of cgminer used to crash/lock-up. But the recent releases (certainly 2.3.6) do not and merely quit to the command prompt.

I realize that if cgminer hangs, this workaround will not work. The real solution is a fix in cgminer. I offer this looping .bat file as something that may work for some of us (Windows 7 at least, perhaps not Linux ... that's something I cannot comment on).

edit: sorry, Luke, I don't mean to go off-topic here with cgminer comments ... I'll stay back on track with bfgminer! Lips sealed

I haven't 'unplugged a Single' running with bfgminer yet to see how it behaves ... I'll try that this evening.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
May 02, 2012, 04:17:04 PM
 #56

Same with my experience ... cgminer just stops, it doesn't hang... so the batch file idea would work until it's fixed.

How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 02, 2012, 04:19:22 PM
 #57

How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer.
It's polling every serial port every few seconds. Too ugly to put in any sane software, IMO. The real problem for CGMiner/BFGMiner is that the initialization has to happen in a certain order right now, so adding devices later isn't possible. Changing that will require some refactoring.

rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
May 02, 2012, 04:20:54 PM
 #58

How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer.
It's polling every serial port every few seconds. Too ugly to put in any sane software, IMO. The real problem for CGMiner/BFGMiner is that the initialization has to happen in a certain order right now, so adding devices later isn't possible. Changing that will require some refactoring.

I'd argue that this is very acceptable for a dedicated miner, even if it isn't for a non-dedicated miner, therefore I would like the same thing to be implemented in cgminer/bfgminer. It could be an option, such as -S aggressive or similar.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 02, 2012, 04:29:05 PM
 #59

How is Ufasoft handling the hot-plugging? I'd *really* like to see that functionality in cgminer/bfgminer.
It's polling every serial port every few seconds. Too ugly to put in any sane software, IMO. The real problem for CGMiner/BFGMiner is that the initialization has to happen in a certain order right now, so adding devices later isn't possible. Changing that will require some refactoring.

I'd argue that this is very acceptable for a dedicated miner, even if it isn't for a non-dedicated miner, therefore I would like the same thing to be implemented in cgminer/bfgminer. It could be an option, such as -S aggressive or similar.
I was considering a "-S all"; but in any case, hotplug support still requires a refactor of CGMiner's initialization.

Tinua
Hero Member
*****
Offline Offline

Activity: 870



View Profile
May 02, 2012, 05:11:51 PM
 #60

Hi Luke-Jr

Like promise in the cgminer-tread, i make the same test with 15 BFL's.

Thats the result:

http://www.fileswap.com/dl/QELC51peid/bfgminer2.jpg.html

With CGminer runs everything now!

Regards
Tinua
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  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!