Quote from: cscape on March 18, 2014, 08:17:42 AM

Quote from: Taugeran on March 18, 2014, 08:00:35 AM

Code:

[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: SEND version
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV hwerror 0
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV job 67 5327f8d0 0
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV needwork 3
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV hwerror 1
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV hwerror 2
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV job 69 5327f8d1 2
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV needwork 3
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV hwerror 3
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV hwerror 4
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV job 6c 5327f8d3 4
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV needwork 3
[2014-03-18 07:42:47] bifury fd=8: DEVPROTO: RECV version 1.2 rev 1 chips 2

Ben the preceding is a snippet of a log from bfgminer run with --device-protocol-dump

it is plainly clear that the firmware shipped on the OSM boards is hard coded with a response the version command. if this is so and you have access to the source it would need modified to 15. if not could you request cscape recompile a fw specifically for the OSM boards with this modification.

Following this post, i will be trying to hack together a modification to bfgminer's Bifury driver to see if this fixes the poor performance.

the issue lies in the way bfgminer uses the FW response to VERSION to allocate and setup the queue. since it replies only 2 chip in the response the other 12 are left hungry as f*** and any values they find arent being logged since as far as BFG knows they dont exist

We'll change the firmware, but note that the 'chip' parameter was never intended to be used to calculate work load. Instead, if the board requires more work, it sends the 'needwork ' command to the miner. This is a much more accurate representation of exactly how many jobs are required by the firmware to ensure smooth mining.

Yea I'm still trying to work out the fundamental differences between cgminer BXF driver and bfgminer BIF driver.

I'll be quite honest bfgminers BiFury driver needs a lot of work. Just from looking it seems that on every poll it tells the device to flush, set target, and set maxroll. No idea how much workload that is on the PIC but I'm sure several times a second can't be light.

TO the drawing board... tonite after work and a few angry orchards