Bitcoin Forum
December 02, 2016, 06:18:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 244908 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
March 28, 2013, 12:08:49 AM
 #681

WR703N != Avalon

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.
Thanks for testing! Can you elaborate on specifically how it is bricked? Were you able to communicate with it at all?
Failsafe is actually using the firmware, so if that works it suggests some kind of config conflict..

1480702685
Hero Member
*
Offline Offline

Posts: 1480702685

View Profile Personal Message (Offline)

Ignore
1480702685
Reply with quote  #2

1480702685
Report to moderator
1480702685
Hero Member
*
Offline Offline

Posts: 1480702685

View Profile Personal Message (Offline)

Ignore
1480702685
Reply with quote  #2

1480702685
Report to moderator
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480702685
Hero Member
*
Offline Offline

Posts: 1480702685

View Profile Personal Message (Offline)

Ignore
1480702685
Reply with quote  #2

1480702685
Report to moderator
1480702685
Hero Member
*
Offline Offline

Posts: 1480702685

View Profile Personal Message (Offline)

Ignore
1480702685
Reply with quote  #2

1480702685
Report to moderator
1480702685
Hero Member
*
Offline Offline

Posts: 1480702685

View Profile Personal Message (Offline)

Ignore
1480702685
Reply with quote  #2

1480702685
Report to moderator
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 28, 2013, 12:23:29 AM
 #682

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.
I guess the wiki should be updated to warn people that bfgminer bricks their avalon ...
But then again, why would untested code even be listed on the bitcoin wiki ...
Oh right ... I forgot ... in this thread ...
https://bitcointalk.org/index.php?topic=78192.40

So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.

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
nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
March 28, 2013, 12:26:18 AM
 #683

WR703N != Avalon

WR703N ∈ Avalon
Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
March 28, 2013, 01:14:51 AM
 #684

No network at all. Nothing. Put a network tester on it. Nothing. No dhcp/bootp not activity at all. No response to any of the common ip addresses.

Recovery doesn't need a serial port.

To recover an Avalon.

Shut unit off. Setup a pc. Get a http server running on it. Put known good firmware in root directory of webpage. Setup PC on ip 192.168.1.5. Start a ping to 192.168.1.1 plug cable between pc and Avalon. Power up Avalon. Watch blue led on wrt. When it blinks after 10 seconds or so hold down reset button for 1-2 seconds. PC should be able to telnet and ping to 192.168.1.1

Telnet to device. It's in limp mode.
cd /tmp
wget http://192.168.1.5/firmware.bin
mtd -r write firmware.bin firmware
It will reboot Avalon when done.
Setup as clean Avalon. Avalon up will be back to 192.168.0.100

Connect to default webpage and restore backup settings or reconfigure.

gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2016



View Profile
March 28, 2013, 01:15:26 AM
 #685

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk.
So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.
Luke makes a best effort attempt to support third party hardware which he has no access to, posts the code with appropriate warnings and initial recovery instructions.

How Luke's unrelated efforts which are in cooperation with another hardware vendor are related in anyone's guess.

Good thing Kano's port of BFGMiner to avalon runs perfectly...
nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
March 28, 2013, 01:45:44 AM
 #686

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk.
So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.
Luke makes a best effort attempt to support third party hardware which he has no access to

Yeah, it's impossible to get access to a WR703N and see if the image boots properly.
nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
March 28, 2013, 01:56:58 AM
 #687

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk.
So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.
Luke makes a best effort attempt

Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
March 28, 2013, 02:02:41 AM
 #688

You all are ruthless...

Chill ,the avalons a prototype, and so is anything it's running. It could be as simple and one fat finger somewhere in the code or build config.

I'm just glad I didn't have to get out a EEPROM burner or hot swap flash chips or something weird.

Luke's the only one actually trying to help getting it doing things I'd like to do.

Everyone else just bitches about how they got left out.

No one is willing to test or brick their units. I don't mind. I'm in it for more than mega BTC. In trying to tinker and make it better. I'd really like to get it working well on p2pool.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 28, 2013, 02:12:25 AM
 #689

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk.
So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.
Luke makes a best effort attempt to support third party hardware which he has no access to, posts the code with appropriate warnings and initial recovery instructions.

How Luke's unrelated efforts which are in cooperation with another hardware vendor are related in anyone's guess.

Good thing Kano's port of BFGMiner to avalon runs perfectly...

Joke fail ... there is no port of that rubbish.
Lulz, no one in their right mind would port that piece of rubbish to anything.
There's a reason we don't take code back to cgminer from him, but he attempts to copy copious amounts of the cgminer code to the clone ...
The last biggest section of code from him that went into cgminer was the MMQ driver that didn't even work.
I've rewritten it completely in every aspect of how it works and it of course works better and hashes faster than the MMQ code in the clone ...

