Accepted Shares calculation in History tab is wrong if using both GPU and ASIC

[murraypaul]

The calculation of the accepted shares variable adds up shares for all devices with the same device index. However, if you have two different types of devices (in my example, a GPU and a BE), they are each device index 1, so the display shows that each of them have an accepted shares value that is actually the sum of both devices.

Example:
15/10/2013 00:15 15/10/2013 00:22 Megacoin MEC .00007879 .00007879 30 7.31 minutes #1
15/10/2013 00:15 15/10/2013 00:22 Bitcoin BTC 1 1 30 7.26 minutes #1

I think that lastAcceptedShares needs to be indexed on both device id and device kind.

[nwoolls]

Hi there. The lastAcceptedShares dictionary uses absolute indexes for the devices. What makes you think that you have two devices with the same index? The specific code that stores the value in lastAcceptedShares is below and you can see it is using the index of the row in the grid:

lastAcceptedShares[rowIndex] = deviceInformation.AcceptedShares;

[murraypaul]

I have verified this in the debugger (using current GitHub master), and there is a bug in the display of accepted shares in the history tab, but it is not quite as I described it, both devices are listed with the number of shares of the first device (GPU), not the total of both.
The devices are created with BE having a deviceIndex of 0, and GPU having a deviceIndex of 1.
However, in CreateMinerConfiguration, the GPU deviceIndex is rebased, so that both devices now have a deviceIndex of 0.
When LogProcessClose is called, they both have a deviceIndexes list with one item, value 0.
Therefore, in CalculateAcceptedSharesForProcess, they both have the same index into lastAcceptedShares, and so both receive the same number of shares.
In my test, the GPU had 19 accepted shares, the BE had 10, but both were displayed with 19 in the history log.

[nwoolls]

Thank you for the additional information. From your description I am assuming this is only an issue with USB devices, and that you are using a new version of bfgminer? Can you confirm?

If that is the case, can you please (if possible) see if this issue happens with bfgminer 3.2.1 (instead of 3.3.0) or cgminer? If my hunch in correct this issue was introduced with new code specifically for bfgminer 3.3.0.

Thanks in advance.

[nwoolls]

Thanks again for reporting this. Just to confirm this issue is specific to bfgminer 3.3.0. It does not exist with bfgminer 3.2.1 or cgminer. It is due to recent changes to MultiMiner to deal with changes in bfgminer 3.3.0.

This should be addressed now, specifically in commit 4379a8a