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

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

BFGMiner uses the chip count only to determine how many chips will be returning submits, not to determine how much work is needed.
Although earlier Bi*fury firmwares were buggy, for which BFGMiner's driver has code to workaround until it receives the first needwork message, but I don't see how that could affect this.

Quote from: Taugeran on March 18, 2014, 10:29:09 PM

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.

No, it only sends these once on initialisation (device open)...
Flushing occurs when there is a work update too.

Quote from: cscape on March 19, 2014, 06:46:55 AM

Also, a low maxroll value is also bad for performance. For instance, with maxroll = 0, a single OSM board needs about 11-12 work items per second to keep busy. And if the boards are chained through the serial link, they could require nearly 200 work items per second. That's a lot. Setting maxroll to 60, only requires 1/60th of the workload, so about 1 work item every 5 seconds for a board.

There is definitely room to improve this, but it wasn't necessary for bi*fury and incompatible with getwork pools.

Quote from: cscape on March 19, 2014, 06:46:55 AM

In addition, it is good to send the pool difficulty to the board using 'target' command, to avoid unnecessary traffic going the other way.

BFGMiner uses diff 1 nonces to provide more reliable statistics.
Perhaps this can be made configurable if there's a need.

As for why it's performing worse, I'd be happy to look into it.
Are you planning to send a sample unit to developers?