Pages:
Author

Topic: hsrminer - Nvidia mining software for various algos by palgin&alexkap - page 53. (Read 30791 times)

full member
Activity: 224
Merit: 100
CryptoLearner

Thank you for the info, if speed doesn't fluctuate with power, I think it's SMI software issue and there's nothing dangerous to hardware, but only wattmeter confirmation will close this question, I'll keep tracking it.

But I don't see the fluctuations on Equihash algo. I should test different algos and mining software to localize the issue. Unfortunatelly I've no enough time today. Maybe in few days I will test some and will responce to you.

I beware the problem becaues of I would like to create optimal configuration for the future rig and the main question is: How much power should reserve above average consumption ( I proposed about 20-25% )

a good practice is to have at least 30% reserve to compensate for any possible spikes and because psu's aren't made to work 24/7 at 100% load (except server psu's and not even those like to be 100% all the time), it will also save you money, because a PSU efficiency is higher when it's load is lower (most efficiency numbers are given for a 50% loaded psu, so a plat 94% will be 90% at 80% load and even less above)
full member
Activity: 405
Merit: 136

Thank you for the info, if speed doesn't fluctuate with power, I think it's SMI software issue and there's nothing dangerous to hardware, but only wattmeter confirmation will close this question, I'll keep tracking it.

But I don't see the fluctuations on Equihash algo. I should test different algos and mining software to localize the issue. Unfortunatelly I've no enough time today. Maybe in few days I will test some and will responce to you.

I beware the problem becaues of I would like to create optimal configuration for the future rig and the main question is: How much power should reserve above average consumption ( I proposed about 20-25% )
sr. member
Activity: 266
Merit: 250
Miner software for various hashing algorithms (currenlty Nvidia-only) by palgin & alexkap

Hey palgin cool to see you do a new miner, I followed your progress regarding the Skunk algo earlier this year.

If it is possible to vote you have my vote for a improved Bitcore BTX miner! Wink

--ypsi

Thank you, I'm planning to cover most of non-ASIC algos, but all this takes time, Bitcore is on my list Wink
sr. member
Activity: 266
Merit: 250
a working altenative pool will be great. You know, like in this "old&crap" software called sgminer...

Yes, we're planning failover pool support in future versions.
legendary
Activity: 1151
Merit: 1001
a working altenative/backup/  pool will be great. You know, like in this "old&crap" software called sgminer...
sr. member
Activity: 266
Merit: 250
Hi Palgin,

I have a large commercial farm and would love to see a Neoscrypt enhancement come out! Very in demand for miners and all of the new profitable coins coming out with no SPMod like LUX.

Good luck and congrats on your success so far!

-Kevin

Hi, as a lot of people vote for Neoscrypt, I think I'll stick to it, hope to finish it in time.

And thank you for your kind words.
sr. member
Activity: 266
Merit: 250
Config:
MoBo: MSI Z170-A Pro
CPU: Pentium G 4400
RAM: 8GB
HardDrive: 60GB SSD
OS: Win Server 2012R2
GPU: GTX1080Ti Palit GameRock Premium

GPU is connected directly to the MoBo.
Hashrate is stable around 24Mh/s. (core voltage/frequency also stable in MSI AB)
Average power consumption is about 230W (for several hours)
Unfortunatelly I've no a wattmeter to make direct measurement. I'm using just Nvidia SMI tool

Maybe power fluctuations appear because of task distribution on the GPU (I check with 2 sec period)

Thank you for the info, if speed doesn't fluctuate with power, I think it's SMI software issue and there's nothing dangerous to hardware, but only wattmeter confirmation will close this question, I'll keep tracking it.
sr. member
Activity: 266
Merit: 250
Good to know. I'm not a programmer but I was just thinking how much of a difference a near-perfect t/b launch config could offer and how much time it takes for you guys to find ideal launch configs for each cards. Miners tends to enjoy playing with settings so you could kind of crowdsource that - if it made a significant difference that is.

In cudaminer days for scrypt and similar algos the difference was day and night when it came down to using the perfect settings (threads(or blocks?) were almost always the multiple of the card's SMX count).

Tying both the optimization and the benchmark issue into one, cudaminer's benchmark for scrypt coins had a benchmark mode that would find the fastest launch config by trying a bunch of them. It was bad by default (was way too fast before trying the next one), but with some tinkering it found the fastest speeds pretty reliably even on modern cards. Again, if that's a scrypt-exclusive thing than just ignore me, but it's something to consider. But a benchmark system that tries even only just different intensities and finds the fastest would be great imo.

You're right, but this is applicable only to single kernel algos (or in some specific cases to multi kernel algos).
I like the idea with benchmark self-finding best launch config, think we'll stick to this rather then direct intensity input. Another problem with benchmark versus real work is that benchmark usually shows faster hashrate than it appears during real pool work, so I think we should provide real data from pool to benchmark code.

Thank you for a great idea!
jr. member
Activity: 34
Merit: 1
I'm not sure how intensity should be done, but with the default setting now there's some overhead (1-3% GPU usage). In ccminer that means you can get a noticeable speed increase if you push the GPU usage higher with intensity.

Maybe allowing us to change the intensity or even thread/blocks, we, the users could experiment and find the best settings for different cards. I'm not sure how that works for different algos though.

Direct thread/block input is unsafe . As this parameter is hardware-bounded, think I'll stick to ccminer-style intensity setting, currently it's automatically calculated depending on card model.

Hi Palgin,

I have a large commercial farm and would love to see a Neoscrypt enhancement come out! Very in demand for miners and all of the new profitable coins coming out with no SPMod like LUX.

Good luck and congrats on your success so far!

-Kevin
full member
Activity: 405
Merit: 136

Can you please post your rig config (MoBo, Memory amount, CPU, GPU Vendor and model) ? Your card is currently installed on board or you use riser? Does the speed fluctuate with power consumption (30% up-down)? Do you have wattmeter to measure consumption at power plug?

It can be caused by work distribution among GPUs (in your case 1 card only) or by hardware config, I make a list of hardware with troubles or unexpected behavior, so your help will be much appreciated.

Anyway, thank you for participation!


Config:
MoBo: MSI Z170-A Pro
CPU: Pentium G 4400
RAM: 8GB
HardDrive: 60GB SSD
OS: Win Server 2012R2
GPU: GTX1080Ti Palit GameRock Premium

GPU is connected directly to the MoBo.
Hashrate is stable around 24Mh/s. (core voltage/frequency also stable in MSI AB)
Average power consumption is about 230W (for several hours)
Unfortunatelly I've no a wattmeter to make direct measurement. I'm using just Nvidia SMI tool

Maybe power fluctuations appear because of task distribution on the GPU (I check with 2 sec period)

legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
I'm not sure how intensity should be done, but with the default setting now there's some overhead (1-3% GPU usage). In ccminer that means you can get a noticeable speed increase if you push the GPU usage higher with intensity.

Maybe allowing us to change the intensity or even thread/blocks, we, the users could experiment and find the best settings for different cards. I'm not sure how that works for different algos though.

Direct thread/block input is unsafe . As this parameter is hardware-bounded, think I'll stick to ccminer-style intensity setting, currently it's automatically calculated depending on card model.

Good to know. I'm not a programmer but I was just thinking how much of a difference a near-perfect t/b launch config could offer and how much time it takes for you guys to find ideal launch configs for each cards. Miners tends to enjoy playing with settings so you could kind of crowdsource that - if it made a significant difference that is.

In cudaminer days for scrypt and similar algos the difference was day and night when it came down to using the perfect settings (threads(or blocks?) were almost always the multiple of the card's SMX count).

Tying both the optimization and the benchmark issue into one, cudaminer's benchmark for scrypt coins had a benchmark mode that would find the fastest launch config by trying a bunch of them. It was bad by default (was way too fast before trying the next one), but with some tinkering it found the fastest speeds pretty reliably even on modern cards. Again, if that's a scrypt-exclusive thing than just ignore me, but it's something to consider. But a benchmark system that tries even only just different intensities and finds the fastest would be great imo.
sr. member
Activity: 266
Merit: 250
I'm not sure how intensity should be done, but with the default setting now there's some overhead (1-3% GPU usage). In ccminer that means you can get a noticeable speed increase if you push the GPU usage higher with intensity.

Maybe allowing us to change the intensity or even thread/blocks, we, the users could experiment and find the best settings for different cards. I'm not sure how that works for different algos though.

Direct thread/block input is unsafe . As this parameter is hardware-bounded, think I'll stick to ccminer-style intensity setting, currently it's automatically calculated depending on card model.
sr. member
Activity: 266
Merit: 250
It's my test rig. now with only one GPU 1080Ti. I just tested it only with equihash and HSR now. What tests do you recommend? It's win machine and I would not like to install Linux but if it will be especially interest test I would try

Can you please post your rig config (MoBo, Memory amount, CPU, GPU Vendor and model) ? Your card is currently installed on board or you use riser? Does the speed fluctuate with power consumption (30% up-down)? Do you have wattmeter to measure consumption at power plug?

It can be caused by work distribution among GPUs (in your case 1 card only) or by hardware config, I make a list of hardware with troubles or unexpected behavior, so your help will be much appreciated.

Anyway, thank you for participation!
hero member
Activity: 714
Merit: 512
Looks interesting, will give it a try.  What other algos are you targeting for addition?

I think next one will be Neoscrypt or phi, my main target is Cryptonight, but it's a hard nut to crack, need to solve this algo random memory access problem/bottleneck/riddle first, current results are not applicable for miner with devfee.

I would certainly welcome any of those three -- keep up the good work!
legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
Thank you for your participation, as I've mentioned, HSR is quite a good base for other algo implementations, many kernels are cross-used and will give me good start in other algo implementation.

Regarding features:

- Would you like ccminer-style intensity setting or should we look at this from a different angle?
- Info verbosity improvement is planned, currently it's ccminer-style, each miner thread outputs all running GPU hashing speeds every minute from actual thread start (+ 10 sec per output) until it reaches 5 min per thread.
- benchmark will definitely be added in future releases

I'm not sure how intensity should be done, but with the default setting now there's some overhead (1-3% GPU usage). In ccminer that means you can get a noticeable speed increase if you push the GPU usage higher with intensity.

Maybe allowing us to change the intensity or even thread/blocks, we, the users could experiment and find the best settings for different cards. I'm not sure how that works for different algos though.
full member
Activity: 405
Merit: 136
Got about 24 Mh/s with GTX1080Ti, but power consumption is unstable: from 205W to 265W (at NvidiaSMI) - variation about 30%. At the same time core voltage and frequency are stable and don't change and GPU load also stable. For example on Equihash algo I don't see so huge variation (no more than 5%)

Thank you for feedback, on my testrigs power consumption isn't fluctuating so much, have you tested on one specific card or on a rig?

It's my test rig. now with only one GPU 1080Ti. I just tested it only with equihash and HSR now. What tests do you recommend? It's win machine and I would not like to install Linux but if it will be especially interest test I would try
sr. member
Activity: 266
Merit: 250
Got about 24 Mh/s with GTX1080Ti, but power consumption is unstable: from 205W to 265W (at NvidiaSMI) - variation about 30%. At the same time core voltage and frequency are stable and don't change and GPU load also stable. For example on Equihash algo I don't see so huge variation (no more than 5%)

Thank you for feedback, on my testrigs power consumption isn't fluctuating so much, have you tested on one specific card or on a rig?
sr. member
Activity: 266
Merit: 250
Hey,

Any API support? I can list it for EthMonitoring.com

Unfortunately, currently no API functional (it's present, but not operational at the moment), very poor control, I know. From vresion 1.1.x API will be fully functional.

Currently I'm more focused on CUDA kernels, alexkap is busy on another project at the moment, you can read more about further developement plan in the first post.
sr. member
Activity: 392
Merit: 266
EthMonitoring.com
Hey,

Any API support? I can list it for EthMonitoring.com
full member
Activity: 405
Merit: 136
Got about 24 Mh/s with GTX1080Ti, but power consumption is unstable: from 205W to 265W (at NvidiaSMI) - variation about 30%. At the same time core voltage and frequency are stable and don't change and GPU load also stable. For example on Equihash algo I don't see so huge variation (no more than 5%)
Pages:
Jump to: