(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64

[Luke-Jr]

I couldn't get my x6500 working with BFGminer  

Tried posting here but seems that no one had any info/help.
Luke mentioned trying a different usb driver.  Still didn't help me.  Seems BFGMiner will occasionally start communicating with my x6500, but gets thru a bit of programming the firmware and then BFGMiner crashes.  Sometimes it gets thru programming it 100%, then it crashes.
Lots of times it will fail on a JTAG detect. I think the JTAG detect code needs some work.

I've been told the x6500 support is still new?  So not too much help abounds there.

Spent several hours doing trial and error, nothing worked. We're probably missing something. Tried the original x6500 usb driver and the one found here http://sourceforge.net/apps/trac/libusb-win32/wiki. Gave up and went back to MPBM for the x6500s.

You need to be using the latest WinUSB driver. https://github.com/pbatard/libwdi/wiki/Zadig#wiki-Basic_usage (see Options menu if it doesn't show X6500s)

[1714030856]

1714030856

[1714030856]

1714030856

[1714030856]

1714030856

[TheLQ]

Now that I'm passed the stupid newbie filter, I can actually post this bug report

I am noticing a slight decrease in processing power from one of my cards, a Radeon 5770 after upgrading from 2.8.2 to 2.9.2. No settings or configuration changed between upgrades. After seeing the drop I tried messing with the intensity which didn't work

Here's the annotated image I created when I wanted to post this originally

http://imageshack.us/a/img254/5483/minerhashesday.png

With that blip in mind lets look at the most recent weekly report

http://anonymouse.org/cgi-bin/anon-www.cgi/http://img23.imageshack.us/img23/5756/minerhashesweek.png

Something seems to be wrong as I've lost performance ever since upgrading and will continue to loose performance. Is there something I've done wrong or is this a known issue somewhere in this 21 page thread?

[Luke-Jr]

Now that I'm passed the stupid newbie filter, I can actually post this bug report

Bug reports really belong on GitHub Issues

I am noticing a slight decrease in processing power from one of my cards, a Radeon 5770 after upgrading from 2.8.2 to 2.9.2. No settings or configuration changed between upgrades. After seeing the drop I tried messing with the intensity which didn't work

There were a couple of subtle changes to the OpenCL driver between 2.8 and 2.9. We could try bisecting the difference if you have time, but with the reward halving coming up in 2 weeks, I'm not sure it's worth it. If you want to do this, let me know in an Issue (since the bisect will probably take a while, best to track it there)

[RoboCoder]

Still cant get my x6500s to work.

Using -D -d? -T

 ..SNIP..
 [2012-11-11 16:54:59] ft232r_scan: Error opening device: LIBUSB_ERROR_NOT_SUPPORTED                    
 ..SNIP..

4 x6500s, 1 BFL, 2 GPUs
Win 7 64

I am getting the exact same thing with my Win 7 64.  I have 4 7970 GPU's and was trying to get one of my x6500's i just got to work.

I have tried all the suggestions also.

I will look at my winusb driver to see about the version number -

Thing is - i can't get the MPBM to work either - i am getting a device ID not set  and when I can fiddle with the software past that - i get errors about the proxy shutting down.

One thing i will say for my BFL's i have on another machine - they did truly seem to be plug and play.

Anyway based on other messages - i see problems seem to occur when using win7 64 - possibly the problems are issues due to 64 bit drivers and not 32 bit.  Really not sure.

I would be happy using the mpbm but having a lot of problems getting it configured also - can't get the web interface to show up properly in ie or firefox - had to use chrome to see it properly.  Really the fpgamining site is a little thin on documentation, examples etc.   I would appreciate any help on at least getting mpbm working..  But would MUCH rather be using BFG..

Thanks,
RoboCoder

[jddebug]

I battled windows issues for months and lost a lot of btc in the process. I FINALLY gave in and tried linux. I've had NO problems since. How I wish I'd tried it earlier.

Still cant get my x6500s to work.

Using -D -d? -T

 ..SNIP..
 [2012-11-11 16:54:59] ft232r_scan: Error opening device: LIBUSB_ERROR_NOT_SUPPORTED                    
 ..SNIP..

4 x6500s, 1 BFL, 2 GPUs
Win 7 64

I am getting the exact same thing with my Win 7 64.  I have 4 7970 GPU's and was trying to get one of my x6500's i just got to work.

I have tried all the suggestions also.

I will look at my winusb driver to see about the version number -

Thing is - i can't get the MPBM to work either - i am getting a device ID not set  and when I can fiddle with the software past that - i get errors about the proxy shutting down.

One thing i will say for my BFL's i have on another machine - they did truly seem to be plug and play.

Anyway based on other messages - i see problems seem to occur when using win7 64 - possibly the problems are issues due to 64 bit drivers and not 32 bit.  Really not sure.

I would be happy using the mpbm but having a lot of problems getting it configured also - can't get the web interface to show up properly in ie or firefox - had to use chrome to see it properly.  Really the fpgamining site is a little thin on documentation, examples etc.   I would appreciate any help on at least getting mpbm working..  But would MUCH rather be using BFG..

Thanks,
RoboCoder

[RoboCoder]

Worst part is - it probably is something really simple.  We know it does work with BFG/Win - but it is going to be a windows config issue.

Also - another interesting thing is that originally i had the x6500 showing up in device manager as a LUBUSB device - now when I plug it in - i just get a COM6 show up. 

Anyone know which should i be seeing, the libusb device or the com port?   Either way i still got the LIBUSB error - i never got passed that like some to the bitstream/FW load process in BFG - BFG doesn't show the device at all.

I battled windows issues for months and lost a lot of btc in the process. I FINALLY gave in and tried linux. I've had NO problems since. How I wish I'd tried it earlier.

Still cant get my x6500s to work.

Using -D -d? -T

 ..SNIP..
 [2012-11-11 16:54:59] ft232r_scan: Error opening device: LIBUSB_ERROR_NOT_SUPPORTED                    
 ..SNIP..

4 x6500s, 1 BFL, 2 GPUs
Win 7 64

I am getting the exact same thing with my Win 7 64.  I have 4 7970 GPU's and was trying to get one of my x6500's i just got to work.

I have tried all the suggestions also.

I will look at my winusb driver to see about the version number -

Thing is - i can't get the MPBM to work either - i am getting a device ID not set  and when I can fiddle with the software past that - i get errors about the proxy shutting down.

One thing i will say for my BFL's i have on another machine - they did truly seem to be plug and play.

Anyway based on other messages - i see problems seem to occur when using win7 64 - possibly the problems are issues due to 64 bit drivers and not 32 bit.  Really not sure.

I would be happy using the mpbm but having a lot of problems getting it configured also - can't get the web interface to show up properly in ie or firefox - had to use chrome to see it properly.  Really the fpgamining site is a little thin on documentation, examples etc.   I would appreciate any help on at least getting mpbm working..  But would MUCH rather be using BFG..

Thanks,
RoboCoder

[Luke-Jr]

Worst part is - it probably is something really simple.  We know it does work with BFG/Win - but it is going to be a windows config issue.

Also - another interesting thing is that originally i had the x6500 showing up in device manager as a LUBUSB device - now when I plug it in - i just get a COM6 show up.  

Anyone know which should i be seeing, the libusb device or the com port?   Either way i still got the LIBUSB error - i never got passed that like some to the bitstream/FW load process in BFG - BFG doesn't show the device at all.

WinUSB (the correct driver) is neither libusb nor emulates a COM port.

[n4l3hp]

Using the WinUSB driver link that Luke posted, I was able to make the x6500s work with bfgminer. My only problem now is with 2.9.2, one will get declared as sick after 10 mins or so, then the other ones will follow at random after a few minutes. Version 2.9.1 seems to be working fine but the devices will only operate at 375MH/s +/-, and sometimes the performance will slowly drop and not recover when I use the computer for browsing and other simple tasks. The only thing that can be done is restart the miner.

As Luke said, download Zadig, the installation GUI for the WinUSB driver. Under the options menu, select "List all Devices". Your USB devices will then appear on the drop down list. Find the x6500 FPGA Miner. Select WinUSB driver. The big button at the middle will display "install, reinstall, or replace" depending on the state of your driver. Click to install the driver then restart computer after installation. Using -D -d? -T, the serial number of the x6500 should now show up during the ft232r_scan.

[Luke-Jr]

My only problem now is with 2.9.2, one will get declared as sick after 10 mins or so, then the other ones will follow at random after a few minutes. Version 2.9.1 seems to be working fine but the devices will only operate at 375MH/s +/-, and sometimes the performance will slowly drop and not recover when I use the computer for browsing and other simple tasks. The only thing that can be done is restart the miner.

Someone else reported this problem, but he couldn't get 2.9.1 to work at all. If you're willing, I'd love to bisect it on IRC sometime.

[n4l3hp]

I didnt do anything special after getting it to work with 2.9.2 though. 2.9.1 ran (except for the previously mentioned issues) fine after that.

I noticed that the dynclock of 2.9.2 seems a bit aggressive. Even though i'm using Thermalright IFX coolers, 2 of the x6500s seem to get sick after 214-218MHz and the other 2 after 206-208MHz.

When i'm using MPBM, I use the overclocker fw for the higher performing pair and the ztexmerge_200mhz on the lower performing pair.

[RoboCoder]

FYI.

Used the winusb driver installer.  Fixed the problem right away!

I got a lot of HW Errors on 2.92 so i tried 2.91 and got almost none - Wonder if it has something to do with the additional information about temps being read from the unit?

On 2.91 i also got a pretty steady hash rate of 375 on the 5s rate, but the hash rate based on accepted shares was much better  than that - it settled out at around 437 MH/s..  so i am sticking with 2.91 for now.

Luke-Jr: is there a way to replace the default programming file in BFG and have it use the overclocker file?  Would it work if i swapped it out with the file from btfpamining?

Thanks
RoboCoder

[Luke-Jr]

Luke-Jr: is there a way to replace the default programming file in BFG and have it use the overclocker file?  Would it work if i swapped it out with the file from btfpamining?

I think the bitstream included with 2.9.2 is the same overclocker one from fpgamining...

[AmDD]

I can confirm 2.9.2 is slightly faster on my MMQs. U used to be about 11.1 or so and is now 11.5, not a major increase but I'll take it!

[RoboCoder]

Luke-Jr: is there a way to replace the default programming file in BFG and have it use the overclocker file?  Would it work if i swapped it out with the file from btfpamining?

I think the bitstream included with 2.9.2 is the same overclocker one from fpgamining...

Fantastic!  Thanks for the info.  Actually they are running really good now on 2.91 and very low hw error count and the hash rate has moved upward to close to 400 per x6500.

Thanks for the help with this and for the BFG in general - send you a nice little donation for the help and for your development work (3 BTC).  My way of saying thanks..

Robo

[Luke-Jr]

NEW VERSION 2.9.3, NOVEMBER 16 2012

I've also bumped the stable release to 2.8.6 including the two fixes relevant to the 2.8.x versions.

Human readable changelog:

• Many stratum bugfixes, including support for fractional difficulties.
• Fix GBT to work properly with very short expiration times.

Full changelog

• Bugfix: Properly process new stratum jobs through test_work_current, even if old shares are still accepted, and copy submit_old flag correctly
• Ensure pdiff 1 is always caught regardless of bdiff precision, and ceil all other cases to ensure we never lose valid shares
• Check against a double for current pool diff.
• Support for fractional diffs and the classic just-below-1 share all FFs diff target.
• Check share target diff for best_share to be calculated when solo mining.
• Store the full stratum url information in rpc_url for correct configuration file saving.
• Put in a hack to prevent dud work from sneaking into test_work_current being seen as a new block.
• Reset the work->longpoll flag where it will affect stratum work items as well.
• Bugfix: Stratum does not guarantee notify messages every minute, so extend timeout to 2 full minutes
• Bugfix: Always honour libblkmaker time limits
• Always (debug)log when stratum template is updated by the pool
• Bugfix: When a stratum connection is interrupted, ensure all work/shares for it are considered stale
• Bugfix: clear_sock should return on socket errors
• Bugfix: Force calculation of work_difficulty since set_work_target fails to consider the pdiff<bdiff difference
• Bugfix: Minimal support for handling real difficulties from stratum server
• Bugfix: Never consider shares to be accepted if the submission response is an error
• Bugfix: Always fail scrypt detection if Stratum is chosen

[n4l3hp]

After 3 days of testing, I get better stability with the overclocker bitstream and 2.9.1 on my x6500s.

[Luke-Jr]

After 3 days of testing, I get better stability with the overclocker bitstream and 2.9.1 on my x6500s.

Any chance we could bisect the SICK problem on IRC sometime?

[vitruvio]

Stats with --scrypt param still wrong for me in  2.9.3.


Regards

[Luke-Jr]

Stats with --scrypt param still wrong for me in  2.9.3.

Is there an issue for this open on GitHub?

[n4l3hp]

After 3 days of testing, I get better stability with the overclocker bitstream and 2.9.1 on my x6500s.

Any chance we could bisect the SICK problem on IRC sometime?

Ran 2.9.0 and overclocker bitstream for 12 hrs, it doesn't seem to affect the performance while using Chrome and other tasks unlike using the default bitstream included with 2.9.0 and 2.9.1 that seem to lower the performance of the FPGAs (not a problem on a dedicated mining machine, of course).

     

I'm thinking that the dynamic clocking of 2.9.2 and 2.9.3 (using the older bitstream doesn't help, still getting SICK and DEAD later on) is probably more aggressive compared to 2.9.0 and 2.9.1.