Prohashing Mining Pool Forums

CritterDog wrote:

vinylwasp wrote:

Steve Sokolowski wrote:
Do you plan to produce better firmware for these miners?

We desperately need firmware for them that resolves the heating issues with work restarts. Perhaps there is a way to fund this effort so the firmware is completed quickly so that everyone involved can install it and get increased hashrate.

Steve, while Inno have implemented some thermal protection with this hardware, I don't think this is the core problem. My Batch 2's are well cooled and as you can see I'm trialing many variations of voltage, diff, Mhz, and G=off, etc. Not one of them seems to run longer than 20-25 minutes before it resets all the cards. One the other hand my Batch 1 miners are very stable. I think it's the version of cgminer they've compiled which is different for every batch.

I have a batch one set but could not make it work on this pool.. Can I ask what settings you are using then I can see if I get the same results as you do.. Thanks

Could you try again today?

Every one of tradewiz's miners suddenly started working at full steam today, after we deployed that "periodic difficulty refresh" fix last night. I think it's just too easy to say that resending the difficulty fixed the problem, which is why I want to see if anyone other than tradewiz sees improved results.

Steve Sokolowski wrote:

CritterDog wrote:

vinylwasp wrote:
Steve, while Inno have implemented some thermal protection with this hardware, I don't think this is the core problem. My Batch 2's are well cooled and as you can see I'm trialing many variations of voltage, diff, Mhz, and G=off, etc. Not one of them seems to run longer than 20-25 minutes before it resets all the cards. One the other hand my Batch 1 miners are very stable. I think it's the version of cgminer they've compiled which is different for every batch.

I have a batch one set but could not make it work on this pool.. Can I ask what settings you are using then I can see if I get the same results as you do.. Thanks

Could you try again today?

Every one of tradewiz's miners suddenly started working at full steam today, after we deployed that "periodic difficulty refresh" fix last night. I think it's just too easy to say that resending the difficulty fixed the problem, which is why I want to see if anyone other than tradewiz sees improved results.

Sure I can try again today what should I set it at? Just dynamic?

CritterDog wrote:

Steve Sokolowski wrote:

CritterDog wrote:I have a batch one set but could not make it work on this pool.. Can I ask what settings you are using then I can see if I get the same results as you do.. Thanks

Could you try again today?

Every one of tradewiz's miners suddenly started working at full steam today, after we deployed that "periodic difficulty refresh" fix last night. I think it's just too easy to say that resending the difficulty fixed the problem, which is why I want to see if anyone other than tradewiz sees improved results.

Sure I can try again today what should I set it at? Just dynamic?

Try what he did, "g=off h=50 d=32768."

Steve Sokolowski wrote:

CritterDog wrote:

Steve Sokolowski wrote:
Could you try again today?

Every one of tradewiz's miners suddenly started working at full steam today, after we deployed that "periodic difficulty refresh" fix last night. I think it's just too easy to say that resending the difficulty fixed the problem, which is why I want to see if anyone other than tradewiz sees improved results.

Sure I can try again today what should I set it at? Just dynamic?

Try what he did, "g=off h=50 d=32768."

My A4 just restarted with a dropped card 1 hour ago -- just restarted it with this above string.

Steve Sokolowski wrote:

CritterDog wrote:

Steve Sokolowski wrote:
Could you try again today?
Try what he did, "g=off h=50 d=32768."

I've just restarted 2 miners with those settings Steve. They have -TW at the end of the name.

Steve Sokolowski wrote:

GenTarkin wrote:

Steve Sokolowski wrote:
This is the hacker's way of fixing things when your product is so bad that you can't figure out what is actually wrong. Instead of fixing the problem, simply restart it and hope that it doesn't recur. One would have hoped that a company selling millions of dollars' worth of these things could come up with some idea of what is happening.

hehe, this is how their firmware works too?!?! This is exactly what I worked on beefing up in the Titan firmware. I turned their 8KB watchdog script(mostly useless) into a working and fully featured 66KB script.

