Quote from: induktor on November 10, 2017, 01:32:21 AM

Quote from: 64dimensions on November 10, 2017, 01:14:11 AM

Quote from: dstm on November 10, 2017, 12:20:45 AM

Quote from: induktor on November 09, 2017, 11:44:59 PM

Quote from: Dropsh0t on November 09, 2017, 08:49:39 AM

It happens because very smart boy - dstm hardcoded fee pool in this miner. When pool (flypool) is down miner is out of work. So I lost more than hour on my farms it is much more than fee. Now I switched to EWBF - it is less vulnerable to such a treats.

Bye bye dstm..

Same here, 8 Hours offline with 30 x 1080 GPUs because of this problem.
not anymore.
I'll go back to EWBF
it connected instantly, 0 problems.

I lost a lot of money today.
sorry dstm but i can't afford problems like this, my profit marging is too thin right now to be offfline 8 hours for such a stupid issue.

That's perfectly valid ofc, no doubt - sry for the downtime.
I'm currently in contact with different pool owners, to be able to distribute pools across different networks.
I'm still not really happy about the failover draft, it has some corner cases that I don't like - like local network issues - more difficulties for people which have to tunnel all their traffic through a proxy - but I'm working on it.

Comments:

1) To these miners: it's not DSTM's fault that you lost money, it's your fault. Your greed got you in trouble.:

a) What business expects operational perfection in forecasting profit? So if you owned a trucking business, all the trucks would work perfectly? What would happen if a squirrel shorted out a breaker at the local power distribution station? There are some particular power distribution transformers that could take a week+ to replace because they are not stock items. Where I live, count on small animals, car crashes and lighting power outages.

b) You are stupid and greedy if you immediately deployed DSTM's miner across all your miners and then dumped on DSTM for any flaws. What was wrong with just running it on one mining setup? Even those bastions of software excellence, Microsoft and AMD, deploy updates that have problems/flaws. Why are you newbies dumping on one guy?

You guys need to come up with some sort of procedure for software deployment given all the noise you are making about how serious you are.

My procedure(not for everyone).

I'm conservative. I typically run at least 1 to 2 months behind any improved mining software. If the improvement is only a few %, I won't bite because crash free operation is worth a few per cent. If it's a few % hash increase plus a few per cent decrease in power consumption, this gets on my radar. I will wait several more weeks until people on the board I trust vouch for it. I then run this "new" software on one miner. Every crash adds a day of evaluation after a "corrective" homemade or goggle tweak. I have no expertise in determining whether there is bad stuff hidden in any software, this is my major concern. Yet another reason to treat this board's reliable software coders with respect and stop whining about their cut.

That's why only 1/3 of my miners runs ZM miner, the rest are with EWBF and others.

yes I am greedy, i like money, i also like technology, and mining is the best of both worlds, but make no mistake, we ALL are here to make money, so greed or no greed, we all need to get even, to achieve ROI, hardware is expensive!, power is also VERY expensive!, i invest heavily in mining hardware, and i expect it to perform accordingly.
I setup everything to insane perfection, so when something that it's out of my hand, happens, and my miners stays offline for so long, i get mad!, not to dstm, he is working hard to make the miner great, he'll eventually get it right, but to the situation, yes I rant, so he fix it Grin

can't help it Grin

(sorry dstm if i was rude btw) LOL

I run linux, have my own custom distro, totally automated, with near 99.99% uptime.
testing something for 1 month in crypto could be suicide, here things change so rapidly that usually testing is the week-range, IMHO, not more!.

BTW: i haven't deployed ZM overnight, dstm knows my case, i tested it for 2 weeks on a 1080Ti, then decide to move to three rigs (6x1080) and then some more, stability was pretty good until this happens, and yes eu pools got fucked up by some major ISP nothing we can do about it, i inmediately changed to another location and another pool and then i realized that ZM was "locked" to eu port on fly pool, so i switched to EWBF (yes 8 hours LATE because i was dealing with a F* mess in a plant with some PLC controller , and had no time to check my miners, so yes i cursed at me as well for not taking 30 seconds to check my miners remotely)

anyway.....shit happens...
all online again

cheers
indkt.

No, there was nothing rude in your comment, it's a perfectly valid position. It's very interesting how people are different in their judgments with respect to this.

Concerning ZM's flypool 'lock'. As far as I understand flypool has a high uptime something about 99.9x/8x%, this is what my tests during the last months suggest it also matches the experience people have made so far. ZM's implementation was based on this numbers.

The downtime because of ISP issues is really a stupid thing - zm clearly needs an improvement here. I don't really like the failover pool solution - it has some corner cases. I prefer much more to ignore the submission of dev fee shares in cases of server outages. This is less complex and perfectly reliable for you, however this easy to abuse and I'm not able to predict how many installations would do so.