Pages:
Author

Topic: [ANN] DelosMiner for nVidia GPUs by TeamDelos - page 2. (Read 2834 times)

newbie
Activity: 28
Merit: 0
This is joke?

11:10 start
11:45 fee
12:18 fee
12:52 fee
13:25 fee
13:58 fee

1 min 15 sec - 30 min
x % fee - 100 %

x = 1.25 * 100 / 30 = 4,1666666666666666666666666666667

Real dev fee is above 4%!!!



i removed right after it made 1st connection during benchmark phase. 240sec interval only. dev fee connect wayyy too early.
reinitialized gpu during benchmarking x16r even devfee connecting to x16r.
member
Activity: 142
Merit: 10
This is joke?

11:10 start
11:45 fee
12:18 fee
12:52 fee
13:25 fee
13:58 fee

1 min 15 sec - 30 min
x % fee - 100 %

x = 1.25 * 100 / 30 = 4,1666666666666666666666666666667

Real dev fee is above 4%!!!



i was wondering about same , why my workers so often getting jerked off my pool ...
member
Activity: 825
Merit: 18
MindMiner developer
This is joke?

11:10 start
11:45 fee
12:18 fee
12:52 fee
13:25 fee
13:58 fee

1 min 15 sec - 30 min
x % fee - 100 %

x = 1.25 * 100 / 30 = 4,1666666666666666666666666666667

Real dev fee is above 4%!!!

jr. member
Activity: 74
Merit: 1
Still no love for a linux version ?
newbie
Activity: 1
Merit: 0
DelosMiner v1.3.0 is released!

Change log:

    Performance boosts on LYRA2v2, Skein and x16r!
    Additional core speed improvements of up to 2% for most algos.
    Revised dev fee mechanism for a seemless mining experience.

Thanks for the update. The optimizations to Lyra2v2 are much appreciated.  I have small suggest concerning the dev fee mechanism, however. Would you consider hiding the accepted results and hash rate messages when the miner is working on the dev pool?  The issue is that if you are trying to do any calculations based on those numbers, the results from the dev pool work can skew the averages. Since the dev pool work doesn't correspond to the user's work, it would be preferable to hide performance messages related to the dev pool. Thanks for considering my suggestion.

i strongly support this , just simple "starting devfee mining" and "finishing mining devfee" messages should be sufficient for thos who want to see time stamps or whatsnot

I strongly support this also.  Can you also remove the dev pool work from the api.  It is throwing off the miners calculated stats. 
member
Activity: 142
Merit: 10
DelosMiner v1.3.0 is released!

Change log:

    Performance boosts on LYRA2v2, Skein and x16r!
    Additional core speed improvements of up to 2% for most algos.
    Revised dev fee mechanism for a seemless mining experience.

Thanks for the update. The optimizations to Lyra2v2 are much appreciated.  I have small suggest concerning the dev fee mechanism, however. Would you consider hiding the accepted results and hash rate messages when the miner is working on the dev pool?  The issue is that if you are trying to do any calculations based on those numbers, the results from the dev pool work can skew the averages. Since the dev pool work doesn't correspond to the user's work, it would be preferable to hide performance messages related to the dev pool. Thanks for considering my suggestion.

i strongly support this , just simple "starting devfee mining" and "finishing mining devfee" messages should be sufficient for thos who want to see time stamps or whatsnot
legendary
Activity: 2296
Merit: 1031
How about Xevan?

+1 to this.  Any plans to add Xevan into the optimization mix here?
newbie
Activity: 481
Merit: 0
DelosMiner v1.3.0 is released!

Change log:

    Performance boosts on LYRA2v2, Skein and x16r!
    Additional core speed improvements of up to 2% for most algos.
    Revised dev fee mechanism for a seemless mining experience.

Thanks for the update. The optimizations to Lyra2v2 are much appreciated.  I have small suggest concerning the dev fee mechanism, however. Would you consider hiding the accepted results and hash rate messages when the miner is working on the dev pool?  The issue is that if you are trying to do any calculations based on those numbers, the results from the dev pool work can skew the averages. Since the dev pool work doesn't correspond to the user's work, it would be preferable to hide performance messages related to the dev pool. Thanks for considering my suggestion.
newbie
Activity: 16
Merit: 0
DelosMiner v1.3.0 is released!

Change log:

    Performance boosts on LYRA2v2, Skein and x16r!
    Additional core speed improvements of up to 2% for most algos.
    Revised dev fee mechanism for a seemless mining experience.

Enjoy!

newbie
Activity: 16
Merit: 0
Can you bring support for P102-100 mining edition? It uses CUDA 6.1

This will be probably not possible for all supoorted algo. Which algos are you going to use?
newbie
Activity: 66
Merit: 0
Can you bring support for P102-100 mining edition? It uses CUDA 6.1
newbie
Activity: 16
Merit: 0
how about x17 algo? enemy miner has it? this algo is very profitable now so it would be nice if you gonna implement the support of this algo to your miner
by the way II have test your miner for X16r, raven.. still enemy has the lead)) so you have to do more optimization..

Thanks for your feedback!

x17 is already implenented. Does it not work for you?
How much performance are you missing on x16r with which GPU?
We are currently implementing Xevan. Hopefully that is interesting for you, too!
newbie
Activity: 13
Merit: 0
How about Xevan?
newbie
Activity: 16
Merit: 0
Request , could you please move dev fee away from intial miner launch 10+ mins , since you hardcoded x16r it messes up bechmarkings for other algos. Or even better as people already requested , make it per algo or somethings. current implementation is major annoyance.

Also there is something weird with hashrate reporting after dev fee , on pool it shows correct values , but miner output is wrong , messes up with autoswitching software when its update hashrate statistics periodically.

https://preview.ibb.co/ei7cq8/delos.png




Thanks for suggesting this! Pushing dev time to much back is an issue as many switching tools (MindMiner, All-In-Miner, etc.) tend to switch quite often (every 2-3 minutes).

Hence, we take your idea and avoid the x16r hardcoding. This should avoid messing up benchmarks of other algos!

Stay tuned for the next release... Smiley
member
Activity: 142
Merit: 10
Request , could you please move dev fee away from intial miner launch 10+ mins , since you hardcoded x16r it messes up bechmarkings for other algos. Or even better as people already requested , make it per algo or somethings. current implementation is major annoyance.

Also there is something weird with hashrate reporting after dev fee , on pool it shows correct values , but miner output is wrong , messes up with autoswitching software when its update hashrate statistics periodically.




newbie
Activity: 122
Merit: 0
Good Hashrates on Phi, but you have to do something with the DevFee. If i optimize my Rig for Phi and it switches to x16r for your Fee, the Driver crashes as it isnt configured for the other Algorithm. Maybe make it Algo depended.
sr. member
Activity: 536
Merit: 321
Any plan for linux verison?
hero member
Activity: 756
Merit: 507
how about x17 algo? enemy miner has it? this algo is very profitable now so it would be nice if you gonna implement the support of this algo to your miner
by the way II have test your miner for X16r, raven.. still enemy has the lead)) so you have to do more optimization..
newbie
Activity: 1
Merit: 0
  you  should improve your software like enemy              eg:  - Revised dev-fee mechanism. Now the miner does not break off connection with a pool and does not drop work of video cards. Everything works without switch-offs.
newbie
Activity: 28
Merit: 0
1.2.2 9.2 32bit
Api isnt answer on request "threads". In 9.1 all fine.

Please, move fee time to 5 min and above from miner start. Wrong speed detect in autoswitch software.

+1

1.2.2 9.2 32bit crash too much.
Pages:
Jump to: