[ANN] [Metiscoin] [MTS] Unique algorithm | NO PREMINE| NEW POOL! CPU/GPU

[girino]

The quick fix that i applied today made me reduce the worksize from 0x80000 to 0x8000, which will introduce a HUUUUGE latency in faster cards. I'm working on a solution for this just about now.

Ok, NEW VERSION OF GPU MINER RELEASED! Fixed the "0x8000" worksize, so the speed drops might stop for now, and should be a little bit faster!

Linux and Mac OSX binaries also available! (Windows, of course, still available).

Download link: https://www.dropbox.com/sh/2wv2awwgebpdo0m/STzOU5tlXa

source code: https://github.com/girino/xptMiner

Hope you enjoy!

well, i left this open for quite a while now. The gpu is already initialized, and now it says "connected to server using x.pushtrough xpt protocol". But it reports no activity, it's frozen there. Is this supposed to take that long too ? thanks and sorry for the insistance, i just want to know if i am doing sth wrong. 

Now this happens when the server is unreachable (it says connected, but is actually connecting). Are you behind a firewall???

[gigawatt]

Looks like there error message for the "-f" parameter accidentally calls it "-d".

The OpenCL code looks based on the SPH implementation.  Is that the case?

sorry, i changed -d to -f to use -d for "device", but forgot the error.

About the code, it is a "pruned" SPH  code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation.

Ha!  I ran into that as well!
Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks.  I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results.

[girino]

Looks like there error message for the "-f" parameter accidentally calls it "-d".

The OpenCL code looks based on the SPH implementation.  Is that the case?

sorry, i changed -d to -f to use -d for "device", but forgot the error.

About the code, it is a "pruned" SPH  code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation.

Ha!  I ran into that as well!
Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks.  I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results.

Well, the previous submissions to sha3 are also public. Do you think they'll work? What about "metis" hash? is it really "fugue" or has the dev for metiscoin made something new?

[girino]

Looks like there error message for the "-f" parameter accidentally calls it "-d".

The OpenCL code looks based on the SPH implementation.  Is that the case?

sorry, i changed -d to -f to use -d for "device", but forgot the error.

About the code, it is a "pruned" SPH  code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation.

Ha!  I ran into that as well!
Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks.  I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results.

BTW, before releasing the GPU miner I was thinking to port back my optimizations to the CPU version, do you think it's still worth it? My code was so slow on my GPU that i thought CPU mining would still be possible. What do you think?

[NM92]

The quick fix that i applied today made me reduce the worksize from 0x80000 to 0x8000, which will introduce a HUUUUGE latency in faster cards. I'm working on a solution for this just about now.

Ok, NEW VERSION OF GPU MINER RELEASED! Fixed the "0x8000" worksize, so the speed drops might stop for now, and should be a little bit faster!

Linux and Mac OSX binaries also available! (Windows, of course, still available).

Download link: https://www.dropbox.com/sh/2wv2awwgebpdo0m/STzOU5tlXa

source code: https://github.com/girino/xptMiner

Hope you enjoy!

well, i left this open for quite a while now. The gpu is already initialized, and now it says "connected to server using x.pushtrough xpt protocol". But it reports no activity, it's frozen there. Is this supposed to take that long too ? thanks and sorry for the insistance, i just want to know if i am doing sth wrong. 

Now this happens when the server is unreachable (it says connected, but is actually connecting). Are you behind a firewall???

I have the default windows firewall, already created an exception for the miner, but nothing yet 

[girino]

well, i left this open for quite a while now. The gpu is already initialized, and now it says "connected to server using x.pushtrough xpt protocol". But it reports no activity, it's frozen there. Is this supposed to take that long too ? thanks and sorry for the insistance, i just want to know if i am doing sth wrong. 

Now this happens when the server is unreachable (it says connected, but is actually connecting). Are you behind a firewall???

I have the default windows firewall, already created an exception for the miner, but nothing yet 

Are you running with the default "example.bat"? If so, just remove the "-o localhost" option, since it is trying to connect to your own machine and not a pool. Sorry for that, I use an SSH tunnel to connect to the pool behind my firewalls and this config "leaked" into the example.bat.

[gigawatt]

Looks like there error message for the "-f" parameter accidentally calls it "-d".

The OpenCL code looks based on the SPH implementation.  Is that the case?

sorry, i changed -d to -f to use -d for "device", but forgot the error.

About the code, it is a "pruned" SPH  code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation.

Ha!  I ran into that as well!
Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks.  I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results.

BTW, before releasing the GPU miner I was thinking to port back my optimizations to the CPU version, do you think it's still worth it? My code was so slow on my GPU that i thought CPU mining would still be possible. What do you think?

I think it'd totally be worth it from a development point of view.  I'll make optimizing the code way easier, especially considering the "debugging" tools for OpenCL.
I actually pushed a few new optimizations to my CPU miner fork today.  Feel free to check them out: https://github.com/llamasoft/xptminer-linux/commits/master

