|
I don't think it is so inefficient, in the start I think it was designed to be FPGA and ASIC resistant although if something is worth enough then it will be developed. It has to have a lot more memory on die to do the calcs and that introduces a bottleneck accessing memory. I am just guessing but sha256 may not require so much memory everything can be built out of logic gates and there for higher speed. I think (or thought) I read that an scrypt hash engine requires at least 1mbit of memory and chips now a days have 100+ engines while 100Mbit of memory is not a lot it may take a lot of die space to put 100 engines and 100 separate pieces of memory and interface all that out the chip. Could be way off on all this just my guess.
|
|
|
|
What will happen on Oct. 24. Is there a feature that will be activated or is just a block that has to be passed. Due to all the trouble in the last days with this coin I get a bit nervous with with new features. So dev, what will happen on this day? Most of the nodes are still on 1.5. Do we have confidence there will be no mess again? Please give some explanation and ensure we do not face again the same problems. I get a bit tired loosing coins all the time!
Yes exactly, we can repeat the recent situation. Those who do not update the wallet 0.12.1.6 will no longer mining a coin and the wallets will not be synchronized. If you are a miner and worry, use at this period http://pool.eternity-group.org/ everything is prepared there. I'm not a miner and I have updated my wallet yesterday already. I was just asking what is planed for the 24th. Will the new wallet just reject connections with the old nodes and what will happen if the current status of only 20% on 1.6 remains till this date. We will have two chains and the old one will be the stronger, so I see again a potential fork in the wrong direction. What you should probably do is to ensure that all the exchanges have version 1.6 by Oct. 24, so users will need to move to this version, too. I would also recommend to put the mandatory update also in red in the OP. What also helps is to send PMs to the active users in this thread. It is a bit more work, but is very effective. In my opinion you have to have most of the user on 1.6 before that date, otherwise who knows where this will end. What I saw just 2 days ago was a rewind and overwriting of the chain for 3 days in the past, while all the time connected to the explorer and listed there as a "proper" node. After the rewind all the transactions and moved coins were gone. I'm not sure if you or someone else made the fork and the overwriting, but I really do not wish you to compete with a off-chain (in your opinion) that is stronger then yours. One last remark on the block explorer. Please this one is always on the right chain and height, so user can check their wallets and be sure they are on the same (right) one. I agree, I don't want another sad day of loosing... |
|
|
|
Guys, do we have again a fork  I was using till yesterday 12.1.5 and installed today 12.1.6. I'm aligned with the explorer and hope it is the right chain. Before that I had with 12.1.4 up to 3 different chains and the strange point is I got them all after deleting everything and downloading from scratch (just did it 3 times I a row) !?!? In my opinion this was due to a heavy miner working on a off chain. I really hope with the last wallet version everything will be stabilized. I find the whole situation odd as well, it makes me think 3 as well one old and two new, my question what made the chain I was on be bad after so much time. I saw hundreds of masternodes on the wrong chain with me and oddly enough almost the same number on the "correct" chain now. I had 3 nodes on the wrong chain , all I had fresh blockchain downloads seems strange that all 3 in different locations on the earth would have wound up on the same wrong chain. I though I was doing good, saw the new release and got my nodes going and was making so much just due to not everyone catching it so quickly then loosing 700 or so coins 2 days later kind of a bummer. Looking back at a lot of those blocks there are a few addresses that did pretty well during that time, may have been a pool or something maybe someone saw they were about to loose and was able to plow it ahead and win , not sure. |
|
|
|
|
I will download this and just see, I find it amazing that two chains were able to co-exist for so long and make 100s of block then go back. What determines which chain becomes the master and why did it take nearly 2 days .
|
|
|
|
|
so how many were lucky enough to be on the right chain and not loose out today?
|
|
|
|
|
Thanks , strangely I have done that 20 times I finally got one node to sync so I went off it, most haven't updated of course and are stuck.
|
|
|
|
|
Got the new wallet but not syncing past 212440.
|
|
|
|
Man talk about cheap or cutting corners i had to open the controller mine came with the RPI b not b plus or 2b but mine was rusting and old the pins on the SD slot were bent to the point the only SD it worked with was the one it came with and that was hard to get it to boot or the only one that would boot the miner with any image i found so far that works on the A4 ... .. good fpr me thu i had a b i don't use any more with no bent pins on the SD slot, and no rust ... I put it on the addon board it booted up no waiting sad thu i'm gonna figure out or try to plug a RPI 3 or any PI into the board , the add on board on the RPI b is all you really need. my other question is there any open Source Software for that version of CGMINer ? and i wish BFG worked with it , i know it doesn't ... just got my first A4, thing is loud, something i wont be running at nite glad for me it's just hobby right now..
my question now has anyone come up with a quieter fan ?. All ready like it but the nosie gonna have to either find quieter fans or build something around it...
Not that I know of. The specs on the fan are 200CFM, so as long as you can vent 200CFM through the rig you should be able to replace with ducting or other forced air. so im guessing it can be watered cooled if you want to go that route and have some heat sinks made, the boards from what i saw are your normal type hash boards not like the miners bitmian put out after the S5 ... I didn't open the miner and have no plans to till the warranty is up . only went by pictures i saw ... No they still use the old Pis, they have to be the version 2 of the B . one of mine only has the BCM chip and ethernet controller, they left off everything else, no usb jack , power , etc, and yes all of mine are rusty. As as for making it work on a newer version, well it wont work out of the box, it will have to be recompiled due to the bcm2708 libraries needing to be different , not to say it cant be . I have been allowed to get the source code and were working on making them work a lot better myself and another person have made some good progress. AS far as the fans , yes they are loud but I put some dc-dc converters on them dropped them to about 8volts and they are a lot more tolerable , it only changed the CFM about 30% and they run only about +5c higher. I guess I can ask what would people like to see in this, things we have done so far is make them a lot more stable and done the xnsub addition. While it would be neat to water cool them I'd say be more hassle than good, although I have though about it. |
|
|
|
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. So in summary you are saying that this reboot issue isn't going to be fixed by a new version of the SD Card software and clearly Inno knows about this issue because they coded the boards this way, is that correct? I've done everything short of creating a youtube video demonstrating the problem and so far the only response I get from Inno is denial of the problem or to completely ignore it and blame something else. Thanks again for your work and efforts on this, I hope you can bring something to the table that fixes or improves the operation of these A4's for all of us. No it is going to be fixed, the latest version has the reboot thing commented out so it was there , a lot of this is speculation as to why on my part but oh well. I can say it will be a lot better that is for sure, the latest version we are working with is a lot better off, right now doing some side by side comparisons to see over time making a judgement over a short time of hashing can be misleading. Jarrid |
|
|
|
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. |
|
|
|
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   |
|
|
|
Hi all,
Long time no see.
.
.
.
Performance improvement on Nicehash
We have shipped a test miner to Nicehash and opened source to them to help improve the performance of A4 on NH. We will let you know the update.
.
.
.
Thanks for your understanding and support!
Inno Support Team
Hello Innosilicon, what is the update from Nicehash? What settings should I be using suitable for Nicehash? ThanksIt will be interesting to see what they come up with, I have contacted Inno and them about the drivers, I guess I am glad they let someone look at it, I was hoping to get a shot but oh well. I updated my boards to B3 myself and was hoping for a better luck, which over all they are better but still not good. I have went and patched the cgminer binary, for some reason no one has been able to tell me was why the cgminer took so long to run if you just started it, turns out there is a sleep(9) first thing in main, why is it there , who knows changed it to a 0 and works just fine, got wondering why ./cgminer --help took 10 seconds to run. Another thing is the reboot on slightest problem, I changed the /sbin/shutdown binary to just do a sudo pkill cgminer, the only thing is you have to run cgminer command line and in a while loop but it restarts, but normally when it dies like this you have one more more hash boards that are going to act up ... so the next thing was to solder a wire to the MCU reset and tie them to a pin on the rPi that hardware resets them as well, seems to help some but still testing.. Only being about to poke around in assembly is a real bummer, unless there is just a simple answer everyone has overlooked I wonder if it is going to be easily fixable, sure it will mine LTC and other slow block coins one at time. I just wish a bit more thought had went into some of this, I wish you could specify the voltage per board not as an over all, most of my units just need one board to have a little more but when you do them all you are wasting some power on the others. Jarrid |
|
|
|
I hope so to, they did reply said whoever had the jig now was having to make repairs to it and it would be a while, already a month later than expected, the batch 3 boards I do have work better but still not happy , made some hardware mods and some software mods as well to make it a little better but still no where like they claimed.
They said they still are not sure on letting the driver code out, so I guess we will chug along with what we got.
I don't understand the thought to make the machines reboot in a stratum disconnect.
From my observation they have a script that reboots the Pi any time it see's 1 Get Failure. I haven't had time to chase/find it yet though but I can confirm it does it consistently. I've got a 3rd A4 cube coming that is supposed to be batch 3. Hopefully that gamble pays off when they fix the stability issues. Well batch 3 is better however I have made some modifications, I replaced /sbin/shutdown with another a file that does a hardware MCU reset , had to wire that in along with a sudo pkill cgminer to kill cgminer off, all of the stuff in ran in a do loop do it instantly restarts, well nearly for some reason the cgminer binary takes 10 seconds to start now for some reason. I have been unable to flash my own boards from batch 3 firmware that I pulled to my batch 2 cards just get a quick sharp LED flash, dont know the error of my ways, the jig is a month late or so , needless to say I am a bit sad |
|
|
|
|
I hope so to, they did reply said whoever had the jig now was having to make repairs to it and it would be a while, already a month later than expected, the batch 3 boards I do have work better but still not happy , made some hardware mods and some software mods as well to make it a little better but still no where like they claimed.
They said they still are not sure on letting the driver code out, so I guess we will chug along with what we got.
I don't understand the thought to make the machines reboot in a stratum disconnect.
|
|
|
|
|
Cool that is nice, I just wish I could get mine updated to Batch 3.. these units are driving me nuts!
|
|
|
|
|
I see two plans here depending on what you have access to.
If you can get an static IP at the data center you would need another PC or router and switch to bridge between you can the miners. You could set up and VPN on the router you could connect to and have access to the network behind them.
If your miners just get a private IP and you don't get the ability to set up anything else , if you had a static IP or at least something you could use a dynamic DNS on the outside you could set the miners to use say OpenVPN and have it start, each miner open a VPN to the outside world where you could connect to it as well.
And you could combined them if you could add a switch and router but don't get a outside IP then you can have the router build a VPN to an outside device and go from there.
Maybe this helps some, kind done a little of both.
|
|
|
|
Thank you all for your support and attention. A4 belongs to all of you. After the A4 Dominator comes out, we will offer a A2 Terminator and Farmboy miner replacement program so that our loyal customers can continue to benefit. The A4 Dominator will continue the A2 Terminator legacy in serving our mining community! Thank you. Innosilicon Marketing www.innosilicon.comHoly crap! Totally missed this... I wonder if this promise will be fulfilled like the A4 open source software promise...
Thanks for your kindness! We've decided to open source the software after internal discussion. Please stay tuned.
Yea I had forgotten this as well, I hope they open source something, this new cgminer on the A4s makes me sad, still dont have mine all upgraded to batch 3 yet. shesh Has anyone set their miners up for outside remote access other than through RDP type connection to another computer on the network? How did you set up password protection? Newbie Linux user here. Thanks, G
Well just taking a stab your a long way off from an easy answer, unless there directly connected to the internet which would be pretty bad since everyone knows the default passwords and such, they will be behind a firewall of some kind which you will need forward ports, or setup and use VPNs . I use a VPN to connect back to my network where I can get to whatever I need to. |
|
|
|
|
Any latest word on where the jig is? of course that may be to open of a question, I am just anxious to get it.
|
|
|
|
Just had a second order arrive today and one of the boards is not showing up on the miner. So I have an email off to Eastshore to see what they are going to do to address this. Not to happy right now.  UPDATE: Found the problem, loose cable on one of the controllers. Second unit now has all boards hashing. However this second unit appears to run much hotter temps than the first unit I received. Will have to monitor. Watts used at the wall are 384w Cool, I find it amazing that out of no where a miner shows up using less than 1/2 the power of the best thing going. And you can carry on a conversation in the same room... No hearing loss required with the L3. LOL  I changed the diff setting on the L3's to vardiff and they seem to be hashing a little bit better. So the only setting I needed on Prohashing was the h=3. So far so good. The L3 hashes better than my A4's did for me. So I am pretty happy about that. I may get mine updated to batch 3 then sell them off, even at a small loss sell 3 get 2 maybe I don't know. I just find it interesting that there was that much of a breakthrough. |
|
|
|
Just had a second order arrive today and one of the boards is not showing up on the miner. So I have an email off to Eastshore to see what they are going to do to address this. Not to happy right now. UPDATE: Found the problem, loose cable on one of the controllers. Second unit now has all boards hashing. However this second unit appears to run much hotter temps than the first unit I received. Will have to monitor. Watts used at the wall are 384w Cool, I find it amazing that out of no where a miner shows up using less than 1/2 the power of the best thing going. |
|
|
|
|
Show Posts
