Awesome, keep the updates coming. I noticed that you can include the CPU in the list of devices to be used with your miner, is this efficient?
Not at all. It will use opencl on the CPU, and you will get at most half the hash rate you get with a decent CPU miner. |
|
|
|
Using an r9 280x, I'm getting around 8631 kh/s . I have to say that although the gpu usage is 99% it doesn't seems to stress the gpu as much as dogecoin mining for example. The card stays at a cool 62c using a fan speed of 42% (Sapphire).
Dogecoin is scrypt based which uses a good bit more resources than these hash algorithms. Scrypt is about as intense you can get while still being able to run on a GPU. Sadly the performance does drop to 100 after 30mins. Any one else have that issue? It's a known issue. You're still hashing at full speed but the hash meter overflowed back to zero. A fix is in the pipeline. Alright thanks, I thought it might be a visual bug especially after looking at my stats on ypool. This bug is now fixed. Build 5 is released fixing this and other small bugs. Edit: Forgot the usual download links: Binaries link: https://www.dropbox.com/sh/2wv2awwgebpdo0m/STzOU5tlXaSource code: https://github.com/girino/xptMiner |
|
|
|
Any idea why the miner seems to just stop finding shares after a while? I noticed the kh/s going down over time but it was still finding shares pretty quickly, but this morning it was reporting 0 kh/s and not finding shares. Win 7, R9 290 if that helps.
never heard of it stopping finding shares. isn't it a network problem or something? maybe the pool was down. about the speed, the original xptminer from ypool used a 32 bit counter for hashes, but it overflows quite quickly with gpu hashing speed (30 minutes to 1 hour, depending on the gpu). so reported speeds after the first half an hour or so are just bogus. I'll release a fix for that later today. (code is already fixed, but i didn't create the binaries yet). Found this bug, it is fixed in Build 5! |
|
|
|
NEW RELEASEBuild 5, fixes the following bugs: - bogus hash count after half on hour or so in fast GPUs. Now it report the right hashrate for several years. - Not reconnecting after disconnection. Now it waits 45 secs after every disconnect and tries again. New Features: - counts invalid and valid shares separately, so it is easier to spot problems. Todo: - several AMD optimizations are on the pipeline, but they were not yet mature (too many invalid shares) so they were NOT included in this version. Download binaries and source from the same old place. OSX binaries not ready yet, only linux and Windows available. Binaries link: https://www.dropbox.com/sh/2wv2awwgebpdo0m/STzOU5tlXaSource code: https://github.com/girino/xptMinerThanks, and enjoy the new version.
|
|
|
|
Well now that I actually helped someone for a change I would like to give some feedback to the developer. Currently if/when the miner lose connection with the pool there are never any attempts to connect back again, it would be awesome to have a reconnect feature so we donīt lose any hash time. I know I'm a lazy bastard asking you to implement this rather than doing it myself but it is probably a quick matter for someone familiar with the code  Also, thanks a lot for your efforts with this miner. This is quite strange since i didn't mess with the networking code from ypool, but you're not the first to point it out. I'll look into this today (the 32 bit counter is already fixed in the code and in the linux and mac binaries, just the windows binaries still have the bug). Thanks for the support. |
|
|
|
Any idea why the miner seems to just stop finding shares after a while? I noticed the kh/s going down over time but it was still finding shares pretty quickly, but this morning it was reporting 0 kh/s and not finding shares. Win 7, R9 290 if that helps.
never heard of it stopping finding shares. isn't it a network problem or something? maybe the pool was down. about the speed, the original xptminer from ypool used a 32 bit counter for hashes, but it overflows quite quickly with gpu hashing speed (30 minutes to 1 hour, depending on the gpu). so reported speeds after the first half an hour or so are just bogus. I'll release a fix for that later today. (code is already fixed, but i didn't create the binaries yet). |
|
|
|
Similar error, this time in function keccak Initializing GPU...
Initing device 0.
Initializing GPU 1
Initializing Device: Iris Pro
ERROR: -11, CL_BUILD_PROGRAM_FAILURE, if there is a failure to build the program executable. This error will be returned if clBuildProgram does not return until the build has completed.
--- Build log ---
Cannot select: 0x7fedae15bc10: i64 = rotl 0x7fedae19d010, 0x7fedae0dae10 [ID=723]
0x7fedae19d010: i64,ch = load 0x7fedae1a9510, 0x7fedae18ff10, 0x7fedae1b6510<LD8[%sunkaddr301]> [ORD=1529] [ID=722]
0x7fedae18ff10: i64 = add 0x7fedae1b8e10, 0x7fedae0de510 [ORD=1236] [ID=183]
0x7fedae1b8e10: i64 = FrameIndex<0> [ORD=1190] [ID=1]
0x7fedae0de510: i64 = bitcast 0x7fedae106710 [ID=154]
0x7fedae106710: v2i32 = IGILISD::MOVSWZ 0x7fedae12d210, 0x7fedae0df310, 0x7fedae0df310, 0x7fedae0df310 [ID=103]
0x7fedae12d210: i32 = Constant<352> [ID=52]
0x7fedae0df310: i32 = Constant<0> [ID=11]
0x7fedae0df310: i32 = Constant<0> [ID=11]
0x7fedae0df310: i32 = Constant<0> [ID=11]
0x7fedae1b6510: i64 = undef [ORD=1193] [ID=2]
0x7fedae0dae10: i64 = bitcast 0x7fedae0a4610 [ID=115]
0x7fedae0a4610: v2i32 = IGILISD::MOVSWZ 0x7fedae1e9b10, 0x7fedae0df310, 0x7fedae0df310, 0x7fedae0df310 [ID=63]
0x7fedae1e9b10: i32 = Constant<14> [ID=10]
0x7fedae0df310: i32 = Constant<0> [ID=11]
0x7fedae0df310: i32 = Constant<0> [ID=11]
0x7fedae0df310: i32 = Constant<0> [ID=11]
In function: keccak
--- End log ---
Assertion failed: (!error), function loadProgramFromStrings, file xptMiner/OpenCLObjects.cpp, line 316.
Abort trap: 6 it was never tested on intel gpus before. looks like it does not like my rotl imploementation.i'll look into it. |
|
|
|
Got it built but: Initializing GPU...
Initing device 0.
Initializing GPU 1
Initializing Device: Iris Pro
ERROR: -11, CL_BUILD_PROGRAM_FAILURE, if there is a failure to build the program executable. This error will be returned if clBuildProgram does not return until the build has completed.
--- Build log ---
Cannot select: 0x7fa41209b810: i64 = rotl 0x7fa415092810, 0x7fa41224ee10 [ID=723]
0x7fa415092810: i64,ch = load 0x7fa4150a0d10, 0x7fa415085710, 0x7fa4150add10<LD8[%sunkaddr282]> [ORD=1529] [ID=722]
0x7fa415085710: i64 = add 0x7fa4150af610, 0x7fa412251510 [ORD=1236] [ID=183]
0x7fa4150af610: i64 = FrameIndex<0> [ORD=1190] [ID=1]
0x7fa412251510: i64 = bitcast 0x7fa412045510 [ID=154]
0x7fa412045510: v2i32 = IGILISD::MOVSWZ 0x7fa4130ef610, 0x7fa412037710, 0x7fa412037710, 0x7fa412037710 [ID=103]
0x7fa4130ef610: i32 = Constant<352> [ID=52]
0x7fa412037710: i32 = Constant<0> [ID=11]
0x7fa412037710: i32 = Constant<0> [ID=11]
0x7fa412037710: i32 = Constant<0> [ID=11]
0x7fa4150add10: i64 = undef [ORD=1193] [ID=2]
0x7fa41224ee10: i64 = bitcast 0x7fa412018610 [ID=115]
0x7fa412018610: v2i32 = IGILISD::MOVSWZ 0x7fa4130bbd10, 0x7fa412037710, 0x7fa412037710, 0x7fa412037710 [ID=63]
0x7fa4130bbd10: i32 = Constant<14> [ID=10]
0x7fa412037710: i32 = Constant<0> [ID=11]
0x7fa412037710: i32 = Constant<0> [ID=11]
0x7fa412037710: i32 = Constant<0> [ID=11]
In function: keccak_update_g
--- End log ---
Assertion failed: (!error), function loadProgramFromStrings, file xptMiner/OpenCLObjects.cpp, line 316.
Abort trap: 6  WOW! Never seen that before! What GPU do you have? (this function, keccak_update_g, is not even used, it is a test function! Maybe you cane edit opencl/keccak.cl and remove it...) |
|
|
|
OSX binary not there. Just the sources.
Sorry for that. Fixed |
|
|
|
Using an r9 280x, I'm getting around 8631 kh/s . I have to say that although the gpu usage is 99% it doesn't seems to stress the gpu as much as dogecoin mining for example. The card stays at a cool 62c using a fan speed of 42% (Sapphire).
The scrypt miners are WAY more optimized to use all GPU resources. This is a very first version that has LOTS of room for improvement (for example, use proprietary AMD instruction set when it applies, and use vector variables). Oh, and most scrypt miners force overclock, while this miner does not (you need to overclock your GPU manually if you want to increase speed). |
|
|
|
Using an r9 280x, I'm getting around 8631 kh/s . I have to say that although the gpu usage is 99% it doesn't seems to stress the gpu as much as dogecoin mining for example. The card stays at a cool 62c using a fan speed of 42% (Sapphire).
The scrypt miners are WAY more optimized to use all GPU resources. This is a very first version that has LOTS of room for improvement (for example, use proprietary AMD instruction set when it applies, and use vector variables). |
|
|
|
@ 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. |
|
|
|
@ 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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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? |
|
|
|
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/STzOU5tlXasource code: https://github.com/girino/xptMinerHope 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??? |
|
|
|
code is opensource, so if you want, you can check the code and compile it yourself. Impossible to be safer  |
|
|
|
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/STzOU5tlXasource code: https://github.com/girino/xptMinerHope you enjoy! |
|
|
|
|
Show Posts
