for me miniZ have less CPU utilisation on 12x1070 CPU3930 4Gb ubuntu 16 cuda 9.2
Hi topteam, thank you for letting us know. Which nvidia driver version are you using? Cheers Driver Version: 396.82 |
|
|
|
Your miner gets gradually slow on systems with many GPUs. It starts off with higher hashrate for the first few minutes and then slowly drops by up to 30% in speed. This is a sign of too much driver comms, keeping the CPU swamped with irq requests (Gminer had the same problem a few months ago but they fixed it).
You should find a way to drop CPU utilization and driver usage. You should also add an option to disable nvml polling of temperature, fans, power etc.
13x gtx1070, i3-7100, 8 GB ram, Ubuntu x64, nvidia 415.27, cuda 10.0
Gminer 150,5: 280-290 H/s, steady. CPU utilization is 40-50%. I can communicate with the GPUs while it's mining as usual.
miniZ 150,5: starts at ~250 H/s for a about 1 minute, then gradually drops to ~180 H/s within ~2 minutes. CPU is kept at 100% at all times and any GPU command issued hangs (e.g. nvidia-smi hangs entirely). The nvidia driver is totally hogged.
I tried lowering --intensity and the CPU utilization drops, but the hashrate drops significantly too, even if I use --intensity 99. Max I can get is about ~195 H/s.
I also tried --oc1 and --oc2. Also tried --telemetry 0 (doesn't disable nvml polling). Nothing made any difference (even though I have them overclocked and at lower power limits).
I'm willing to test a beta if you're willing to work on this. PM me. I manage a small farm.
EDIT: Retested Gminer on 150,5. Gets 280-290 H/s steady, with 40-50% CPU utilization.
for me miniZ have less CPU utilisation on 12x1070 CPU3930 4Gb ubuntu 16 cuda 9.2 |
|
|
|
Hi,
version 3.0.0 release.
This is the first release of TT-Miner for Windows & Linux. They are based on the same source-code (as far as possible) and may show the same bugs. Anyway I tried to get this release as clean as possible.
- first linux & windows release
- bug fixes (high number of GPUs 8 and more)
- support for Abassian
- support of BeePool
- new command line option: -compute INT to define a certain compute version for you GPU (required if you run RTX interfaces with older cuda)
- new command line option: -notimestamp for output on screen
- new default for 'crashdumps' is now: nocrashdump. Do enable crashdump creation add -ccd
If you want to run TT-Miner under HiveOS please make sure to give TT access to the cuda folder first with:
LD_LIBRARY_PATH=/hive/lib
Please let me know if you run into issues or see any other problem.
Thanks and: Happy Mining
Thanks!!! Please swap versions in readme  Please note these requirements for the different cuda toolkit releases:
Cuda-Toolkit Windows Linux
CUDA 10.1.105 >= 418.39 >= 418.96
CUDA 10.0.130 >= 410.48 >= 411.31
CUDA 9.2.148 >= 396.37 >= 398.26
|
|
|
|
|
24
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: TT-Miner 2.2.5: ProgPoW(Z,H,092), MTP, LYRA2V3, UBQHASH, TETHASHV1, Win, cuda
|
on: July 11, 2019, 05:07:53 PM
|
Hi, I'm rewriting most of the miner at the moment to get it ready for linux as well. so with this rewrite a new communication layer will come, I will address this issue as well for this version.
We are very much looking forward to the Linux version, and especially the appearance of the TT-Miner in HIVE OS +1 |
|
|
|
|
25
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: TT-Miner 2.2.5: ProgPoW(Z,H,092), MTP, LYRA2V3, UBQHASH, TETHASHV1, Win, cuda
|
on: June 10, 2019, 10:33:59 AM
|
Hello, and when to appear at least beta test linux version?
+1 |
|
|
|
|
How i can backup SERO Flight-Light Wallet?
|
|
|
|
any popular coins you want to see in Bminer? please make sure to leave the reasons. thx.
new ZEL algo, instead of ZHASH |
|
|
|
hashrate drop after devfee session on MTP algo, can you check?
Same happend to me, I was mining around 14.4 Mh/s, after de devfee kicked it went down to 13.1 Mh/s and didn't come back up to the 14s You'll still be better off with TT-miner for MTP. TrailingStop's done a good job on that algo, and I doubt you'll see any improvement using CryptoDredge. TT-miner don't have linux version  |
|
|
|
hashrate drop after devfee session on MTP algo, can you check?
That's coz dev session is excluded from avg. h\r calculation no this effect on argon2d4096 algo, for example |
|
|
|
|
hashrate drop after devfee session on MTP algo, can you check?
|
|
|
|
realbminer, two last releases are dedicated to ETH+VBK mining improvements how about cuckoo ? is it highest bound ? and beam and zhash algos? |
|
|
|
I see rejects on pool side, but no one reject on miner Can you check (beam, pool btc.com)? [ 0d19h10m36s] S:4627/0 288(287.8)Sol/s 1639(1628.4)W [eu-beam.ss.btc.com,Beam-PoW]- 44ms (98.0%) (2.0%)  Hi topteam, thank you for reporting this. It may be the case that the server is not reporting invalid shares, or that these are stale shares and in this case they show up in telemetry. Just to confirm, are you are using miniZ v1.3n3? Cheers Yes, miniZ v1.3n3 |
|
|
|
I see rejects on pool side, but no one reject on miner Can you check (beam, pool btc.com)? [ 0d19h10m36s] S:4627/0 288(287.8)Sol/s 1639(1628.4)W [eu-beam.ss.btc.com,Beam-PoW]- 44ms (98.0%) (2.0%) |
|
|
|
Not stable for me Crash on one card, intensity 90 not help Error on GPU2: an illegal memory access was encountered Too much connection error Connection Error: Write timed out
Connect to eu-beam.ss.btc.com:1800 Failed: Host not found (non-authoritative), try again later
Connected to eu-beam.ss.btc.com:1800 |
|
|
|
Latest 1.3n+ still suffer from miner offline in pool just like the previous version. Whatever changes on this version doesn't fix the dreaded offline. Mining on algo 150.5.
Hi ARTRN, We are sorry about that... We really want to get rid of that issue, but it is very hard to replicate. On which pool were you mining? Thanks. Cheers have the same problem on 1.3n+, now run 1.3n2 ubuntu 16 396.82, 144,5, miningpoolhub |
|
|
|
|
Thanks!!!
Now work like a rock solid
|
|
|
|
not stable for me, back to version v1.2m kernel: [ 678.861888] show_signal_msg: 18 callbacks suppressed
kernel: [ 678.861891] miniZ[2386]: segfault at c0 ip 0000560d8618c982 sp 00007fcc10ff2bd0 error 4 in miniZ[560d86098000+1fea000]
1775 Segmentation fault (core dumped) ~/miniZ --url user@europe.equihash-hub.miningpoolhub.com:20595 --pers BgoldPoW --par=144,5 --nocolor --telemetry 0 --gpu-line --extra --templimit 70C --tempunits C --latency --show-solratio --show-pers --shares-detail --oc2
Hi topteam, sorry for this. Could you post here a bit of the log just before the crash? Thanks. Cheers nothing special [ 0d 0h 5m19s] S: 31/0 744(732.4)Sol/s 1641(1589.8)W [fee.server]- 105ms (95.9%) (4.1%)
0>GTX 1070 S: 0/0 [60°C/65%] 28.91 I/s 58.4(58.2)Sol/s 141(139.8)W clk=1746MHz mclk=4452MHz Sol/W=0.42 2.00 Sol/I
1>GTX 1070 S: 0/0 [55°C/50%] 29.40 I/s 59.0(59.1)Sol/s 137(137.5)W clk=1784MHz mclk=4452MHz Sol/W=0.43 2.00 Sol/I
2>GTX 1070 S: 0/0 [56°C/50%] 29.60 I/s 58.2(58.3)Sol/s 137(136.7)W clk=1822MHz mclk=4452MHz Sol/W=0.43 1.97 Sol/I
3>GTX 1070 S: 0/0 [53°C/50%] 30.01 I/s 60.7(60.6)Sol/s 136(135.0)W clk=1835MHz mclk=4452MHz Sol/W=0.45 2.00 Sol/I
4>GTX 1070 S: 0/0 [54°C/50%] 30.07 I/s 59.4(59.4)Sol/s 135(136.4)W clk=1835MHz mclk=4452MHz Sol/W=0.44 1.98 Sol/I
5>GTX 1070 Ti S: 0/0 [48°C/50%] 34.00 I/s 66.9(67.0)Sol/s 135(129.1)W clk=1784MHz mclk=4452MHz Sol/W=0.52 1.96 Sol/I
6>GTX 1070 Ti S: 0/0 [48°C/50%] 33.95 I/s 67.2(67.3)Sol/s 138(128.3)W clk=1771MHz mclk=4452MHz Sol/W=0.52 1.99 Sol/I
7>GTX 1070 Ti S: 0/0 [56°C/50%] 33.58 I/s 67.5(67.3)Sol/s 140(136.1)W clk=1759MHz mclk=4452MHz Sol/W=0.49 2.00 Sol/I
8>GTX 1070 Ti S: 0/0 [54°C/50%] 33.74 I/s 66.1(66.1)Sol/s 138(135.4)W clk=1759MHz mclk=4452MHz Sol/W=0.49 1.97 Sol/I
9>GTX 1070 Ti S: 0/0 [55°C/50%] 34.02 I/s 68.7(68.7)Sol/s 137(118.5)W clk=1784MHz mclk=4452MHz Sol/W=0.58 2.00 Sol/I
10>GTX 1070 Ti S: 0/0 [60°C/65%] 32.93 I/s 65.9(66.0)Sol/s 134(134.6)W clk=1708MHz mclk=4452MHz Sol/W=0.49 2.00 Sol/I
11>GTX 1070 Ti S: 0/0 [53°C/50%] 33.41 I/s 66.5(66.4)Sol/s 132(122.3)W clk=1759MHz mclk=4452MHz Sol/W=0.54 1.97 Sol/I
[ 0d 0h 5m29s] S: 31/0 747(734.8)Sol/s 1615(1589.9)W [fee.server]- 105ms (95.9%) (4.1%)
0>GTX 1070 S: 0/0 [60°C/65%] 28.91 I/s 58.3(58.1)Sol/s 116(136.9)W clk=1771MHz mclk=4452MHz Sol/W=0.42 2.00 Sol/I
1>GTX 1070 S: 0/0 [55°C/50%] 29.41 I/s 59.1(59.1)Sol/s 138(137.5)W clk=1784MHz mclk=4452MHz Sol/W=0.43 2.00 Sol/I
2>GTX 1070 S: 0/0 [56°C/50%] 29.61 I/s 58.1(58.2)Sol/s 138(136.9)W clk=1809MHz mclk=4452MHz Sol/W=0.43 1.97 Sol/I
3>GTX 1070 S: 0/0 [53°C/50%] 30.02 I/s 60.6(60.5)Sol/s 137(135.2)W clk=1822MHz mclk=4452MHz Sol/W=0.45 1.99 Sol/I
4>GTX 1070 S: 0/0 [54°C/50%] 30.06 I/s 59.6(59.5)Sol/s 136(136.4)W clk=1809MHz mclk=4452MHz Sol/W=0.44 1.99 Sol/I
5>GTX 1070 Ti S: 0/0 [48°C/50%] 34.00 I/s 66.6(66.7)Sol/s 133(129.2)W clk=1784MHz mclk=4452MHz Sol/W=0.52 1.97 Sol/I
6>GTX 1070 Ti S: 0/0 [48°C/50%] 33.95 I/s 67.5(67.5)Sol/s 139(129.0)W clk=1771MHz mclk=4452MHz Sol/W=0.52 1.99 Sol/I
7>GTX 1070 Ti S: 0/0 [56°C/50%] 33.58 I/s 67.6(67.4)Sol/s 140(136.3)W clk=1759MHz mclk=4452MHz Sol/W=0.49 2.00 Sol/I
8>GTX 1070 Ti S: 0/0 [54°C/50%] 33.73 I/s 66.8(66.6)Sol/s 133(135.0)W clk=1771MHz mclk=4452MHz Sol/W=0.49 1.98 Sol/I
9>GTX 1070 Ti S: 0/0 [55°C/50%] 34.03 I/s 68.9(68.9)Sol/s 138(119.8)W clk=1784MHz mclk=4452MHz Sol/W=0.57 2.00 Sol/I
10>GTX 1070 Ti S: 0/0 [60°C/65%] 32.93 I/s 66.2(66.2)Sol/s 131(134.1)W clk=1708MHz mclk=4452MHz Sol/W=0.49 2.00 Sol/I
11>GTX 1070 Ti S: 0/0 [54°C/50%] 33.42 I/s 66.3(66.3)Sol/s 137(123.5)W clk=1759MHz mclk=4452MHz Sol/W=0.54 1.97 Sol/I
[ 0d 0h 5m39s] S: 31/0 748(736.0)Sol/s 1629(1593.0)W [fee.server]- 105ms (95.9%) (4.1%)
0>GTX 1070 S: 0/0 [60°C/65%] 28.91 I/s 58.2(58.1)Sol/s 129(137.1)W clk=1746MHz mclk=4452MHz Sol/W=0.42 2.00 Sol/I
1>GTX 1070 S: 0/0 [55°C/50%] 29.41 I/s 58.8(59.0)Sol/s 139(137.7)W clk=1784MHz mclk=4452MHz Sol/W=0.43 2.00 Sol/I
kernel: [ 678.861888] show_signal_msg: 18 callbacks suppressed
kernel: [ 678.861891] miniZ[2386]: segfault at c0 ip 0000560d8618c982 sp 00007fcc10ff2bd0 error 4 in miniZ[560d86098000+1fea000]
1775 Segmentation fault (core dumped) ~/miniZ --user@europe.equihash-hub.miningpoolhub.com:20595 --pers BgoldPoW --par=144,5 --nocolor --telemetry 0 --gpu-line --extra --templimit 70C --tempunits C --latency --show-solratio --show-pers --shares-detail --oc2
PS crash on fee.server |
|
|
|
not stable for me, back to version v1.2m kernel: [ 678.861888] show_signal_msg: 18 callbacks suppressed
kernel: [ 678.861891] miniZ[2386]: segfault at c0 ip 0000560d8618c982 sp 00007fcc10ff2bd0 error 4 in miniZ[560d86098000+1fea000]
1775 Segmentation fault (core dumped) ~/miniZ --url user@europe.equihash-hub.miningpoolhub.com:20595 --pers BgoldPoW --par=144,5 --nocolor --telemetry 0 --gpu-line --extra --templimit 70C --tempunits C --latency --show-solratio --show-pers --shares-detail --oc2
|
|
|
|
Ubuntu 16.04, nvidi 415.27, cuda10, 13x gtx1070, g3930 (2.9ghz dual core) ... is there a reason why the -intensity option sometimes has an effect and sometimes makes absolutely no difference?
Setting -intensity 3 sometimes does bring down the cpu usage to 80% and using nvidia-smi actually works with little delay; and setting -intensity 12 puts cpu usage at 100% and nvidia-smi barely moves, delaying all output by 10-20 seconds.
But sometimes setting -intensity 3 or -intensity 12 makes no difference whatsoever, bot resulting in cpu usage of 95-100% and nvidia-smi being somewhere between slow and medium slow (a few seconds delay, but usable).
Anyone else?
for me, intensity stop working after 15.0.0 version just overload cpu Ubuntu 16.04, nvidia 396.82, cuda 9.2, 12x gtx1070, g3930, GRIN 29 or 31 maybe because i use "old" driver  |
|
|
|
|
Show Posts
