Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini

[efudd]

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

[kgbtc]

Awsome! thanks I'll be glad to be the tester.

[efudd]

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

[bakermining76]

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.

[efudd]

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

[chipless]

@ 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

This is factory firmware unlocked to overclock globally not per board with 4 boards

current

Chain#   ASIC#   Frequency   KSol/S(RT)    HW   Temp(PCB)   Temp(Chip)   ASIC status
1            16                656   20.15             0      49                        69        oooooooo oooooooo
2            16                656   21.13             0      50                        71        oooooooo oooooooo
3            16                656   19.74             0      50                        70        oooooooo oooooooo
4            16                656   19.33             0      43                        52        oooooooo oooooooo


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

[efudd]

...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

[chipless]

...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

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.

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.

Enjoy the input

[xkosx]

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).

[efudd]

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

[efudd]

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

[Czepot]

Hi.
Its v2.1 also for payd users?
Thanks

[xkosx]

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

Yes Jason machine never starts mining. And on the "Overview System" tab I have a void
Miner Type    
Hostname   
Model   
Hardware Version   
Kernel Version   
File System Version   
CGminer Version   
And
Uptime   
Load Average
Total Available   0 kB / 0 kB (0%)
Free   0 kB / 0 kB (0%)
Cached   0 kB / 0 kB (0%)
Buffered   0 kB / 0 kB (0%)

Me firmware on may back everything works.. On your waited 30 minutes and did not start mining..

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
Nov 28 15:44:17 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 15:44:17 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 15:44:17 (none) local0.warn cgminer[1148]: bitmain_ZCASH_init
Nov 28 15:44:17 (none) local0.notice cgminer[1148]: No Fan find, check again
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: fan-num 1 fan-map 1
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: check_chain
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: Chain 0 existed!
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: Chain 1 existed!
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: Chain 2 existed!
Nov 28 15:44:19 (none) local0.notice cgminer[1148]: chain0 every_chain_reset_PIC16F1704_pic_new
Nov 28 15:45:22 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 15:45:22 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 15:45:22 (none) local0.warn cgminer[1219]: bitmain_ZCASH_init
Nov 28 15:45:23 (none) local0.notice cgminer[1219]: No Fan find, check again
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: fan-num 1 fan-map 1
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: check_chain
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: Chain 0 existed!
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: Chain 1 existed!
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: Chain 2 existed!
Nov 28 15:45:24 (none) local0.notice cgminer[1219]: chain0 every_chain_reset_PIC16F1704_pic_new
Nov 28 15:46:28 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 15:46:28 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 15:46:28 (none) local0.warn cgminer[1290]: bitmain_ZCASH_init
Nov 28 15:46:28 (none) local0.notice cgminer[1290]: No Fan find, check again
Nov 28 15:46:29 (none) local0.notice cgminer[1290]: No Fan find, check again
Nov 28 15:47:33 (none) local0.err cgminer: Miner compile time: Tue Aug 21 16:00:32 CST 2018 (v2.1) type: Antminer Z9-Mini
Nov 28 15:47:33 (none) local0.warn cgminer: Started cgminer 4.9.0
Nov 28 15:47:33 (none) local0.warn cgminer[1361]: bitmain_ZCASH_init
Nov 28 15:47:33 (none) local0.notice cgminer[1361]: No Fan find, check again
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: fan-num 1 fan-map 1
Nov 28 15:47:35 (none) local0.notice cgminer[1361]: check_chain
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

[efudd]

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.

[efudd]

...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

[xkosx]

...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

Kernel log,monitor log, screenshot System,Miner Status and img fan emu. Password in PM
Link https://dropmefiles.com/3iSv8

[efudd]

... snip ...
Kernel log,monitor log, screenshot System,Miner Status and img fan emu. Password in PM
Link https://dropmefiles.com/3iSv8

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

[efudd]

... snip ...
Kernel log,monitor log, screenshot System,Miner Status and img fan emu. Password in PM
Link https://dropmefiles.com/3iSv8

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.

[chipless]

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

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.

[efudd]

...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