Interesting ... to use your words: Luke's best effort attempt ...
... is to brick the Avalon 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
March 28, 2013, 02:16:23 AM
 #690

You all are ruthless...

Chill ,the avalons a prototype, and so is anything it's running. It could be as simple and one fat finger somewhere in the code or build config.

I'm just glad I didn't have to get out a EEPROM burner or hot swap flash chips or something weird.

Luke's the only one actually trying to help getting it doing things I'd like to do.

Everyone else just bitches about how they got left out.

No one is willing to test or brick their units. I don't mind. I'm in it for more than mega BTC. In trying to tinker and make it better. I'd really like to get it working well on p2pool.
Xiangfu wrote the cgminer code changes in the Avalon and he's rewriting it to bring it up to speed with the current improved cgminer code ckolivas has written since then and the much better driver USB code that I've written to replace the rubbish that is still in the clone.
Go discuss with Xiangfu if you want to get somewhere useful with it ...

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

Activity: 1806



View Profile
March 30, 2013, 03:05:25 AM
 #691

How difficult would it be to implement the ability to tie a pool to a specific mining device?(Using backup pools as failiver only for each device)My current method is to run multiple instances with each device on its own instance. It appears I'll be receiving more devices from BFL than I had originally planned, and I'm not sure I want to be running that many instances at once.

My concern is the unreliable load distribution using the various load balancing switches. An unproportionate amount of hashing power given to a pool that's having issues or underperforming could result in a huge loss in mining profit for the day. With ASICs rolling out in mass quantities soon, I predict pool issues are going to climb dramatically.  

Spawning another process in app would prob be the easiest way to go about it, but I'm not sure that would be any better than running multiple instances. I'm really looking for an even distribution of hashrate across pools, and I'm thinking the best way to do that with multiple devices is tie each device to its own pool.

Anyways, am I the only person concerned about even hashrate distribution and pool issues from ASIC rollout?

ASICPuppy.net ASIC Mining Hardware and Accessories - GekkoScience DL580 Breakout Boards are In Stock!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
March 30, 2013, 03:30:11 AM
 #692

How difficult would it be to implement the ability to tie a pool to a specific mining device?(Using backup pools as failiver only for each device)
Probably not too difficult, but it'll be a lot easier when I get to rewriting the work-fetching interfaces to be cleaner.

My concern is the unreliable load distribution using the various load balancing switches. An unproportionate amount of hashing power given to a pool that's having issues or underperforming could result in a huge loss in mining profit for the day. With ASICs rolling out in mass quantities soon, I predict pool issues are going to climb dramatically.
Hmm, you may be right about older pools suffering more from ASICs. Already Deepbit is having trouble keeping up with some faster FPGA farms.
I would recommend picking a couple of pools known to manage with ASIC-like loads to use - pretty much anything with vardiff and (GBT or stratum) should do the job.
Personally, I prefer and recommend Eligius. Besides having originally started the pool, I also maintain the software that keeps it going, and have seen it tested with plenty of hashrate.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 30, 2013, 08:01:11 AM
 #693

...
Anyways, am I the only person concerned about even hashrate distribution and pool issues from ASIC rollout?
You are asking in the wrong thread.
The pool balancing options were written in cgminer - they were just copied to the clone here.
If they aren't working correctly in the clone, then consider that yet another reason to not use a clone, but instead use the original cgminer.

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
March 30, 2013, 01:54:52 PM
 #694

Ignore the troll

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
March 30, 2013, 03:51:29 PM
 #695

The pool balancing options were written in cgminer - they were just copied to the clone here.

Ignore the troll

Were the pool balancing options written by you, or by the CGMiner team? If the latter, then he has a point, and he's not trolling.

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

Activity: 1806



View Profile
March 30, 2013, 03:53:38 PM
 #696

...
Anyways, am I the only person concerned about even hashrate distribution and pool issues from ASIC rollout?
You are asking in the wrong thread.
The pool balancing options were written in cgminer - they were just copied to the clone here.
If they aren't working correctly in the clone, then consider that yet another reason to not use a clone, but instead use the original cgminer.

I primarily use cgminer but I switch back and forth from time to time. I switched to bfgminer when I found out you removed BFL serial-usb support, which broke my instance based load balancing script. Not that I see any problem with libusb, I just needed to change the syntax of my start-up command. This led me to my next issue, cgminer cannot access my bfl devices unless I run as super user. I'll spend some time figuring it out later as I think it's important to have both forks of cpuminer ready to go in the event that one doesn't work properly with BFL ASICs.