Also, as far as the metis/fugue thing goes, I'm almost 100% certain they're the same.  The original source even calls it "fugue" in the comments.

I'll drop you a message sometime tomorrow.  I've got some optimizations I want to test out with the GPU code that I'll share with you.

[antonio8]

@ girino

Using GTX 670 was getting about 835 kH/s but it brought my system to a crawl. I had to stop it for now but will run it when I leave for work.

Good job on it.

EDIT: Works fine for the GTX670 but it is stuck at "Initializing Device: Oland" for my R7 250 (I know it aint worth much to mine, but I have all the other cards somewhere else). Just get a flashing cursor.

[FreePls]

Would be nice if someone would team up with the dev and bring this coin a bit forward, the dev seems to be very quiet

[phm]

@ girino

Using GTX 670 was getting about 835 kH/s but it brought my system to a crawl. I had to stop it for now but will run it when I leave for work.

Good job on it.

EDIT: Works fine for the GTX670 but it is stuck at "Initializing Device: Oland" for my R7 250 (I know it aint worth much to mine, but I have all the other cards somewhere else). Just get a flashing cursor.

Ouch, that's poor. My GPU miner does 125 MH/s on 4 x R9 290 rig. On NVIDIA cards it's much slower but still managed to get about 6 MH/s on Amazon GPU g2.2xlarge instance.

[Sy]

the GPU miner doesnt build on my smos rig...where do i get the opencl.h file?

In file included from xptMiner/main.cpp:3:
xptMiner/OpenCLObjects.h:21:23: error: CL/opencl.h: No such file or directory

Update:
Nevermind, fixed it by adding -I/opt/AMD-APP-SDK-v2.4-lnx32/include/CL/ to the makefile

[antonio8]

@ girino

Using GTX 670 was getting about 835 kH/s but it brought my system to a crawl. I had to stop it for now but will run it when I leave for work.

Good job on it.

EDIT: Works fine for the GTX670 but it is stuck at "Initializing Device: Oland" for my R7 250 (I know it aint worth much to mine, but I have all the other cards somewhere else). Just get a flashing cursor.

Ouch, that's poor. My GPU miner does 125 MH/s on 4 x R9 290 rig. On NVIDIA cards it's much slower but still managed to get about 6 MH/s on Amazon GPU g2.2xlarge instance.

I'll take anything extra right now.

If I use my R9 280X it gets 3,275 kH/s but I am using all my cards for something else right now. Just wanted to test this out for now.

[kaene]

Would be nice if someone would team up with the dev and bring this coin a bit forward, the dev seems to be very quiet

Working on it

[stevenlam]

Would be nice if someone would team up with the dev and bring this coin a bit forward, the dev seems to be very quiet

Working on it

+1

[microk]

Hi.
That can not work on my R4870s.
Does it need the card support the OpenCl 1.1?

[antonio8]

@ girino

Ran it overnight but when I woke up my kh/s went down by a lot. Not sure if it is just an error on reporting because it looks like my shares stayed ok.

R9 280X 3,280 kh/s woke up 245 kh/s
7850 1,400 kh/s woke up 169 kh/s
7850 1,600 kh/s woke up 270 kh/s

[Chida]

GPU miner came out. Increase costs, so the need for the miners to convert as soon as possible in bitcoin and relative decline in the value

[bsunau7]

@ girino

Ran it overnight but when I woke up my kh/s went down by a lot. Not sure if it is just an error on reporting because it looks like my shares stayed ok.

R9 280X 3,280 kh/s woke up 245 kh/s
7850 1,400 kh/s woke up 169 kh/s
7850 1,600 kh/s woke up 270 kh/s

Looks like a counter wrap, the shares/h on ypool stayed constant for me..

[girino]

@ girino

Ran it overnight but when I woke up my kh/s went down by a lot. Not sure if it is just an error on reporting because it looks like my shares stayed ok.

R9 280X 3,280 kh/s woke up 245 kh/s
7850 1,400 kh/s woke up 169 kh/s
7850 1,600 kh/s woke up 270 kh/s

it seems to be a reporting error, several people are complaining, the share rates don't go down, but hashes do. I will look into it.

[girino]

@ girino

Ran it overnight but when I woke up my kh/s went down by a lot. Not sure if it is just an error on reporting because it looks like my shares stayed ok.

R9 280X 3,280 kh/s woke up 245 kh/s
7850 1,400 kh/s woke up 169 kh/s
7850 1,600 kh/s woke up 270 kh/s

it seems to be a reporting error, several people are complaining, the share rates don't go down, but hashes do. I will look into it.

Just did my math. The hash counter is a uin32. At 1.4 GH/s it will cycle in 50 minutes Changing it to uint64 will get me some 400 thousand years or so at this speed. I'll do it for the next release.