Quote from: jedi95 on March 02, 2012, 12:44:30 AM

Quote from: lodcrappo on March 01, 2012, 04:05:52 AM

So finally got around to rolling phoenix2 into BAMT. It seems to work great, nice job.

I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.

Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.

I added simple counters for these and then included them in the results of listdevices, just like 'results' is done. Seems to work fine though I am not sure it's the best way. Could these types of status be added to the official rpc interface?

I have added accepted and rejected fields to the listdevices RPC interface.

The number of shares that were not sent to the server for any reason can be found by:

shares not sent = results - (accepted + rejected)

great, that means we can throw away all the custom stuff bamt used to have to hack into phoenix, very nice. also kudos on using a standard interface.. json/rpc might not be everyone's favorite thing but its a standard and its pleasant to deal with.

the only area where phoenix2 does not now provide as good or better info than other miners is with pool summary data... this isn't something I've ever worried about with original phoenix since it basically supported only the one, or at best a single backup. However now that phoenix2 is supporting lots of backup pools, it might be worth consideration. some sort of "listpools" similar to listdevices that reported per pool info.. accept/reject/connection errors, latency that kind of thing might be nice. If you're interested and it helps, I could hack such a thing together.