[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.