Re: A4 Dominator - Pre-Order Group Buy - 280mh, roughly 1000w, $1800 + shipping

Quote from: Eyedol-X on March 14, 2017, 11:29:13 PM

Quote from: mjgraham on March 12, 2017, 04:40:56 PM

I have been running with a local proxy as well mostly so I can get a good hash rate graph. I have been working with Inno to improve the driver along with others. So far I have made some progress with both prohashing and nicehash, although the fixes for nicehash require hardware mods at least with what information I have on the hash board MCU firmware.

I was testing just one hash board but I was able to get 68-72Mh/s on Prohash and mid 60s on nicehash. The problem with nicehash is all the pool changes and stratum disconnects causes the hash board to loose it and some times they don't come back.

I have not heard out of Inno in over a week so I don't know any of their thoughts on the process, I finally got the jig two months later than expected but it was broke but I had already figured out how to flash the new firmware from one board to the another anyway so not as big of a deal.

Anyway just asking does anyone have and odd behaviors I need to look at, I know most of them but I will try to answer what I can and any feature requests, might as well try all of the above

While they let me have access to the cgminer code I am pretty sure it is not what is on 2.0.2 beta, there is no shutdown routine in there and they tried to fix a slow down issue that I don't see a fix for but that is not a problem already worked around it.

I have been using a proxy but that is mostly for switching pools which seems to break them easily and getting a graph on hash rate.

Thanks
Jarrid

Thanks for your work on this, do you have a solution to stop the A4 from rebooting itself any time it sees a get failure?

This issue is really my only issue with it.

Actually the code they shared with me didn't have the shutdown routine in it which shocked me , for some reason had a sleep(9) in the main function, i think they tried the reboot plan is this, when it gets a pool disconnect the boards gets reset during that time the program cant communicate and just goes into almost always a situation it can't recover from so they do a reboot. The hash boards must have some kind of watchdog type thing that after it gets communicated with and stops it resets it's self and by that time the pi should be back up not an efficient plan. I have solved that but it has two outcomes at this point , another flashing for the boards or hardware mods and board flashing which are not super hard but does require soldering.

Since I have made the mods I have been mining Nicehash for 3 days now with no user intervention required, I had been trying to handle different errors differently but now I am thinking any error just reset the board after a little firmware mod instead of taking the board 2~3 seconds to get started it now takes like 0.1 seconds. I dont have access to the MCU firmware code so I dont know if a software update fix only is possible and I may have went overkill but something causes the board to stop talking and from the logic analyzer point of view it *looks* like the hash board is the issue. I dont know if a command is locking the board up I need to look into that a bit more.

My 1 day average on nicehash for 10 hash boards is 642 MH/s so that would make 128.4 MH/s for a 136 unit and 256.8 for a 270. on prohashing it was a bit better , the diff I think gets way to high on nicehash to quickly ,I am seeing 65K on mine I think that is to high and setting it doesn't make any difference.