Folk, I'd like to share a lesson's learned that may be useful to others. I have a Z9mini here that I just checked and it has a hash rate of 0. Immediately I went to the logs to see what was going on and found the following: Nov 28 21:33:52 (none) local0.err cgminer[23558]: bm1740_verify_nonce_integrality CRC error. cal-crc=374c, chip-crc=60bf
Nov 28 21:33:52 (none) local0.warn cgminer[23558]: receive a error nonce. total = 8908
Nov 28 21:33:52 (none) local0.err cgminer[23546]: bm1740_verify_nonce_integrality CRC error. cal-crc=ac2d, chip-crc=3f77
Nov 28 21:33:52 (none) local0.warn cgminer[23546]: receive a error nonce. total = 8705
The key here is that these are happening constantly, every second, the count is up to 8000+. (If these are infrequet, every few minutes, to hours, they can be ignored) What's going on? To figure that out, let's take a look at the process list ("System" -> "Monitor")... and what do I find? 23546 23545 root S < 225m 98% 50% /usr/bin/cgminer --version-file=/usr/bin/compile_time --config=/config/cgminer.conf -T --syslog
23558 23557 root S < 257m 111% 40% /usr/bin/cgminer --version-file=/usr/bin/compile_time --config=/config/cgminer.conf -T --syslog
Two copies of cgminer running! How could that happen? The answer is in this little program right here: 1012 1 root S 2152 1% 0% {monitorcg} /bin/sh /sbin/monitorcg
This is a factory process that tries to be a "watchdog" for cgminer and restart it if it is not running. From the factory it ran every 20 seconds, but I modified it to sleep for 60 seconds to try to limit the possibility of this race condition. What happens is if you change frequency or pool configuration, cgminer is stopped and restarted. While that stop/start is occurring, monitorcg has a change to see cgminer is not running and start one itself. End result: Two cgminer's stepping on each other. I may end up removing /sbin/monitorcg from the firmware as I've attempted to fix this particular race a myriad of ways... but when two separate processes (web interface actions and monitorcg) are both touching the same resource ("cgminer"), there is not any good way to prevent them from stepping on each other unless they are talking to each other constantly to achieve what is called "quorum". What's the lesson here? Many times the errors that you may see are a function of this particular race condition.... and if you have two cgminer processes running, the fix is to kill/restart them. The simplest way to do that is ust to go to the frequency page and click submit. That will terminate both cgminers and hopefully restart it before monitorcg tries to help. A guaranteed way to fix it is to reboot, but I am not a fan of unnecessary reboots. Hopefully this bit of information will be useful to someone. I've been meaning to write posts like this explaining various scenarios for a while. Thank you, Jason |
|
|
|
...snip...
Netstat on the machine don't lie about how many times you are trying to connect. Your in and out of dev mode and the callbacks to your server is telling the miner what mode to mine in. More or less the firmware is dependent on the ability to reach your servers and if it don't then it stops mining and the user lost some shares. I ran for hours and it would only mine if it connected to your server at bootup it never went into a bypass mode. Not a smear just the facts about your release.
Thank you for your feedback and I'm sorry the firmware did not meet your needs. Please let me know if I can assist in some manner in the future. Jason |
|
|
|
Thank you for those details. I think I might know what is going on -- can you check your PM and email me at the email address I provided? Once we can get confirmation, I should be able to get this fixed reasonably quickly. Thank you, Jason Ok, this is going to take a little longer. This is Roskomnadzor. I am looking for a workaround. |
|
|
|
Thank you for those details. I think I might know what is going on -- can you check your PM and email me at the email address I provided? Once we can get confirmation, I should be able to get this fixed reasonably quickly. Thank you, Jason |
|
|
|
...snip...
Yes Jason machine never starts mining. And on the "Overview System" tab I have a void
...snip...
Nov 28 15:43:12 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 15:43:12 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 15:43:12 (none) local0.warn cgminer[1002]: bitmain_ZCASH_init
Nov 28 15:43:12 (none) local0.notice cgminer[1002]: No Fan find, check again
Nov 28 15:43:13 (none) local0.notice cgminer[1002]: No Fan find, check again
....snip...
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: Chain 0 existed!
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: Chain 1 existed!
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: Chain 2 existed!
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: chain0 every_chain_reset_PIC16F1704_pic_new
Ok, yeah, I don't think there is much I can do here at the moment. The more complete log does help tell the picture. The fan thread runs asynchronously to the main thread which is why it partially seems to start up. After that, the daemon is stopping and the monitoring process is restarting cgminer. In the future I'm looking to disable the fan check, but at the moment that check is embedded in the main loop of cgminer and not easily modifiable. I will take a look soon and post an update to your PM if I can figure it out quickly. Can you provide more information on the fan cheat? A link to one, or are you willing to provide one? I'm just wondering what they are doing that is not functioning. I have not modified the fan checks at all -- so it should act exactly like the factory firmware from that perspective. Thank you, Jason |
|
|
|
Hi.
Its v2.1 also for payd users?
Thanks
Czepot - it is. Download 2.1 and then use your original download link to get your license file. Once you have installed the image, go to the 'Upgrade' page again (refresh browser cache) and you will see an option to upload the license file. So the steps are: 1) download and install 2.1 2) Use your download link which will give you a custom zip file. Inside that zip file is the license and a readme. 3) On the system upgrade page, upload your license. 4) The system should say "license applied successfully". 5) The Summary/Overview page will update on the next restart or auto-authorization update with your license status. If you don't see it, it's just browser cache again, but I believe I have fixed the browser caching issue on the summary page. It is the same as image#2 on the first page, but I'll put it here, also.  |
|
|
|
Nov 28 14:58:50 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 14:58:50 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 14:58:50 (none) local0.warn cgminer[1010]: bitmain_ZCASH_init
Nov 28 14:58:50 (none) local0.notice cgminer[1010]: No Fan find, check again
Nov 28 14:58:51 (none) local0.notice cgminer[1010]: No Fan find, check again
Nov 28 14:59:55 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 14:59:55 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 14:59:55 (none) local0.warn cgminer[1156]: bitmain_ZCASH_init
Nov 28 14:59:56 (none) local0.notice cgminer[1156]: No Fan find, check again
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: fan-num 1 fan-map 1
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: check_chain
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: Chain 0 existed!
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: Chain 1 existed!
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: Chain 2 existed!
Nov 28 14:59:57 (none) local0.notice cgminer[1156]: chain0 every_chain_reset_PIC16F1704_pic_new
I don't have a fan. I use the immersion liquid for cooling.. On may firmware everything is OK . Your firmware can't find my fan plug (fan cheat).
"No Fan find, check again" is emitted even on machines with fan's connected, at least once. If there is not a success, the miner will not start up the rest of the way and will abort, and yours appears to be going through chain initialization. So that tells me your fan cheat is at least partially working. Or are you saying your machine never starts mining? Jason |
|
|
|
Never said I didn't know what I was doing and never used your work or others besides the factory firmware. As far as the lockout problem your firmware will have the same issue at some point unless you found the cause. By your statements you have had the issue or have helped already. Your fix was just do a recovery but you don't know the cause of the issue as far as I know your explanation on my post was unsure. I forget but in the end you still had to tell them to do a recovery.
I pointed out that I had already included the recovery conditions as a worst case, not that I had seen the issue. I have had to use the recovery exactly once when I bricked my own machine on the very first image I ever made. I was attempting to be polite. Users won't have that issue with my releases unless it is flat out concocted.
You also need to inform your customers that their miner on the current 2.1 version may stop mining if it cant reach your api callback server us-api1.fudd.net or your dev-fee pool zec-bj.ss.poolin.com or they may lose shares on a callback or dev-fee connection error. I did some testing and from bootup for 6 hours and anytime the callback couldnt reach your server or the dev server it gave the error I posted to you in an earlier post it which the kernel log stated that about 100 shares were lost and I stopped mining at different times and eventually would start again. Callbacks seem to happen more then once every 280 minutes also.
To sumit up if your server is down or unreachable the miner may stop mining all servers for a short time and the owner lose shares because of it.
If the authorization server is down, the inability to start is a purposeful design decision. What you are missing there is how that is cached and handled in various failure scenarios and the fact there is regionalization on the API server you have not yet found. You've also not found the downtime mode that exists such that maintenance server-side can occur without downtime to miners. Nor have you found the retry mechanisms to ensure continuity in mining. Instead, you've created fake scenarios without understanding what you are doing. As far as the pool being down, no, you have done something wrong. cgminer will simply find another pool if a pool is unreachable. As far as the callback goes, you are also simply wrong there, too unless you were repeatedly restarting cgminer and purposefully breaking the network. As far as 280 minutes go, you are also simply wrong there as well. In fact, 280 minutes is not even configured at the moment. Paid user callbacks are once a day. Dev user callbacks are once every 2 hours simply for testing purposes (more traffic) and will drop back to once a day by 12/01. As far as your analysis about lost shares, there is a piece you are missing there as well; shares there are not defined as "successful shares waiting to be submitted to the server", but rather the current getwork queue, many of which will be discarded locally since they do not meet the targets.
Enjoy the input
i did! Nice smear attempted though. Jason |
|
|
|
...snip...
any higher on any of the boards I either start to lose hash or get an x the the status. With Jasons version I don't get the x but still lose hash at higher then 656 on any board
If you are "losing hash higher than 656 on my firmware" relative to what you are running, then that is called "placebo". @chipless -- did you figure out what was going on with your firmware bricking (well, locking them out) those 6 miners? At least, I think it was 6 -- one user said 5, the other said 1. I offered to help them via teamviewer but they had downgraded by doing a factory reset using the "bricked miner" recovery process. I think you just said you didn't know what was going on? As numerous customers and users of my firmwares can attest to of their own accord, I go out of my way to ensure satisfaction. Over the weeks I've spent multiple hours working directly with users on their miners to understand and resolve issues and have been incorporating those lessons learned into both my instructions and firmware. Before releasing any firmware, I test it multiple ways, from bare metal installation, to upgrades over other firmwares. I ensure downgrades work properly and that all factory defaults (such as passwords) are functioning as expected. My failure rate with firmware flashes at customer sites is exactly 0. My failure rate with functionality failing to work as expected at customer sites is exactly 0. Caveats to this are a small handful of users that were unable to overclock at all due to hardware limitations; they were the driving force behind my per-hashboard work. For posterity, the issue I have with your actions is posting on this thread about whatever firmware you have cobbled together from other peoples works; release all the firmwares you want on your own time, your own accord, and without any endorsement or indictment from me. Please stop making assumptions about me or about my intentions, and stop with the passive aggressive subterfuge attempts. I'd like to ask you nicely to please stop posting in my thread. I am not interested in having you as a customer in any way, shape, or form. Jason |
|
|
|
This is great. One of my batch 1 minis ran at 750Mhz for a long time before one board started crapping out and i had to run all three at 550Mhz because of that board, so I'm very happy you put this out. Can't wait for the increased frequencies.
@bakermining76 -- hopefully this works for you! The current image stops at 700, even though the frequencies are completely unlocked... I will update the image as soon as I can get feedback from a couple of users with one that lets you select up to 850 (insane, but it was requested). Jason |
|
|
|
Awsome! thanks I'll be glad to be the tester.
kgbtc -- PM sent to you with the updated image; it goes to 850Mhz, please use wisdom with setting frequencies.  Jason |
|
|
|
The AVR is not even a FPGA, it's just a standard CPU...
Aye, I know. .. I'm just trying to figure out some explanation. |
|
|
|
Actually an asic can be used for its non intended purpose.
I have worked in the past on a few projects where the code was rewritten. It doesn't mean you need or use the asic fully but instead use it to assist in your calculations.
I spent 20 yrs working with satellite code and devices where similar ports have been done. One big example would be the Atmel AVR devices. Biggest problem with them was eventually the code got too large for them, where with the antminers you have much more space to use. As I said it is something I am going to look into. It is a theory I am going to look into for a bit. There are many ways to manipulate data and still get the same results for the output.
Jason I am not on no train, I can agree to disagree and can move past it. Fights, arguments and disagreement are part of the world. I will get with you in a pm at some point in the next few days to inform you of a few things I found in your release that you may want to address.
Please do. Thanks. An Amtel AVR is not an ASIC. Are you sure you have not mixed up "FPGA" and "ASIC"? Jason |
|
|
|
I put it on one of them. Is there anyway to go above 700mhz? I would like to test in 5 or 10 mhz increments. Right now at 700mhz they look to be hitting avg 15.35 vs 16.50 on 750mhz which is in line with the stock one.
thoughts?
I've been asked to add in frequencies up to 850 -- I'll do that in my next image, but it will be a few hours at least before I can get it built and put up. When I put the frequencies in there, I failed to adjust them for the mini. Let me get through the family things for the evening then I'll build a new image. Thank you, Jason |
|
|
|
Ok I'll give it a shot!
Thanks,
KG
Cool deal - use the tuning guide I put in the top post as a starting point and please do provide feedback! Jason |
|
|
|
Dumb question but will this increase the hash on Batch 1 mini z9?
Or is this for the new batches 2, 3 etc...
mine are currently all at 750mhz avg 16-17 each.
Thanks,
KG
Try it and see? Folk have been able to squeeze an additional 5% or more using the per hashboard tuning. If it doesn’t work for you, I provide the batch1 image on my website linked at the top of this post, too. -jason |
|
|
|
Glad you got it working. As Jason said it is an issue some have seen after an upgrade. My brother has the same issue on a couple of his after an upgrade of fw..
...snip...
Just for a point of clarity, I did not say that it is an issue some have seen after an upgrade. I said "I cannot see how this would happen", which is very different. |
|
|
|
|
Folk,
If any of you see issues with the firmware returning back to your pool of choice (generally pool0) after the initial 10 minute dev pool cycle, please let me know. I've had a couple of reports of that, but so far cannot reproduce it... and the folk who had it happen cannot reproduce it either (so far).
I'm trying to get a reproducible use case to find and correct the issue.
Thank you,
Jason
|
|
|
|
Glad you got it working. As Jason said it is an issue some have seen after an upgrade. My brother has the same issue on a couple of his after an upgrade of fw..
I am far from an expert on these units and hopefully we can all learn as we move on.
I am looking into trying to port the V9 hashboards to work on z9 machines.....But that is a project that will take some time that is even if it is possible. So I may steer away from this project. If it is possible to do what I want a V9 should produce as much as 3 z9's if it is possible.
Jason you have any thoughts on porting the v9
Are you saying your plan is to take a "v9 hashboard" and make it do "equihash" as a Z9?... I'm just going to assume you are trolling at this point and get off of the chipless train. An ASIC cannot be repurposed like that. Jason |
|
|
|
chipless,
In the future, please try to refrain from posting this much of your log here; Only about 6 lines of that log were needed.
Two things can cause this: 1) network problems, 2) two cgminer processes runing.
1) In your case, the log clearly tells you there were communication errors with the pool. That is a network issue, caveat'd that it could be #2, so check that first. Otherwise, the FIFO queue full message is exactly that. Can’t submit work If the stratum cannot be communicated with.
2) This also happens if two cgminer processes are running which can happen due to a race condition in the factory firmware between /sbin/monitorcg and any operation which calls "/etc/init.d/cgminer.sh restart", which happens when you change frequencies. Solution is just to reboot. Or, for someone such as yourself, observe two are running, kill them via ssh, let one start back up.
3) As far as the fan going high, someone such as yourself should be completely aware of the startup sequence now... it goes low on init, then high until it is fully online, then the temp fan curve control takes over.
4) Please provide your 'Support ID' in the future, located on the Summary page. Using that I can help you better.
Net-net, looks like it is working as expected.
Jason
Gotcha….Thanks for the input.... As far as working on NH I don't think any of the antminers work well there my V9's wont hardly hash on that pool. It is appearing to be that they are more of a gpu mining site and not a site for asics The issue is in the share submission calculation based on nonce1. In various conditions, NH sends a new nonce and the submission should get updated; it does not. Simple as that. It isn't an ASIC vs. GPU thing, it's something wacky that NH does, and something that this firmware doesn't currently handle. Jason |
|
|
|
|
Show Posts
