Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 02:31:25 PM |
|
Is there a consensus regarding this miner? Is it really much better than ewbf? Do we have an organized comparison between the two in various conditions for various cards?
The comparison is that this miner is clearly an unstable beta version, an I lost 3 hours of mining today... again. And we are paying 2% fee on top of that, to participate to a beta test... t1NEpmfunewy9z5TogCvAhCuS3J8VWXoJNv yea... like I said, dev fee is working perfectly. just use Cheat Engine
|
|
|
|
at10ti0n
Newbie
Offline
Activity: 16
Merit: 0
|
|
November 09, 2017, 03:19:40 PM |
|
this morning there was an outage in EU affecting several pool providers that had the EU servers there: suprnova, flypool, ethermine, miningspeed, hence an almost 3 hour downtime.
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 03:50:53 PM |
|
this morning there was an outage in EU affecting several pool providers that had the EU servers there: suprnova, flypool, ethermine, miningspeed, hence an almost 3 hour downtime.
We already know that. The problem here is that the server for the dev fee is hardcoded (eu flypool). So, if eu flypool is down, you can't mine anywhere with zm.
|
|
|
|
chancefx
Member
Offline
Activity: 153
Merit: 10
In Decentralization We Trust
|
|
November 09, 2017, 03:53:59 PM |
|
this morning there was an outage in EU affecting several pool providers that had the EU servers there: suprnova, flypool, ethermine, miningspeed, hence an almost 3 hour downtime.
We already know that. The problem here is that the server for the dev fee is hardcoded (eu flypool). So, if eu flypool is down, you can't mine anywhere with zm. totally agree, its a crap
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 04:02:51 PM |
|
With my 1070s, I have 460 sols instead of 440. So that's ~4.5% for me. Today, with a 3 hours hole and the 2% fees, that makes 14.5% less...
I don't understand why the mining would need to stop if it can't connect to flypool. I mean, the fee shares are lost anyway. So, what communication with pool owners? Just cut the crap
Looks like the dev fees are priority number one here, that sure works perfectly!
Was it so hard for you to visit pool website and realize, that EU nodes are down? Then was it so hard for you to edit your miner with US pool address and continue mining? No one shouldn't do this instead of you, for whatever fee... Guys! is that so hard to understand that you can edit whatever you want, it won't work! it is HARDCODED zm try to connect to eu server anyway, for the DEV FEE I'm as noob as you here, but at least read the last 2 pages before posting shit
|
|
|
|
toptek
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
November 09, 2017, 04:09:03 PM |
|
To avoid misinterpretations of my previous statement:
ZM's reliability is of high priority. There is no doubt - this needs improvement. I'm thinking about a better solution to this ofc. This requires some communication with pool owners and some testing. I'll provide an update as soon as possible. Sry for the downtime.
NP just make it more clear what you mean this software seems awesome or better then EWBF's CUDA Zcash miner ...so until you get it working again please take your time fixing it and ignore some of the others an me for that fact ..... an fix it : ) ...the good thing i guess no one seems to care about the Fee they just want it working because it does work good, when it is working ... or better then EWBF's CUDA Zcash miner . I do have one request add some color to the screen ... .....
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 04:25:08 PM |
|
To avoid misinterpretations of my previous statement:
ZM's reliability is of high priority. There is no doubt - this needs improvement. I'm thinking about a better solution to this ofc. This requires some communication with pool owners and some testing. I'll provide an update as soon as possible. Sry for the downtime.
NP just make it more clear what you mean this software seems awesome or better then EWBF's CUDA Zcash miner ...so until you get it working again please take your time fixing it and ignore some of the others an me for that fact ..... an fix it : ) ...the good thing i guess no one seems to care about the Fee they just want it working because it does work good, when it is working ... or better then EWBF's CUDA Zcash miner . I do have one request add some color to the screen ... ..... Yeah, make us pay to beta test and ignore us... that's the best way to go! If people change their miner for a 4% gain, they certainly care for 2% fee as well.
|
|
|
|
ap0stol
Newbie
Offline
Activity: 39
Merit: 0
|
|
November 09, 2017, 05:12:56 PM |
|
Looks like the dev fees are priority number one here, that sure works perfectly!
u can change some bytes....
|
|
|
|
that1lurk3r
Newbie
Offline
Activity: 25
Merit: 0
|
|
November 09, 2017, 06:26:59 PM |
|
I see people are having a problem just showing mine the one working miner on there is using EWBF as I haven't found a OC setting that dstm likes yet. https://imgur.com/T0w7lT9
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 07:35:22 PM |
|
Same here... here we go again. No flypool, no zm mining... can't connect to nanopool, working perfectly with ewbf...
|
|
|
|
dstm (OP)
|
|
November 09, 2017, 08:01:04 PM |
|
Some more information about the downtime:
OVH hosting went down for a couple of hours today. They are one of the biggest hosting service in Europe - multiple pools went down because of this in Europe.
Concerning zm's developer fee implementation: It's not easy to differentiate between a server outage and someone simply blocking network access to dev fee servers for a user space program. This is why zm behaves like this. Nevertheless expected downtime due to this is still very low.
There are multiple technical solutions to this. Failover servers is one possibility, however they have to be chosen carefully such that they are distributed among different hosting providers.
Another possibility is to differentiate between a server outage and someone trying to bypass dev fee. Such an implementation would allow to simply disable dev fee as long as the corresponding server is down. However this would require zm to communicate with it's own servers.
A third possibility is to extend zm such that it's able to solve blocks without the need of a pool. This one requires the most work - I'm currently not sure about the constraints of this solution, however it might also be useful for some users.
For users that have concerns about zm's current reliability because of this. Pls use a different mining software - it's your choice ofc.
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 08:14:28 PM |
|
Some more information about the downtime:
OVH hosting went down for a couple of hours today. They are one of the biggest hosting service in Europe - multiple pools went down because of this in Europe.
Concerning zm's developer fee implementation: It's not easy to differentiate between a server outage and someone simply blocking network access to dev fee servers for a user space program. This is why zm behaves like this. Nevertheless expected downtime due to this is still very low.
There are multiple technical solutions to this. Failover servers is one possibility, however they have to be chosen carefully such that they are distributed among different hosting providers.
Another possibility is to differentiate between a server outage and someone trying to bypass dev fee. Such an implementation would allow to simply disable dev fee as long as the corresponding server is down. However this would require zm to communicate with it's own servers.
A third possibility is to extend zm such that it's able to solve blocks without the need of a pool. This one requires the most work - I'm currently not sure about the constraints of this solution, however it might also be useful for some users.
For users that have concerns about zm's current reliability because of this. Pls use a different mining software - it's your choice ofc.
Well, after reading this, it's clear that you fees are your number one concern. You do not care about the down time as long as your fees are not stolen. This kind of reasoning will get you hacked, this is just a matter of time.
|
|
|
|
dstm (OP)
|
|
November 09, 2017, 08:27:08 PM |
|
Some more information about the downtime:
OVH hosting went down for a couple of hours today. They are one of the biggest hosting service in Europe - multiple pools went down because of this in Europe.
Concerning zm's developer fee implementation: It's not easy to differentiate between a server outage and someone simply blocking network access to dev fee servers for a user space program. This is why zm behaves like this. Nevertheless expected downtime due to this is still very low.
There are multiple technical solutions to this. Failover servers is one possibility, however they have to be chosen carefully such that they are distributed among different hosting providers.
Another possibility is to differentiate between a server outage and someone trying to bypass dev fee. Such an implementation would allow to simply disable dev fee as long as the corresponding server is down. However this would require zm to communicate with it's own servers.
A third possibility is to extend zm such that it's able to solve blocks without the need of a pool. This one requires the most work - I'm currently not sure about the constraints of this solution, however it might also be useful for some users.
For users that have concerns about zm's current reliability because of this. Pls use a different mining software - it's your choice ofc.
Well, after reading this, it's clear that you fees are your number one concern. You do not care about the down time as long as your fees are not stolen. This kind of reasoning will get you hacked, this is just a matter of time. I'm not sure about your intention, I don't see any productive proposal in your statement. I've clearly stated the preference for reliability above the developer fee I've also stated some possible solutions I'm thinking of. This allows people to discuss them if there are any concerns about them.
|
|
|
|
uskovartem
Newbie
Offline
Activity: 44
Merit: 0
|
|
November 09, 2017, 08:36:58 PM |
|
What if not hardcode flypool, but mine with user on same pool? If user run zm on nanopool, also mine on this pool, and same with other pools. Sadly, that dev fee №1 in prioritate
|
|
|
|
Seb83
Newbie
Offline
Activity: 41
Merit: 0
|
|
November 09, 2017, 08:39:27 PM |
|
Some more information about the downtime:
OVH hosting went down for a couple of hours today. They are one of the biggest hosting service in Europe - multiple pools went down because of this in Europe.
Concerning zm's developer fee implementation: It's not easy to differentiate between a server outage and someone simply blocking network access to dev fee servers for a user space program. This is why zm behaves like this. Nevertheless expected downtime due to this is still very low.
There are multiple technical solutions to this. Failover servers is one possibility, however they have to be chosen carefully such that they are distributed among different hosting providers.
Another possibility is to differentiate between a server outage and someone trying to bypass dev fee. Such an implementation would allow to simply disable dev fee as long as the corresponding server is down. However this would require zm to communicate with it's own servers.
A third possibility is to extend zm such that it's able to solve blocks without the need of a pool. This one requires the most work - I'm currently not sure about the constraints of this solution, however it might also be useful for some users.
For users that have concerns about zm's current reliability because of this. Pls use a different mining software - it's your choice ofc.
Well, after reading this, it's clear that you fees are your number one concern. You do not care about the down time as long as your fees are not stolen. This kind of reasoning will get you hacked, this is just a matter of time. I'm not sure about your intention, I don't see any productive proposal in your statement. I've clearly stated the preference for reliability above the developer fee I've also stated some possible solutions I'm thinking of. This allows people to discuss them if there are any concerns about them. I have no intention. I'm just saying that zm should not shut down if you cannot connect to the server for your fees. You have to act fast. Do something. Lower the hash rate or I dont know... but find a solution now. We don't have to wait that you find the perfect anti piracy solution. Let me remind you that you are taking 700 bucks everyday from us. This is no donation! this is your fees. We are paying you. So, in case of problem like that we expect you to act fast. No blabla, no bullshit. We all lost today because of that (including you), and you act like it is nothing. The problem is not the network failure, it is the way your miner react.
|
|
|
|
QuintLeo
Legendary
Offline
Activity: 1498
Merit: 1030
|
|
November 09, 2017, 08:53:58 PM |
|
this morning there was an outage in EU affecting several pool providers that had the EU servers there: suprnova, flypool, ethermine, miningspeed, hence an almost 3 hour downtime.
Set up one or more backup pools - somewhere else. Doesn't help if YOUR ISP or the core ISP they connect to goes down, but can make a big difference is the POOL'S ISP goes down on one pool.
|
I'm no longer legendary just in my own mind! Like something I said? Donations gratefully accepted. LYLnTKvLefz9izJFUvEGQEZzSkz34b3N6U (Litecoin) 1GYbjMTPdCuV7dci3iCUiaRrcNuaiQrVYY (Bitcoin)
|
|
|
dstm (OP)
|
|
November 09, 2017, 09:05:05 PM |
|
What if not hardcode flypool, but mine with user on same pool? If user run zm on nanopool, also mine on this pool, and same with other pools. Sadly, that dev fee №1 in prioritate I was thinking of this possibility, it's easy to implement, however it has drawbacks since some pools require login information.
|
|
|
|
prettycode
Newbie
Offline
Activity: 9
Merit: 0
|
|
November 09, 2017, 09:19:25 PM |
|
Just wanted to say that I'm switching back to EWBF even if zm gives me a ~3% better hashrate. No fail-over for dev shares is not going to work for my farm. Not interested in having a similar outage again.
|
|
|
|
dstm (OP)
|
|
November 09, 2017, 09:38:08 PM |
|
I have no intention. I'm just saying that zm should not shut down if you cannot connect to the server for your fees. You have to act fast. Do something. Lower the hash rate or I dont know... but find a solution now. We don't have to wait that you find the perfect anti piracy solution.
Let me remind you that you are taking 700 bucks everyday from us. This is no donation! this is your fees. We are paying you. So, in case of problem like that we expect you to act fast. No blabla, no bullshit.
We all lost today because of that (including you), and you act like it is nothing. The problem is not the network failure, it is the way your miner react.
This is slightly one sided ofc. Server outage like today is very unlikely to happen during the next week. So there is some time (and it's a of high priority ofc) to think about a solution which works reliable for all users in all locations. People that have concerns about zm's current reliability (this is perfectly valid ofc) have the option to use a different mining software. I don't want to hack an unreliable solution as fast as possible just to make it look good.
|
|
|
|
uskovartem
Newbie
Offline
Activity: 44
Merit: 0
|
|
November 09, 2017, 09:46:58 PM |
|
Server outage like today is very unlikely to happen during the next week.
Bad practice in programming think that something isn't happen. Try to predict all cases.
|
|
|
|
|