Ok I'll give it a shot!
Thanks,
KG
Topic: Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini - page 29. (Read 45527 times)
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
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
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
Or is this for the new batches 2, 3 etc...
mine are currently all at 750mhz avg 16-17 each.
Thanks,
KG
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
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
I know on the gpu rigs I have there is a setting in the config you have to change if your on a nicehash server to make it run correct. claymore implemented a fix for it in his gpu releases
My personal review for the new patch and the experience I had with "set freq per-hashboard feature"(I was 4 days in the beta test for the new patch):
VERSION 2.1
Z9 Large(NOT MINI)
I'll start with applauding Jason for his hard work to bring us everything we wanted for our z9 machines and give us what bitmain didn't deliver.
Overall performance of patch 2.1:
This patch seems to work similarly with patch 2.0d with slight advantage in average k/sols overall (in my case the average speed went from 55.61k/sols-55.93k/sols with the same settings)
So its a boost in performance.
Per-hashboard feature:
So I experienced that not all of my asic chains work well when boosted high in freq, but one of them does work better when pushed harder then the rest so this feature is giving me the ability to get the most out of my machine. So to test out how my asic performs i started by setting my global freq to 650 and went from there(so i started at what i thought was the highest my machine would probably go and planned on underclocking everything that doesn't like that freq and overclock anything that is stable).
Results:
1st test(frequencies set to global(global freq set to 650)
asic0 zero-ed out after 14 minutes of mining(that forced me to underclock asic0)
2nd test(this time frequencies set to 643,Use Global,Use Global(global was 650 at that time))
asic0 doesnt crash for 1 day(crashes after one day), asic1 has best hashrate overall, asic2 gives errors in the kerner log and has worst hashrate(i wasnt aware of the kernel log errors at that point)
3rd test(freq set to 637,656,656(so i was still unaware that asic02 was giving errors in the kernel log but the cores were stable and i pushed asic01 and asic02 one step further)
asic0 still crashes once in 2 days but i figured that as soon as the Chip temperature goes over 77'C the asic chain is in danger of zero-ing out and resetting itself(which makes it not work for 1-2 minutes and that doesnt really affect the overall hashrate if it happens once in two or three days. In my case this chain is just hot and is always 3 degrees above the other two. asic01 works perfectly fine at 656, asic02 gives errors but still working on 656 with same stability.
4th test(final one, for now): (i figured that asic02 is giving out errors in the kernel log when set on 650freq and 656freq so i underclocked it to 643, this time frequencies set to 637,656,643)
asic0 same performance, asic01 still performs the best, asic02 stopped giving out errors in the kernel log completely and is now rendering out noticeably better Sol rates.
Average hashrate after 3 days of uptime: 55.93k/sols
Average poolside hashrate after 3 days of uptime: +/- 58.00k/sols
I'm mining Horizen(zencash) on Luckpool.
Conclusion:
My z9 large(might not apply for all of the machines out there) works best when chip temperature is under 77'C, if the temperature goes over that border all of the chips might drop in my scenario at this frequency, so keep your machine in a room that is colder than +/-30'C and everything should work well as this chips dropping to 0k/sols rarely situations are temperature related , at least in my case and experience.
Beside that which is a hardware thing and not related to this firmware, everything works perfectly fine.
Cheers,
Igor
VERSION 2.1
Z9 Large(NOT MINI)
I'll start with applauding Jason for his hard work to bring us everything we wanted for our z9 machines and give us what bitmain didn't deliver.
Overall performance of patch 2.1:
This patch seems to work similarly with patch 2.0d with slight advantage in average k/sols overall (in my case the average speed went from 55.61k/sols-55.93k/sols with the same settings)
So its a boost in performance.
Per-hashboard feature:
So I experienced that not all of my asic chains work well when boosted high in freq, but one of them does work better when pushed harder then the rest so this feature is giving me the ability to get the most out of my machine. So to test out how my asic performs i started by setting my global freq to 650 and went from there(so i started at what i thought was the highest my machine would probably go and planned on underclocking everything that doesn't like that freq and overclock anything that is stable).
Results:
1st test(frequencies set to global(global freq set to 650)
asic0 zero-ed out after 14 minutes of mining(that forced me to underclock asic0)
2nd test(this time frequencies set to 643,Use Global,Use Global(global was 650 at that time))
asic0 doesnt crash for 1 day(crashes after one day), asic1 has best hashrate overall, asic2 gives errors in the kerner log and has worst hashrate(i wasnt aware of the kernel log errors at that point)
3rd test(freq set to 637,656,656(so i was still unaware that asic02 was giving errors in the kernel log but the cores were stable and i pushed asic01 and asic02 one step further)
asic0 still crashes once in 2 days but i figured that as soon as the Chip temperature goes over 77'C the asic chain is in danger of zero-ing out and resetting itself(which makes it not work for 1-2 minutes and that doesnt really affect the overall hashrate if it happens once in two or three days. In my case this chain is just hot and is always 3 degrees above the other two. asic01 works perfectly fine at 656, asic02 gives errors but still working on 656 with same stability.
4th test(final one, for now): (i figured that asic02 is giving out errors in the kernel log when set on 650freq and 656freq so i underclocked it to 643, this time frequencies set to 637,656,643)
asic0 same performance, asic01 still performs the best, asic02 stopped giving out errors in the kernel log completely and is now rendering out noticeably better Sol rates.
Average hashrate after 3 days of uptime: 55.93k/sols
Average poolside hashrate after 3 days of uptime: +/- 58.00k/sols
I'm mining Horizen(zencash) on Luckpool.
Conclusion:
My z9 large(might not apply for all of the machines out there) works best when chip temperature is under 77'C, if the temperature goes over that border all of the chips might drop in my scenario at this frequency, so keep your machine in a room that is colder than +/-30'C and everything should work well as this chips dropping to 0k/sols rarely situations are temperature related , at least in my case and experience.
Beside that which is a hardware thing and not related to this firmware, everything works perfectly fine.
Cheers,
Igor
@ Efudd-I just wanted to say again and again how unbelievably good you are at what you do. This firmware is my birthday all over again. I know a lot of people are saying thank you....but Jason (if that's is your real name 
) THANK YOU!
currently at
Chain# ASIC# Frequency KSol/S(RT) HW Temp(PCB) Temp(Chip) ASIC status
1 16 693 19.25 0 47 67 oooooooo oooooooo
2 16 681 19.90 0 52 72 oooooooo oooooooo
3 16 687 20.56 0 51 70 oooooooo oooooooo
) THANK YOU!currently at
Chain# ASIC# Frequency KSol/S(RT) HW Temp(PCB) Temp(Chip) ASIC status
1 16 693 19.25 0 47 67 oooooooo oooooooo
2 16 681 19.90 0 52 72 oooooooo oooooooo
3 16 687 20.56 0 51 70 oooooooo oooooooo
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
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
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
May be, may be... But Innosilicon A9 ZMaster work very nice and don't have problem vith NH. And profit not bad. Higher more then on different pool.
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
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
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
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
Correct, no Nicehash. I have spent a lot of time on that but now need to work with NH engineering. The action is on my side to do that at this point.
As far as the API goes, HiveOS is correct. On the box I actually insert the frequencies into the API for the web interface. Exporting that off box via the normal API is probably going to be a no. I will add it to the queue and see what I can do there, but the API handling inside cgminer is a mess of spaghetti.
Thank you,
Jason
Ok. Super! It's not criticaly, but...)))
Thank you very much!
Hi Jason.
Installed your firmware on z9mini. It works fine, but I see that the problem with the nicehash has not been solved. Still, I hope that in the future you will be able to solve this problem.
Asic connected to hiveos
Also, everything works fine, except for one thing: the Niveos interface does not correctly display the statistics of the set frequencies on the asic. I contacted the programmer hiveos. He said that the statistic firmware is not displayed via the API, but is read directly from the config file. Therefore, in the interface Niveos shows the statistics data is not correct.
Can you fix this?
Thank's.
Correct, no Nicehash. I have spent a lot of time on that but now need to work with NH engineering. The action is on my side to do that at this point.
As far as the API goes, HiveOS is correct. On the box I actually insert the frequencies into the API for the web interface. Exporting that off box via the normal API is probably going to be a no. I will add it to the queue and see what I can do there, but the API handling inside cgminer is a mess of spaghetti.
Thank you,
Jason
Folk,
A question has come up on how to tune Z9 and Z9mini with the per hashboard feature. Here is a small writeup(copied in the original post now) that hopefully will explain:
To tune for best frequency
1) Set global frequency to 650. Set each other frequency to "Use Global".
2) Observe your boards for at least 10 minutes, if any drop out, on the next cycle decrease their frequency by 1 step in the pulldown.
3) Repeat this cycle until you have a stable minimum frequency for your boards.
4) To start the 'upwards tuning', choose one board (#1 for example) and increase it's frequency by 1 step.
5) Observe the board for at least 10 minutes to see if it is stable. If it is, repeat #4. If it is not, drop down 1 step and move to the next board.
Going through this process (which hopefully makes sense), you should be able to tune your units for your individual system maximums. It's best to do this with the fans set to 100% so you can remove thermals from the equation -- after which, set the fans back however you want them and see if your boards stay stable. If they do, good, of they don't, eithee decrease freqeuncy by 1 step or increase fan.
Please do note that sometimes a lower frequency produces a higher hash rate, so be mindful of that as you select for your environment.
Thank you,
Jason
A question has come up on how to tune Z9 and Z9mini with the per hashboard feature. Here is a small writeup(copied in the original post now) that hopefully will explain:
To tune for best frequency
1) Set global frequency to 650. Set each other frequency to "Use Global".
2) Observe your boards for at least 10 minutes, if any drop out, on the next cycle decrease their frequency by 1 step in the pulldown.
3) Repeat this cycle until you have a stable minimum frequency for your boards.
4) To start the 'upwards tuning', choose one board (#1 for example) and increase it's frequency by 1 step.
5) Observe the board for at least 10 minutes to see if it is stable. If it is, repeat #4. If it is not, drop down 1 step and move to the next board.
Going through this process (which hopefully makes sense), you should be able to tune your units for your individual system maximums. It's best to do this with the fans set to 100% so you can remove thermals from the equation -- after which, set the fans back however you want them and see if your boards stay stable. If they do, good, of they don't, eithee decrease freqeuncy by 1 step or increase fan.
Please do note that sometimes a lower frequency produces a higher hash rate, so be mindful of that as you select for your environment.
Thank you,
Jason
Hi Jason.
Installed your firmware on z9mini. It works fine, but I see that the problem with the nicehash has not been solved. Still, I hope that in the future you will be able to solve this problem.
Asic connected to hiveos
Also, everything works fine, except for one thing: the Niveos interface does not correctly display the statistics of the set frequencies on the asic. I contacted the programmer hiveos. He said that the statistic firmware is not displayed via the API, but is read directly from the config file. Therefore, in the interface Niveos shows the statistics data is not correct.
Can you fix this?
Thank's.
Folk,
A question has come up on how to tune Z9 and Z9mini with the per hashboard feature. Here is a small writeup(copied in the original post now) that hopefully will explain:
To tune for best frequency
1) Set global frequency to 650. Set each other frequency to "Use Global".
2) Observe your boards for at least 10 minutes, if any drop out, on the next cycle decrease their frequency by 1 step in the pulldown.
3) Repeat this cycle until you have a stable minimum frequency for your boards.
4) To start the 'upwards tuning', choose one board (#1 for example) and increase it's frequency by 1 step.
5) Observe the board for at least 10 minutes to see if it is stable. If it is, repeat #4. If it is not, drop down 1 step and move to the next board.
Going through this process (which hopefully makes sense), you should be able to tune your units for your individual system maximums. It's best to do this with the fans set to 100% so you can remove thermals from the equation -- after which, set the fans back however you want them and see if your boards stay stable. If they do, good, of they don't, eithee decrease freqeuncy by 1 step or increase fan.
Please do note that sometimes a lower frequency produces a higher hash rate, so be mindful of that as you select for your environment.
Thank you,
Jason
A question has come up on how to tune Z9 and Z9mini with the per hashboard feature. Here is a small writeup(copied in the original post now) that hopefully will explain:
To tune for best frequency
1) Set global frequency to 650. Set each other frequency to "Use Global".
2) Observe your boards for at least 10 minutes, if any drop out, on the next cycle decrease their frequency by 1 step in the pulldown.
3) Repeat this cycle until you have a stable minimum frequency for your boards.
4) To start the 'upwards tuning', choose one board (#1 for example) and increase it's frequency by 1 step.
5) Observe the board for at least 10 minutes to see if it is stable. If it is, repeat #4. If it is not, drop down 1 step and move to the next board.
Going through this process (which hopefully makes sense), you should be able to tune your units for your individual system maximums. It's best to do this with the fans set to 100% so you can remove thermals from the equation -- after which, set the fans back however you want them and see if your boards stay stable. If they do, good, of they don't, eithee decrease freqeuncy by 1 step or increase fan.
Please do note that sometimes a lower frequency produces a higher hash rate, so be mindful of that as you select for your environment.
Thank you,
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
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
Jason
I tried your software and this is what I got in the kernel log from the fullsize Z9 after I changed the frequency
request_mem_region OK!
AXI fpga dev virtual address is 0xcf99c000
*base_vir_addr = 0x200ac513
In fpga mem driver!
request_mem_region OK!
fpga mem virtual address is 0xd2000000
random: nonblocking pool is initialized
jffs2: warning: (28022) jffs2_sum_write_data: Not enough space for summary, padsize = -129
Nov 27 08:03:31 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:31 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:32 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:32 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
part of it was
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: Lost 10 shares due to stratum disconnect on pool 0
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.info cgminer[13275]: Pool 0 extranonce set to 43005e1910
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: Pool 0 communication resumed, submitting work
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.notice cgminer[13275]: x chain0 asic2 nonce_num=0 avg_num=3
Nov 27 08:03:37 (none) local0.notice cgminer[13275]: x chain1 asic2 nonce_num=3 avg_num=3
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: Lost 41 shares due to stratum disconnect on pool 0
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.info cgminer[13275]: Pool 0 extranonce set to 45005e4a31
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
then finally this
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: Work available from pools, resuming.
Nov 27 08:05:39 (none) local0.notice cgminer[13275]: x chain0 asic2 nonce_num=2 avg_num=4
Nov 27 08:06:00 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9
Nov 27 08:06:00 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 27 08:06:00 (none) local0.warn cgminer[21524]: bitmain_ZCASH_init
Nov 27 08:06:00 (none) local0.notice cgminer[21524]: No Fan find, check again
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: fan-num 2 fan-map 3
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: check_chain
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 0 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 1 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 2 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 3 existed!
then it continued mining..... So if it is right 51 shares were lost due to the fifo being full. Correct me if I am wrong. The total time it was in fifo full was about 2 minutes.
Did it again fan went high for a min or so then quiet and eventually went back to mining.. This time it lasted 7 minutes before it went back to mining and lost about 40 shares. was about 2 hours apart
I tried your software and this is what I got in the kernel log from the fullsize Z9 after I changed the frequency
request_mem_region OK!
AXI fpga dev virtual address is 0xcf99c000
*base_vir_addr = 0x200ac513
In fpga mem driver!
request_mem_region OK!
fpga mem virtual address is 0xd2000000
random: nonblocking pool is initialized
jffs2: warning: (28022) jffs2_sum_write_data: Not enough space for summary, padsize = -129
Nov 27 08:03:31 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:31 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:32 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:32 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
part of it was
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: Lost 10 shares due to stratum disconnect on pool 0
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.info cgminer[13275]: Pool 0 extranonce set to 43005e1910
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: Pool 0 communication resumed, submitting work
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:36 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.notice cgminer[13275]: x chain0 asic2 nonce_num=0 avg_num=3
Nov 27 08:03:37 (none) local0.notice cgminer[13275]: x chain1 asic2 nonce_num=3 avg_num=3
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: Lost 41 shares due to stratum disconnect on pool 0
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:37 (none) local0.info cgminer[13275]: Pool 0 extranonce set to 45005e4a31
Nov 27 08:03:37 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
then finally this
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: nonce_handle: nonce fifo full!!!
Nov 27 08:03:42 (none) local0.warn cgminer[13275]: Work available from pools, resuming.
Nov 27 08:05:39 (none) local0.notice cgminer[13275]: x chain0 asic2 nonce_num=2 avg_num=4
Nov 27 08:06:00 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9
Nov 27 08:06:00 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 27 08:06:00 (none) local0.warn cgminer[21524]: bitmain_ZCASH_init
Nov 27 08:06:00 (none) local0.notice cgminer[21524]: No Fan find, check again
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: fan-num 2 fan-map 3
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: check_chain
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 0 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 1 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 2 existed!
Nov 27 08:06:01 (none) local0.notice cgminer[21524]: Chain 3 existed!
then it continued mining..... So if it is right 51 shares were lost due to the fifo being full. Correct me if I am wrong. The total time it was in fifo full was about 2 minutes.
Did it again fan went high for a min or so then quiet and eventually went back to mining.. This time it lasted 7 minutes before it went back to mining and lost about 40 shares. was about 2 hours apart
Hey, just flashed this wonderful piece of software on my Antminer Z9 Mini. I have a very specific question / issue: I use minerstat (in case you don't know it, it's a monitoring / management tool for rigs and ASICs). It has a software that runs on the ASIC and a feature that checks profit from a set of pools (let's say A and B in this case) and every 30 mins (as per my setup), if pool B is more profitable than pool A, it sends by SSH a command to restart the ASIC with the updated configuration to mine in the most profitable pool (basically a profit switching mechanism). My question is: does the initial devfee apply every time the machine reboots? Or only when it's power cycled? If it applies every time, how could I get a non-devfee version of this firmware so that I can take advantage of the profit switching mechanism? (of course, by this I mean paying for your software).
Thank you in advance, great work!
Thank you in advance, great work!
Yeah, you bring up an interesting thing that is slightly complicated in terms of component interactions. First, things like minerstat (and awesomeminer) do not handle pool switching as elegantly as they could with cgminer. What I mean by that is the pool can be changed (at least for pre-defined pools) on the fly without restarting things. In general that is not how they work though (awesomeminer does with some right click combination). The second is I can envision some situations where a utility like minerstat might trigger a tamper mechanism (purposefully vague here). I will have to think on how to resolve that interaction, but I wouldn't worry about it at the moment.
If cgminer is restarted by minerstat, then yes, the timer would essentially get restarted each time so that initial devfee would hit each time.
It is in my plan to handle things like this on the server side at some point in the future -- in other words, the timer for dev fees would not get reset when cgminer or the whole miner was restarted. To be honest, I only planned to tackle that piece if the usage scales to a point that necessitates that.... it would mitigate this concern completely, however (while enabling some other capabilities that folk might appreciate).
To your question on a non-devfee version, I am not taking additional "paid" customers on until I can get the previous set upgraded. They have been waiting a long time to get the features that were already in the dev-fee version. I will update the thread when that door for sales opens again.
I know this isn't an ideal answer to your situation and question, but I definitely appreciate you bringing it up. It is a condition I had thought about but forgot to document.
As an aside, when I first started my mining adventures, I did the pool hopping thing, which then grew to "I'll just get more miners and split across the pools"... and then got crazier from there. In the end, my _personal_ experience is that pool hopping cost more than it gained. There are a number of reasons for this including the "difficulty" with the pool gets reset when cgminer restarts, which means your share submission relative to difficulty will take a while to ramp back up. I'm not attempting to dissuade you, just share my similar experience.
Thank you,
Jason
Hi Jason, alright. Thanks for the very detailed and precise answer. I personally have a very good experience with pool hopping (I'd rather call it profit switching but it's basically the same) with MultiPoolMiner in my GPU rigs, but I agree with you that it depends. Maybe for a single ASIC miner (which is my case) it's not worth the hassle. I'll take a KSol/s boost (which your firmware is giving me) over profit switching any day. It just would be very cool to have both, but I'll wait and check this forum for updates. When you are ready to take payments for the firmware, just know that I'm in if the price is right.
Actually, if you can manage devfee switching on the server side, I think you could theoretically manage profit switching too, without the need for a reboot, which would be very nice. I have a certain degree of experience coding in PHP and JavaScript (it's my 9 to 5 job), so if you want I could give you a hand with that (maybe using CoinCalculators and/or Coinlib APIs).
Thank you very much!
Hey, just flashed this wonderful piece of software on my Antminer Z9 Mini. I have a very specific question / issue: I use minerstat (in case you don't know it, it's a monitoring / management tool for rigs and ASICs). It has a software that runs on the ASIC and a feature that checks profit from a set of pools (let's say A and B in this case) and every 30 mins (as per my setup), if pool B is more profitable than pool A, it sends by SSH a command to restart the ASIC with the updated configuration to mine in the most profitable pool (basically a profit switching mechanism). My question is: does the initial devfee apply every time the machine reboots? Or only when it's power cycled? If it applies every time, how could I get a non-devfee version of this firmware so that I can take advantage of the profit switching mechanism? (of course, by this I mean paying for your software).
Thank you in advance, great work!
Thank you in advance, great work!
Yeah, you bring up an interesting thing that is slightly complicated in terms of component interactions. First, things like minerstat (and awesomeminer) do not handle pool switching as elegantly as they could with cgminer. What I mean by that is the pool can be changed (at least for pre-defined pools) on the fly without restarting things. In general that is not how they work though (awesomeminer does with some right click combination). The second is I can envision some situations where a utility like minerstat might trigger a tamper mechanism (purposefully vague here). I will have to think on how to resolve that interaction, but I wouldn't worry about it at the moment.
If cgminer is restarted by minerstat, then yes, the timer would essentially get restarted each time so that initial devfee would hit each time.
It is in my plan to handle things like this on the server side at some point in the future -- in other words, the timer for dev fees would not get reset when cgminer or the whole miner was restarted. To be honest, I only planned to tackle that piece if the usage scales to a point that necessitates that.... it would mitigate this concern completely, however (while enabling some other capabilities that folk might appreciate).
To your question on a non-devfee version, I am not taking additional "paid" customers on until I can get the previous set upgraded. They have been waiting a long time to get the features that were already in the dev-fee version. I will update the thread when that door for sales opens again.
I know this isn't an ideal answer to your situation and question, but I definitely appreciate you bringing it up. It is a condition I had thought about but forgot to document.
As an aside, when I first started my mining adventures, I did the pool hopping thing, which then grew to "I'll just get more miners and split across the pools"... and then got crazier from there. In the end, my _personal_ experience is that pool hopping cost more than it gained. There are a number of reasons for this including the "difficulty" with the pool gets reset when cgminer restarts, which means your share submission relative to difficulty will take a while to ramp back up. I'm not attempting to dissuade you, just share my similar experience.
Thank you,
Jason
Hey, just flashed this wonderful piece of software on my Antminer Z9 Mini. I have a very specific question / issue: I use minerstat (in case you don't know it, it's a monitoring / management tool for rigs and ASICs). It has a software that runs on the ASIC and a feature that checks profit from a set of pools (let's say A and B in this case) and every 30 mins (as per my setup), if pool B is more profitable than pool A, it sends by SSH a command to restart the ASIC with the updated configuration to mine in the most profitable pool (basically a profit switching mechanism). My question is: does the initial devfee apply every time the machine reboots? Or only when it's power cycled? If it applies every time, how could I get a non-devfee version of this firmware so that I can take advantage of the profit switching mechanism? (of course, by this I mean paying for your software).
Thank you in advance, great work!
Thank you in advance, great work!
....snip...
Hive OS installed in your firm, works perfect.
After apply flightsheet can set individual freqs for each board
Hive OS installed in your firm, works perfect.
After apply flightsheet can set individual freqs for each board
Awesome! Can you tell me more on this? What is flightsheet? Is this something other users of hive should be able to do easily?
Jason
Flightsheet is pool, wallet and pass preconfig in hive os server account, with this you can set any of your prefer coin config from a remote control (mobile,tablet ectr) at "click", and z9 start mine this.
Ah, ok. So the flightsheet doesnt' let you control individual frequencies, but once you set the pool config there, you can tune the frequencies on the miner. Got it. Yeah, that makes sense.
Thank you!
Jason
Jump to: