 Show Posts
|
|
Pages: [1] 2 »
|
+ support BeamHashIII algorithm for Nvidia GPUs (for auto-switching use algo --beamhash)
I just tested the newest gminer update. I pointed it to a test pool that is already past block 777777 (so on BeamHashIII) and got 18-19 Sol/s with my 1070ti's (using the same Afterburner settings as with BeamHashII). Now the interesting thing is that I then pointed it to my node (so still BeamHashII) to solo mine and I was getting 18-19 Sol/s on there too. I then ran against my node the previous gminer version that I had been running and it got 40+ Sol/s as I expected (again, no changes in Afterburner settings). Any idea why I am seeing very low hashrate while mining BeamHashII with this latest version? We figured out what the issue is. If you test BeamHashIII on a test pool and it is past block 777777, gminer creates a 0k file in the miner folder. With this file there, gminer will continue to run on BeamHashIII even if you go back to a regular mainnet pool that has not yet hit block 777777. To get your hashrate back and to have it actually mine on BeamHashII again, you must delete that 0k file. |
|
|
|
+ support BeamHashIII algorithm for Nvidia GPUs (for auto-switching use algo --beamhash)
I just tested the newest gminer update. I pointed it to a test pool that is already past block 777777 (so on BeamHashIII) and got 18-19 Sol/s with my 1070ti's (using the same Afterburner settings as with BeamHashII). Now the interesting thing is that I then pointed it to my node (so still BeamHashII) to solo mine and I was getting 18-19 Sol/s on there too. I then ran against my node the previous gminer version that I had been running and it got 40+ Sol/s as I expected (again, no changes in Afterburner settings). Any idea why I am seeing very low hashrate while mining BeamHashII with this latest version? |
|
|
|
|
What is the best frequency at which to run the F1mini+ for Odocrypt? Any reason to change from the default 560M? Thanks
|
|
|
|
The miner does not print to the console when an overclock "OC" kernel is in effect. Whatever improvement to the hash rate that results from the kernel seems minimal at best.
Miner print when selected OC kernel: "Selected OC1 solver" When there is no OC1 kernel for card and algorithm then miner print "Selected Normal solver" How to set OC paremeter in config files? Maybe "sample-config" needs to be updated?
Will do it in next update, example: oc=0 1 1 0 1 1 I am running v1.60. This is the syntax I tried but it will not work for me. I have a PNY xlr8 1070 card in a rig with 3 1070ti cards. I run two miner instances, one with "devices=0" to run the 1070 buy itself and the other with "devices=1 2 3" for the 1070ti cards. For my 1070 config file, I added OC=1, but it still uses the normal solver. Additional question... I have another computer with two 1070 cards that I run in different miner instances because I am running one for me and one for my brother. So in one config file, I have devices=0 and the other config file I have devices=1. Does the "OC=" line reference the GPU in the devices= line or reference the GPU in the system? In other words, for the config file that has devices=1, would OC=1 reference the GPU in the devices line (GPU1) or would it reference GPU0 on the system? Thanks |
|
|
|
Good day miniZ
Trying to download v1.5q2_cuda10_win and I keep getting trojan/virus alert from Defender. Is this just defender being difficult? Do I need to exclude v1.5q2 before unzipping? I'm running 144_5 now and changing to Beam. Anyone have a suggestion on a pool? Looking at Leafpool, now
Thanks in advance for the help.
BigHarryArmsi, Yes, you will have to exclude it from antivirus. Also, give the Sunpool.top pool a try. I have been mining there since the end of January. Great pool, no complaints. You can use a different address for each payout if you like. Just read and understand the first page and record in a safe place the private and public keys. The pool op is very active in the Beam Discord. |
|
|
|
|
I am testing GMiner 1.52 against a test pool that passes a block height of 321321 back to the miner so I can see what settings might be best for my GPUs after the hard fork. We have noticed that it will only successfully mine if we use algo=BeamHashII, forcing the new algo. If we use algo=BeamHash, which should auto-switch at block 321321, it does not work. What is the technical mechanism Gminer will use to auto-switch the algo at the fork height?
Thanks
|
|
|
|
|
Miniz,
Can you make a change to your website so the checksums on the download page can easily be selected and copied? Right now, it is not possible without viewing page source. This was a request from someone on Discord.
Thanks
|
|
|
|
just switched to 1.3n5 and found a decrease of 40w across the rig with no drop is hashrate. amazeballs!
Very interesting. I upgraded also and actually saw zero drop in wattage on my 8-card rig. I know, I know, it's because i'm using Win10!  Which version did you switch from? |
|
|
|
Error when mining on dev [fee.server].
Hi hogwash.89m, thanks for reporting this. We never had that error. We are looking into this. Cheers It happens sometimes, after long run. And I think it can be connected to sudden crush when mining on fee.server, it happens to me once. This error I saw few times already. miniZ, I also had the miner crash once last night. I'm glad I had asked for that runtime/local time modification because that made it very simple to spot it and then find it in the log. You can see that it was on the dev fee and then the miner started up again (I have it in a loop in the bat file). I am guessing no errors were written to the log because the miner just crashed. Thanks again for your great work... [ 0d 5h55m22s|00:48:25 01/05/2019] S:1592/0 199(197.9)Sol/s 979(980.4)W [fee.server]- 137ms (97.9%) (2.1%)
0>GTX 1070 Ti `S:212/0 [47øC/59%] 12.33 I/s 24.0(24.5)Sol/s 121(123.4)W clk=1594MHz mclk=3553MHz Sol/W=0.20
1>GTX 1070 Ti `S:187/0 [53øC/69%]*12.47 I/s 24.6(24.7)Sol/s 124(122.5)W clk=1417MHz mclk=3553MHz Sol/W=0.20
2>GTX 1070 Ti `S:185/0 [50øC/64%]*12.51 I/s 25.1(24.9)Sol/s 115(122.2)W clk=1544MHz mclk=3553MHz Sol/W=0.20
3>GTX 1070 Ti `S:200/0 [52øC/67%]*12.43 I/s 25.0(24.7)Sol/s 130(122.6)W clk=1468MHz mclk=3553MHz Sol/W=0.20
4>GTX 1070 Ti `S:217/0 [53øC/68%]*12.43 I/s 25.0(24.7)Sol/s 121(121.1)W clk=1506MHz mclk=3553MHz Sol/W=0.20
5>GTX 1070 Ti `S:211/0 [53øC/68%] 12.30 I/s 24.7(24.4)Sol/s 124(121.9)W clk=1455MHz mclk=3553MHz Sol/W=0.20
6>GTX 1070 Ti `S:157/0 [51øC/65%]*12.54 I/s 24.8(24.9)Sol/s 122(122.9)W clk=1594MHz mclk=3553MHz Sol/W=0.20
7>GTX 1070 Ti `S:182/0 [54øC/70%]*12.71 I/s 25.1(25.2)Sol/s 123(122.2)W clk=1607MHz mclk=3553MHz Sol/W=0.21
[ 0d 5h55m33s|00:48:37 01/05/2019] S:1599/0 199(197.9)Sol/s 993(980.9)W [fee.server]- 134ms (97.9%) (2.1%)
0>GTX 1070 Ti `S:212/0 [47øC/59%] 12.32 I/s 24.1(24.5)Sol/s 126(123.4)W clk=1556MHz mclk=3553MHz Sol/W=0.20
1>GTX 1070 Ti `S:187/0 [53øC/68%] 12.48 I/s 24.9(24.7)Sol/s 127(122.5)W clk=1480MHz mclk=3553MHz Sol/W=0.20
2>GTX 1070 Ti `S:185/0 [50øC/64%] 12.51 I/s 25.1(24.9)Sol/s 118(122.2)W clk=1506MHz mclk=3553MHz Sol/W=0.20
3>GTX 1070 Ti `S:200/0 [52øC/67%] 12.43 I/s 25.1(24.7)Sol/s 125(122.6)W clk=1430MHz mclk=3553MHz Sol/W=0.20
4>GTX 1070 Ti `S:217/0 [53øC/68%] 12.43 I/s 24.8(24.6)Sol/s 124(121.1)W clk=1531MHz mclk=3553MHz Sol/W=0.20
5>GTX 1070 Ti `S:211/0 [53øC/68%] 12.30 I/s 24.6(24.4)Sol/s 127(121.9)W clk=1379MHz mclk=3553MHz Sol/W=0.20
6>GTX 1070 Ti `S:157/0 [51øC/67%] 12.54 I/s 24.7(24.9)Sol/s 126(122.9)W clk=1354MHz mclk=3553MHz Sol/W=0.20
7>GTX 1070 Ti `S:182/0 [54øC/70%] 12.71 I/s 25.1(25.2)Sol/s 122(122.2)W clk=1569MHz mclk=3553MHz Sol/W=0.21
Number of CUDA devices found: 8
miniZ,150,5[1:0:00]: Selecting GPU#0[0] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#1[1] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#2[2] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#3[3] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#4[4] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#5[5] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#6[6] GeForce GTX 1070 Ti
miniZ,150,5[1:0:00]: Selecting GPU#7[7] GeForce GTX 1070 Ti
Algo: EQ[150,5]
Pool#0: user[0480437dc7c1c92f2e2b992b5b33cfb2483e9f827ca8eb5bcddd880a6feeb92e.C_G_1070Ti]
server[beam.sunpool.top] port[3334] ssl[yes] pers[Beam-PoW]
Logging:: file[miniZ.log] period[10] delay[0]
Temp. limit: [70øC]
[ 0d 0h 0m09s|00:48:53 01/05/2019] S: 1/0 168(168.2)Sol/s 483(482.6)W [beam.sunpool.top]- 128ms (100.0%) (0.0%)
0>GTX 1070 Ti `S: 0/0 [41øC/52%] 10.38 I/s 19.5(19.5)Sol/s 37( 37.1)W clk=1607MHz mclk=3553MHz Sol/W=0.53
1>GTX 1070 Ti `S: 0/0 [47øC/61%] 10.47 I/s 19.7(19.7)Sol/s 38( 38.0)W clk=1607MHz mclk=3553MHz Sol/W=0.52
2>GTX 1070 Ti `S: 0/0 [45øC/56%] 11.14 I/s 23.5(23.5)Sol/s 126(125.6)W clk=1594MHz mclk=3553MHz Sol/W=0.19
3>GTX 1070 Ti `S: 0/0 [46øC/60%] 10.46 I/s 17.6(17.6)Sol/s 41( 41.4)W clk=1607MHz mclk=3553MHz Sol/W=0.43
4>GTX 1070 Ti `S: 0/0 [46øC/60%] 10.28 I/s 18.0(18.0)Sol/s 38( 38.1)W clk=1620MHz mclk=3553MHz Sol/W=0.47
5>GTX 1070 Ti `S: 0/0 [49øC/59%] 10.94 I/s 19.9(19.9)Sol/s 123(122.9)W clk=1480MHz mclk=3553MHz Sol/W=0.16
6>GTX 1070 Ti `S: 0/0 [44øC/57%] 10.50 I/s 23.0(23.0)Sol/s 40( 39.5)W clk=1607MHz mclk=3553MHz Sol/W=0.58
7>GTX 1070 Ti `S: 0/0 [49øC/65%] 10.35 I/s 16.8(16.8)Sol/s 40( 40.1)W clk=1607MHz mclk=3553MHz Sol/W=0.42
|
|
|
|
miniZ,
Things have been running pretty well for me the past 24 hours. I think my only crash was because I was on the edge on my power and clock settings. One thing though... I noticed that when I start the miner, about 30-45 seconds later (one time it was around 2 minutes) it sends 2 invalid shares to the pool. It did it this evening when I restarted 3 of my mining processes. These invalid shares occur before it starts to submit the dev fee. Not a huge issue, but I thought I would mention it.
Much thanks for your work on this...
Hi DanGB, Thank you for the feedback. We did a check just now and we did not experience the same couple of invalid shares during the first minutes. We will keep looking. Could you let us know to which pool were you mining? Cheers Sunpool |
|
|
|
|
miniZ,
Things have been running pretty well for me the past 24 hours. I think my only crash was because I was on the edge on my power and clock settings. One thing though... I noticed that when I start the miner, about 30-45 seconds later (one time it was around 2 minutes) it sends 2 invalid shares to the pool. It did it this evening when I restarted 3 of my mining processes. These invalid shares occur before it starts to submit the dev fee. Not a huge issue, but I thought I would mention it.
Much thanks for your work on this...
|
|
|
|
Hi DanGB, OCs may need to be adjusted when changing miner. We share some values on our website ( https://miniz.ch/1505-2/). They are just a reference, you may need to adjusted for your configuration. When limitig power, performance may benefit from using --oc1. Cheers miniZ, I tried --oc1. My 1070 in that rig runs about 1.5 Sol/s better with it, but my 1070ti's run about 5 Sol/s less, so I took it back out. I'll try tweaking my settings if it continues to crash. No issues with my other rigs. Running great for 11.5 hours now. One question... would it be possible to give us the option to show both run time and local time? That way, it's easy to see how long it has been running, but also when looking at the logs, you can see when something happened. Thanks |
|
|
|
miniZ - The miner on my one rig crashed. It ran for 7.5 hours. This is the error in the log:
GPU[2]: CUDA error 'unspecified launch failure' in func 'eq_a[[[ac>5;:c_26dEbB, SM, PS2>::solve' line 957
GPU[0]: CUDA error 'unspecified launch failure' in func 'eq_a[[[ac>5;:c_26dEbB, SM, PS2>::solve' line 957
This rig has an i5 CPU and 4GB ram running Win10x64. NVIDIA driver version is 417.35.
Hi DanGB, Thank you for the test. That Cuda error is not related to the other issue. This may be related to your GPUs OCs. Remind us which GPUs and OCs are you using. Nevertheles, we have updated the testing file with few more small corrections. miniZ v1.3n++ @ cuda v10.0, Apr 28 2019 20:05:51 Thanks. Cheers Those two specific cards are as follows (settings done with Afterburner): GPU0 - PNY 1070 XLR8 Power 66%, temp limit 65deg, core +160, mem +0 GPU2 - EVGA 1070ti FTW2 Power 66%, temp limit 70deg, core +200, mem +0 These are the settings I had been using on gminer since January. Thanks |
|
|
|
|
miniZ - The miner on my one rig crashed. It ran for 7.5 hours. This is the error in the log:
GPU[2]: CUDA error 'unspecified launch failure' in func 'eq_a[[[ac>5;:c_26dEbB, SM, PS2>::solve' line 957
GPU[0]: CUDA error 'unspecified launch failure' in func 'eq_a[[[ac>5;:c_26dEbB, SM, PS2>::solve' line 957
This rig has an i5 CPU and 4GB ram running Win10x64. NVIDIA driver version is 417.35.
|
|
|
|
FYI, v1.3n++ still have the same 'losing miner' on pool. Cheers.
Hi ARTRN, Thanks a lot for your quick feedback. It looks like you can replicate faster the problem than we do! Now, we know what it is (the communication with the pool gets into some weird state and the miner was getting stuck trying to recover). We fixed it, but it still requires testing... This stage will be much faster with some extra help  The miniZ v1.3n++ testing version (Win 10, Cuda10) was updated. You can download from our Download page https://miniz.ch/download/We did not change the version name, so check you have the right build with miniZ.exe --version It should be Apr 28 2019 12:28:20Cheers, miniZ Hi, miniZ v1.3n++ testing version (Win 10, Cuda10) Apr 28 2019 12:28:20 so far so good. It's been running close to 4 hours without fail. Cheers. miniZ - I agree. I am at 5 hours now with no issues, so I am hopeful. CPU utilization is holding steady so far. I need to get to 12 hours with no issues before I will be pretty confident that it is resolved. |
|
|
|
The miniZ v1.3n++ testing version (Win 10, Cuda10) was updated. You can download from our Download page https://miniz.ch/download/We did not change the version name, so check you have the right build with miniZ.exe --version It should be Apr 28 2019 12:28:20Cheers, miniZ miniZ - I have this latest version running on my 3 rigs right now. The CPU utilization is a little better on my two Celeron rigs (74% and 89% instead of 100%). I'll let you know how it goes. |
|
|
|
Hi Dan, We tested on win10, Celeron(R) G4900, v1.3n+, with no problem. But we will keep looking  Thanks. Cheers miniZ - As mentioned earlier, I am running the latest miniZ (what I'm calling v1.3n++ since there was another update with no version change). My rig with the i5 CPU that had the CPU running at a nice low % failed just a short bit ago. It looks like about 30 minutes ago, miniZ stopped communicating with sunpool and also stopped writing to the log, but the mine window had activity. Then the miner window crashed and just closed a couple minutes ago. Nothing was in the log since it stopped writing to it about 30 minutes ago. I will let my other 2 rigs with Celeron CPUs run for a bit longer, but I will have to switch them off miniZ overnight. |
|
|
|
Just installed miniZ miner v1.3n+ from website
on my 1080s rig all works fine - CPU 33 %(+12% Sols compare to gminer)
on my 1060s rig not good - CPU 99 %
You'll have to give it up to 24 hours to know for sure. I had it fail between 1 and 12 hours. What CPUs are you running on your rigs? |
|
|
|
Hi Dan, We tested on win10, Celeron(R) G4900, v1.3n+, with no problem. But we will keep looking Thanks. Cheers I have the newest version running on my 3 rigs (Celeron 3900, Celeron 3930, and i5 CPU). I will let you know how it goes. |
|
|
|
miniZ - I downloaded the newest update (I'll refer to it as v1.3n++). It is running, but CPU still got up to 100%. It took about 1 minute for all 8 cards to actually start working (see logs below) and by the time the last card was going, CPU was at 100%. I will have to run it for a while to see if it stops sending shares to the pool or crashes. Thanks
Hi DanGB, Thanks for all the feedback. Could you see which process is occupying 100%? We have been unable replicate your error exactly. Cheers miniZ - Windows Command Processor (which is miniZ.exe underneath that) is about 65%-75% and System is about 20%-25% and System interrupts just a couple %. Have you been able to test with a Celeron processor, because my i5 works better (not sure yet if it is stable). |
|
|
|
|