Do you plan to produce better firmware for these miners?

We desperately need firmware for them that resolves the heating issues with work restarts. Perhaps there is a way to fund this effort so the firmware is completed quickly so that everyone involved can install it and get increased hashrate.

Well, the least expensive route (for everyone) would be for someone to let me have ssh access to linux that is the "controller"(if thats possible) and I can hunt around. Will be easier and results may be better once they open source the firmware. But if a bash script does the "monitoring" and I have direct access to it and see what else it does... then that would be a starting point.
Beyond that, I dont have a plan to purchase any A4's( big waste on probable 0 ROI). I contacted innosilicon about the possibility of a dev miner and sourcing the firmware to me.... havent heard anything back. =(

GenTarkin wrote:I contacted innosilicon about the possibility of a dev miner and sourcing the firmware to me.... havent heard anything back. =(

We contacted them about the same thing to troubleshoot the pool. They said that due to high demand they had no spare units available, and they offered us $1800 for one cube. I unfortunately think that you will have no more success than we did. We'll never make any ROI at that price, and you can get them $300 cheaper on eBay anyway.

GenTarkin wrote:

Steve Sokolowski wrote:

GenTarkin wrote:

hehe, this is how their firmware works too?!?! This is exactly what I worked on beefing up in the Titan firmware. I turned their 8KB watchdog script(mostly useless) into a working and fully featured 66KB script.

Do you plan to produce better firmware for these miners?

We desperately need firmware for them that resolves the heating issues with work restarts. Perhaps there is a way to fund this effort so the firmware is completed quickly so that everyone involved can install it and get increased hashrate.

Well, the least expensive route (for everyone) would be for someone to let me have ssh access to linux that is the "controller"(if thats possible) and I can hunt around. Will be easier and results may be better once they open source the firmware. But if a bash script does the "monitoring" and I have direct access to it and see what else it does... then that would be a starting point.
=(

I'd give you access but Inno have changed the pi password with the A4 because they were not happy that 'people' (emdje?) had been making changes to the firmware. They've since reviewed that stance and promised to make it OS, but we're all waiting.

I pulled the SD card from one of my 'sick' batch 2 miners running the V1.0.2 firmware today and it looks like they've built the watcher process into cgminer. There's a lot of left over dev detritus in the directory with several files with Tan in the name including versions of cgminer so I'm guessing he's the lead software developer for the A4 release.

The final 2 lines in the StartCgminer.log for today were
[date] Tan Restart by line goto Restart
[date] Tan Return 0

There's not much in /var/logs except you can see that a HUP was sent when it reboots, but the cgminer.log is also interesting.

Is it normal to reinitialize the card (and all 20 Chips/2000 cores) every few seconds? It seems to reinitialize the whole card whenever a core sends an invalid nonce, it gets new work (I can understand that) or when any single core (of 2000) stops working. It's truly every few seconds.

I am back after some days of travelling. I have set one unit on the dev pool please let me know how that goes.
I see the "worker history" chart is pretty much "out there" - all the units except the first batch seems to make the graphs look weird, but it does not matter to me if the hash rate is ok. I guess if the machines reboot every now and then it will take some time for the graphs to "catch up" and show the hashrate?

tradewiz wrote:I am back after some days of travelling. I have set one unit on the dev pool please let me know how that goes.
I see the "worker history" chart is pretty much "out there" - all the units except the first batch seems to make the graphs look weird, but it does not matter to me if the hash rate is ok. I guess if the machines reboot every now and then it will take some time for the graphs to "catch up" and show the hashrate?

Don't worry about using the Dev pool anymore. We released the code to the production pool, so there is no need to use Dev anymore. CritterDog has seen great success with this new code; it appears that simply re-sending the current difficulty periodically causes these miners to restart or do something that prevents crashing. Put all the units on production.

I'll look at these graphs in a few hours and examine them, but when I looked at your miners a few days ago, everything looked perfect. That's why I asked CritterDog how his were doing, and he also reported good performance.