Quote from: efudd on November 28, 2018, 03:15:57 PM

Quote from: chipless on November 28, 2018, 02:39:56 PM

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.

Quote from: chipless on November 28, 2018, 02:39:56 PM

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.

Quote from: chipless on November 28, 2018, 02:39:56 PM

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.