SP - is myr-gr and dmd-gr similar output?
-pokeytex
no: myr-gr = groestl + sha, dmd-gr = greostl + groestl. myr-gr should be about twice as fast as dmd-gr.
|
|
|
I tried to mine DGB with cgminer, algo was skein, two 280x and one 280, but my gpu usage stayed at 64% for all three gpus, cpu usage 100%! low end cpu e7400 with 6 GB ram windows 7 64 driver 15.7 any idea about this problem?
did you set GPU_USE_SYNC_OBJECTS=1?
|
|
|
selling only. where is buying ? it's very bad for coin. dead ?
the questions is: who is mining? if nobody mines, the it is dead. someone is mining indeed, look at the diffs...
|
|
|
Thanks sp! 47 Mh/s on 970 is very good. As a comparison, my opencl kernel for amd does 63 on 290x (the recently released opensource one by another guy does 50).
|
|
|
I see you got the speed bump by applying a couple of tricks from my groestlcoin/diamond opensource kernel (use of rotated T0 for putting into local ram, different byte-extract code), but this is a different beast because of the additional SHA round. Only part of that knowledge can be applied succesfully in this case. By breaking compatibility with stock miner you've got a lot more room for optimisation. Beware of that byte-extract code, though: it works fine on some driver versions only.
EDIT: and the local ram initialisation only works at worksize 256, which is usually not optimal.
|
|
|
I assume there is a russian forum where this coin chat takes place. Can someone relay the most important news here, please?
|
|
|
Hello! I've tried solo-mining saffron with groestl algo (myriad-groestl), but all blocks are rejected! Why?
|
|
|
Nice work!
Still my private myr-groestl kernel is faster: 35 Mh/s on 280x and 63 Mh/s on 290x ;-) I think the 280x version can be improved further.
|
|
|
Selling 100,000 TTY @100 SAT = 0.1 BTC
|
|
|
yea i know, but is it a lot of work? or just simply switching one parameter in code? No... Why would sp and others write Maxwell only code if we could easily swith 3.0 compatibility without hashrate loss?
|
|
|
Thx for your awesome work! what do i need in order to compile in with compute 3 and 3.5 support? You need to make the code compatible with compute 3 and 3.5 :-) This fork is for compute >= 5. Try tpruvot one.
|
|
|
I'm interested in knowing this coin better: what are the main differences between trinity and other multi-algo pow coins like digibyte and myriad?
|
|
|
I had a look at cgminer_skein and I think it's pretty good, as usual with reorder's releases. A good gpu coder might squeeze a bit more hashrate, but don't expect 2x or more like in other algos (hint: myr-groestl... pm me if interested).
|
|
|
does anyone have any working nodes for the coin - cryptopia doesn't even have any working nodes.
look back some posts, there are working addnodes (at least they worked for me).
|
|
|
Nothing new in the groestl+groestl area, but I've worked a bit on the groestl+sha variant (myr-groestl for myriad, digibyte, saffron, etc.). Tahiti is a mess, but I could easily push hawaii over 60 Mh/s, keeping the kernel compatible with the old miners.
I could finally get rid of scratch registers on Tahiti: now the 280x is doing 35 Mh/s with moderate overclock :-)
|
|
|
Just wanted to say I'm following this coin :-) Looking forward to the working exchange.
|
|
|
I was experiencing same kind of issue when I was making Axiom CUDA algo. Having 980 Ti, which packs 6 gig of memory, whenever I set algo to use more than about 2,5 gigs, there was a massive slow down, bus interface load jumped up, TDP jumped down. Since 980 Ti is my primary GPU, it constantly has mem load of about 400 mega even in idle time - and that would explain that actual mem cutoff is at around 2.1 gigs - same as other v2 maxwell cards.
I don't have account there to post, but measure bus interface load during these bottlenecks - maybe it can reveal another hint getting down (I used GPUZ for measuring bus interface load).
Bus interface load is - to my knowledge - how much PCIE bus gets loaded with data. And my algorithm implementation was sending very very little data over this bus - not something to load PCIE 3.0 16x so massively that it would show 30-50% of load. I could not explain, why bus load was so high, googling gave no results and I kinda gave up. But now that you revealed this slow down happening with other algorithms, other cards, I have my suspicion that these problems are related. My first idea would be; what if CUDA is automatically syncing GPU and CPU memory - as if some part of GPU memory was set to be in sync with CPU memory - this would explain massive bus load, as my algo was causing a lot of changes in this massive allocated buffer. I believe, CUDA even has a name for this - Unified memory. And to my knowledge, it is only active when you explicitly set so. What if it is active even in cases when you do not explicitly set so? Or maybe a bug in CUDA software - sending data over bus even though there is no need for synced memory space?
you could easily test it by running the same thing on the same card but thru a 1x raiser.
|
|
|
Is anyone else having issues with random closes while mining quark with the latest .70? I have 2 different gtx 970 rigs, windows 10. Both computers will crash within the hour mining at completely stock clocks. Can someone post a quark bat file so I can see how yours are setup.
TYIA.
I have the same random crashes on 1 of 2 machines. Both running windows7x64. The loop works as a workaround... same happens to me on linux, so I assume it's a ccminer quark specific issue.
|
|
|
so now that DGB is doin so well i have been trying to mine it with my 290x cards but cant seem to find a sgminer that works with skein for some reason the windows 5.1.1 from cryptomining-blog just reverts to ckolivas any time i start it the old cgminers still work but kinda wanna experiment and see if sgminer will run a bit better
this is what im running in my conf:
"intensity" : "11", "worksize" : "128", "kernel" : "skein", "lookup-gap" : "2", "gpu-threads" : "2", "shaders" : "2812", "thread-concurrency" : "8192", "gpu-platform" : "0", "device" : "0"
maybe its just a settings issue?
"skein" is not a kernel in sgminer, it's just the base algo to be included in a kernel. I don't think there is any sgminer for myriad-skein, but I may be wrong ;-) You are wrong mate here you are cryptomining-blog.com/wp-content/download/ cgminer-skein-windows.zip sgminer != cgminer
|
|
|
so now that DGB is doin so well i have been trying to mine it with my 290x cards but cant seem to find a sgminer that works with skein for some reason the windows 5.1.1 from cryptomining-blog just reverts to ckolivas any time i start it the old cgminers still work but kinda wanna experiment and see if sgminer will run a bit better
this is what im running in my conf:
"intensity" : "11", "worksize" : "128", "kernel" : "skein", "lookup-gap" : "2", "gpu-threads" : "2", "shaders" : "2812", "thread-concurrency" : "8192", "gpu-platform" : "0", "device" : "0"
maybe its just a settings issue?
"skein" is not a kernel in sgminer, it's just the base algo to be included in a kernel. I don't think there is any sgminer for myriad-skein, but I may be wrong ;-)
|
|
|
|