Topic: NxtMint Java minter (Read 58322 times)

achim · « **Reply #60 on:** January 17, 2015, 03:27:28 pm »

Quote from: ScripterRon on January 17, 2015, 03:22:35 pm

Quote from: achim on January 17, 2015, 03:04:01 pm
217 MH/s for egold would be pretty nice
it's all good now, I'm crunching along with 18 MH/s, probably set the intensity too high before.
Yep - I misread your append. Out of curiousity, is that an NVIDIA or an AMD card? I'd like to get an idea of the differences between the various cards. Since the GPU kernel program is built just once and then reused for each kernel instance, Java vs native shouldn't be an issue for GPU hashing. CPU hashing benefits from JIT although a native implementation would certainly be faster (but I don't know what the performance difference actually is).

GPU is 8870m AMD, on a samsung chronos 7 notebook.
GPU does 17 MH/s on a slight overclock 900/1300

lopalcar · « **Reply #61 on:** January 17, 2015, 04:13:43 pm »

Any ways to enable more than one GPU in the same machine? I have one double core GPU from the scrypt mining times and need to heat a bit the room

And why the GPU core in use isn't at 100% even using 30 intensity?, I checked with 25 and 30 but this isn't increassing the usage :S

anyways, post your nxt address and will send you some EGOLD for your work! Thanks for the miner

Pfool · « **Reply #62 on:** January 17, 2015, 04:20:10 pm »

Thank you ScripterRon!

I was trying to make a GPU miner with aparapi like you but only achieve to get a 2.2 MH/s speed. I have integrated your kernel in my miner and I am now at 145 MH/s with my HD 7950 @ 950MHz. I am running your kernel with an equivalent intensity of 256.

Good job!

Jimmy2011 · « **Reply #63 on:** January 17, 2015, 04:21:14 pm »

I remote login to my computer with GPU, and then shutdown the NxtMint to change some parameters. I got the following error when I restart it again. Can I remotely start NxtMint with GPU?

Code: [Select]

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000005ee0e685, pid=2220, tid=6868
#
# JRE version: Java(TM) SE Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# V  [jvm.dll+0x12e685]

lopalcar · « **Reply #64 on:** January 17, 2015, 04:23:35 pm »

Quote from: lopalcar on January 17, 2015, 04:13:43 pm

Any ways to enable more than one GPU in the same machine? I have one double core GPU from the scrypt mining times and need to heat a bit the room
And why the GPU core in use isn't at 100% even using 30 intensity?, I checked with 25 and 30 but this isn't increassing the usage :S

anyways, post your nxt address and will send you some EGOLD for your work! Thanks for the miner

Just realized that maybe the cause to not use more than 80% of GPU could be a bottleneck with the CPU cause only use one thread, and since I have 6 cores-> 12 threads one of the threads get full of work quite easy...
Do you have planed making the process which feeds the GPU with the CPU multicore? Or should I disable hyperthreathing

crimi · « **Reply #65 on:** January 17, 2015, 04:40:44 pm »

Quote from: Pfool on January 17, 2015, 04:20:10 pm

Thank you ScripterRon!

I was trying to make a GPU miner with aparapi like you but only achieve to get a 2.2 MH/s speed. I have integrated your kernel in my miner and I am now at 145 MH/s with my HD 7950 @ 950MHz. I am running your kernel with an equivalent intensity of 256.

Good job!

Thanks for the tip with intensity of 256, long ago i did mine any coin. I was using 10-14 and got 55 MH/s now i have 245 MH/s @r290x tri oc water cooled. 512 even better 265 MH/s.

ScripterRon · « **Reply #66 on:** January 17, 2015, 04:41:36 pm »

Quote from: lopalcar on January 17, 2015, 04:13:43 pm

Any ways to enable more than one GPU in the same machine? I have one double core GPU from the scrypt mining times and need to heat a bit the room
And why the GPU core in use isn't at 100% even using 30 intensity?, I checked with 25 and 30 but this isn't increassing the usage :S

anyways, post your nxt address and will send you some EGOLD for your work! Thanks for the miner

I'll look into that. I don't have the hardware, so I'll need somebody to test it for me once I get it coded. Aparapi just added support for enumerating devices, so it should be interesting times

Nxt account: NXT-XM86-4ZNA-65L5-CDWUE

ScripterRon · « **Reply #67 on:** January 17, 2015, 04:55:32 pm »

Quote from: Jimmy2011 on January 17, 2015, 04:21:14 pm

I remote login to my computer with GPU, and then shutdown the NxtMint to change some parameters. I got the following error when I restart it again. Can I remotely start NxtMint with GPU?

Code: [Select]
# A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000005ee0e685, pid=2220, tid=6868 # # JRE version: Java(TM) SE Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x12e685]

That is an error in the JVM itself. The type of login really shouldn't make a difference unless it has something to do with login access permissions or stdin/stdout/stderr redirection. I don't know if an error in the Aparapi/OpenCL JNI code would show up as a JVM error. Since it points to jvm.dll, that doesn't seem like the problem. If the problem is repeatable, you could try disabling GPU hashing to see if the problem goes away.

Jimmy2011 · « **Reply #68 on:** January 17, 2015, 05:00:03 pm »

Quote from: ScripterRon on January 17, 2015, 04:55:32 pm

Quote from: Jimmy2011 on January 17, 2015, 04:21:14 pm
I remote login to my computer with GPU, and then shutdown the NxtMint to change some parameters. I got the following error when I restart it again. Can I remotely start NxtMint with GPU?

Code: [Select]
# A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000005ee0e685, pid=2220, tid=6868 # # JRE version: Java(TM) SE Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x12e685]
That is an error in the JVM itself. The type of login really shouldn't make a difference unless it has something to do with login access permissions or stdin/stdout/stderr redirection. I don't know if an error in the Aparapi/OpenCL JNI code would show up as a JVM error. Since it points to jvm.dll, that doesn't seem like the problem. If the problem is repeatable, you could try disabling GPU hashing to see if the problem goes away.

It goes well if I disable GPU. It may be system restricted remotely access GPU, because I can't open NVIDIA control panel, which shows me it can't be shown from remote client.

ScripterRon · « **Reply #69 on:** January 17, 2015, 05:06:37 pm »

Quote from: lopalcar on January 17, 2015, 04:23:35 pm

Just realized that maybe the cause to not use more than 80% of GPU could be a bottleneck with the CPU cause only use one thread, and since I have 6 cores-> 12 threads one of the threads get full of work quite easy...
Do you have planed making the process which feeds the GPU with the CPU multicore? Or should I disable hyperthreathing

It could just be that Aparapi/OpenCL isn't fast enough to saturate your GPU. The GPU workload is divided into groups based on the number of GPU processing units on the card. As each group completes, Aparapi starts the next group. Once all groups have finished, Aparapi retrieves the data from GPU memory and restarts the Java thread. There isn't really anything that multi-threading could help with since the data is fairly small (40 bytes of input and 32 bytes of output plus some control fields). The biggest chunk is the kernel code which needs to be loaded into GPU memory. I don't have any control over the internal operation of Aparapi, so I can't change anything there. Increasing gpuIntensity will increase the number of kernel executions before control returns to Java, so that is the best way to increase GPU utilization.

achim · « **Reply #70 on:** January 17, 2015, 05:39:49 pm »

Quote from: achim on January 17, 2015, 03:27:28 pm

Quote from: ScripterRon on January 17, 2015, 03:22:35 pm
Quote from: achim on January 17, 2015, 03:04:01 pm
217 MH/s for egold would be pretty nice
it's all good now, I'm crunching along with 18 MH/s, probably set the intensity too high before.
Yep - I misread your append. Out of curiousity, is that an NVIDIA or an AMD card? I'd like to get an idea of the differences between the various cards. Since the GPU kernel program is built just once and then reused for each kernel instance, Java vs native shouldn't be an issue for GPU hashing. CPU hashing benefits from JIT although a native implementation would certainly be faster (but I don't know what the performance difference actually is).

GPU is 8870m AMD, on a samsung chronos 7 notebook.
GPU does 17 MH/s on a slight overclock 900/1300

cool, with intensity=512 I now get 29 MH/s

jasemoney · « **Reply #71 on:** January 17, 2015, 06:57:14 pm »

I just upped the intensity as it wasnt fully saturated was using like 75%, for 10 I was getting low 40Mhash/s now at 350 im getting 180Mhash/s now its over 90% utilized 73*C at 2.8k fan rpm. FYI the kernel uses very little gpu memory, about 20mb dynamic and 20 mb dedicated

good luck all!

*edit, noted issue.. if solving faster than blocks are being found for nxt if a que forms it doesnt seem to recover, it will just stack addition aolutions into a que and not get around to sending them once a block is found.

ScripterRon · « **Reply #72 on:** January 17, 2015, 10:18:25 pm »

Quote from: jasemoney on January 17, 2015, 06:57:14 pm

I just upped the intensity as it wasnt fully saturated was using like 75%, for 10 I was getting low 40Mhash/s now at 350 im getting 180Mhash/s now its over 90% utilized 73*C at 2.8k fan rpm. FYI the kernel uses very little gpu memory, about 20mb dynamic and 20 mb dedicated
good luck all!

*edit, noted issue.. if solving faster than blocks are being found for nxt if a que forms it doesnt seem to recover, it will just stack addition aolutions into a que and not get around to sending them once a block is found.

I had a queue build up last night and it cleared as blocks were found. Only 1 transaction can be submitted per block. Do you still have the log so you can match solution timestamps to Nxt block timestamps?

ScripterRon · « **Reply #73 on:** January 17, 2015, 10:36:02 pm »

Queuing appears to be working. I mined an easy coin and built up a queue. It cleared as blocks were found. Note that I wait 30 seconds between polls when waiting for the next block to be generated (don't want to overload the server with nuisance API requests)

Code: [Select]

----> Block 335535 generated at 5:16 <----
05:23:15 INFO MintWorker.run: Worker 2 found solution for counter 1
05:23:15 FINE Mint.mint: Solution for counter 1 added to pending queue
05:23:15 INFO Mint.mint: Solution for counter 1 submitted
05:23:17 FINE Mint.mint: Solution for counter 2 added to pending queue
05:23:47 FINE Mint.mint: Solution for counter 3 added to pending queue
05:25:48 FINE Mint.mint: Solution for counter 4 added to pending queue
----> Block 335536 generated at 5:25 <----
05:25:48 INFO Mint.mint: Solution for counter 2 submitted
----> Block 335537 generated at 5:25 <----
05:26:18 INFO Mint.mint: Solution for counter 3 submitted
05:26:48 FINE Mint.mint: Solution for counter 5 added to pending queue
----> Block 335538 generated at 5:27 <----
05:26:49 INFO Mint.mint: Solution for counter 4 submitted
05:28:19 FINE Mint.mint: Solution for counter 6 added to pending queue
----> Block 335539 generated at 5:27 <----
05:28:19 INFO Mint.mint: Solution for counter 5 submitted

jasemoney · « **Reply #74 on:** January 18, 2015, 01:12:12 am »

Thanks for reply, sorry i didnt save it. I could make a new one by submitting for SILVR hehe. If it happens again ill post the log but I'm on EGOLD for the moment.

Side thoughts: what happens when the POW is over for these coins? minting up to 1/1000 at a time, I dont see EGOLD or SILVR lasting more than 10-20 days to run through the POW phase.

ScripterRon · « **Reply #75 on:** January 18, 2015, 02:19:50 am »

Quote from: jasemoney on January 18, 2015, 01:12:12 am

Thanks for reply, sorry i didnt save it. I could make a new one by submitting for SILVR hehe. If it happens again ill post the log but I'm on EGOLD for the moment.

Side thoughts: what happens when the POW is over for these coins? minting up to 1/1000 at a time, I dont see EGOLD or SILVR lasting more than 10-20 days to run through the POW phase.

SILVR will go even faster shortly - I'm testing the GPU version of SHA-256 at the moment

I suppose coins will be created with greater difficulties. I think we are in sandbox mode at the moment, just building sand castles to see what happens.

MAMLCOM · « **Reply #76 on:** January 18, 2015, 02:34:53 am »

Why it's say.. currency code is not valid

ScripterRon · « **Reply #77 on:** January 18, 2015, 02:51:14 am »

Quote from: MAMLCOM on January 18, 2015, 02:34:53 am

Why it's say.. currency code is not valid

What currency code is not valid? Did you update NxtMint.conf with a valid currency? Is NxtMint.conf in the application data directory?

MAMLCOM · « **Reply #78 on:** January 18, 2015, 02:59:06 am »

Quote from: ScripterRon on January 18, 2015, 02:51:14 am

Quote from: MAMLCOM on January 18, 2015, 02:34:53 am
Why it's say.. currency code is not valid
What currency code is not valid? Did you update NxtMint.conf with a valid currency? Is NxtMint.conf in the application data directory?

SEVERE Main.main: Exception during program initialization
java.lang.illegalArgumentException:Currency code is not valid

That miner said... I did update NxtMint.conf with currency EGOLD.. and path i think it's right..

egold · « **Reply #79 on:** January 18, 2015, 03:42:31 am »

Quote from: jasemoney on January 18, 2015, 01:12:12 am

Thanks for reply, sorry i didnt save it. I could make a new one by submitting for SILVR hehe. If it happens again ill post the log but I'm on EGOLD for the moment.

Side thoughts: what happens when the POW is over for these coins? minting up to 1/1000 at a time, I dont see EGOLD or SILVR lasting more than 10-20 days to run through the POW phase.

EGOLD POW phase will last much longer, you should check EGOLD properties

News:

Author Topic: NxtMint Java minter (Read 58322 times)