Load-balancing options in both forks are uneven and leave much to be desired. I brought it up in September and November in the cgminer thread but I seem to be the only person concerned about even load distribution across pools with ASIC devices. This is what led me to write my script to provide device based load balancing, and I'm just suggesting this would be a good thing to have in the application. I'm not upset, these are open source projects and I appreciate the work you guys have put into them with little to no monetary compensation. You've both advanced mining tremendously over the python based miners I used in the beginning.

On that note, I think it's detrimental to the community that you guys are arguing in each others release threads.  Personally, I'd like to see you guys working on the same branch. If that's not going to happen, why don't you just leave each other alone?

ASICPuppy.net ASIC Mining Hardware and Accessories - GekkoScience DL580 Breakout Boards are In Stock!
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
March 30, 2013, 06:21:43 PM
 #697

I primarily use cgminer but I switch back and forth from time to time. I switched to bfgminer when I found out you removed BFL serial-usb support, which broke my instance based load balancing script. Not that I see any problem with libusb, I just needed to change the syntax of my start-up command. This led me to my next issue, cgminer cannot access my bfl devices unless I run as super user. I'll spend some time figuring it out later as I think it's important to have both forks of cpuminer ready to go in the event that one doesn't work properly with BFL ASICs.

Load-balancing options in both forks are uneven and leave much to be desired. I brought it up in September and November in the cgminer thread but I seem to be the only person concerned about even load distribution across pools with ASIC devices. This is what led me to write my script to provide device based load balancing, and I'm just suggesting this would be a good thing to have in the application. I'm not upset, these are open source projects and I appreciate the work you guys have put into them with little to no monetary compensation. You've both advanced mining tremendously over the python based miners I used in the beginning.

On that note, I think it's detrimental to the community that you guys are arguing in each others release threads.  Personally, I'd like to see you guys working on the same branch. If that's not going to happen, why don't you just leave each other alone?
For not running as superuser, see Here. Worked for me.

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

Activity: 2086



View Profile
March 30, 2013, 06:57:35 PM
 #698

The pool balancing options were written in cgminer - they were just copied to the clone here.

Ignore the troll

Were the pool balancing options written by you, or by the CGMiner team? If the latter, then he has a point, and he's not trolling.
Nice try removing the rest of kano's troll.
The pool balancing stuff was written by Con Kolivas, including all the bugs which CrazyBlane is concerned about.


On that note, I think it's detrimental to the community that you guys are arguing in each others release threads.  Personally, I'd like to see you guys working on the same branch. If that's not going to happen, why don't you just leave each other alone?
I proposed a truce to Kano a month or two ago, that if he stopped trolling and FUD all over BFGMiner, I'd just ignore cgminer. He flatly refused.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
March 30, 2013, 11:26:57 PM
 #699

Code:
bfgminer version 2.99.2 - Started: [2013-03-30 23:37:17] - [  0 days 00:01:57
------------------------------------------------------------------------------
 5s:17.85 avg:16.58 u:14.26 Gh/s | A:342 R:0 S:0 HW:0 U:179.6/m
 ST: 2  DW: 10  GW: 3  LW: 494  GF: 0  NB: 1  AS: 0  RF: 0  E: 2.08
 Connected to 192.168.1.1 diff 8 with stratum as user test
 Block: ...ee2e8a72 #3123  Diff:153  Started: [23:37:17]  Best share: 528
------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BFL 0:  45.0C         | 17.83/17.52/14.58Gh/s | A:343 R:0 HW:0 U:180.16/m
------------------------------------------------------------------------------

 [2013-03-30 23:38:52] Stratum from pool 0 requested work update
 [2013-03-30 23:38:52] Accepted 0ecf365f BFL 0  Diff 17/1
 [2013-03-30 23:38:53] Accepted a91d942c BFL 0  Diff 1/1
 [2013-03-30 23:38:53] Accepted 15d55ee2 BFL 0  Diff 11/1
 [2013-03-30 23:38:53] Accepted be2972c6 BFL 0  Diff 1/1
 [2013-03-30 23:38:53] Accepted 9e87d2fd BFL 0  Diff 1/1
 [2013-03-30 23:38:53] Accepted 7f854200 BFL 0  Diff 2/1
 [2013-03-30 23:38:54] Accepted 03c5d641 BFL 0  Diff 67/8
 [2013-03-30 23:39:08] Accepted 040aab96 BFL 0  Diff 63/8
 [2013-03-30 23:39:09] Accepted 14997fe3 BFL 0  Diff 12/8
 [2013-03-30 23:39:10] Accepted 123ded4b BFL 0  Diff 14/8
 [2013-03-30 23:39:11] Accepted 0453e37f BFL 0  Diff 59/8
 [2013-03-30 23:39:14] Accepted 06bd2321 BFL 0  Diff 37/8

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
March 30, 2013, 11:28:44 PM
 #700

Nice to see the SC hashing with BFGMiner, Luke.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
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!