I know I'm late but I have a little btc amount that I've requested cashout for: it's pending for two days now.
Please let it go :-)
So they are gone. I wonder why you didn't post here that you were shutting down and taking our coins. How could I now? |
|
|
|
I already compiled the arm binary. You can find it, along with building instructions, if you search this thread.
Found the ARM building instructions - they really do look similar to what I did, so I'm glad I didn't take a path that was totally ludicrous. For people that might be looking at this down the line, pallas' Diamond wallet ARM build instructions and headless binary are linked in his post here: https://bitcointalk.org/index.php?topic=580725.msg8380165#msg8380165 ! It even has a nifty donation address for his work. Is there any chance you know the reason your additions (and the boost scopes that I missed, though it looks like the file just uses the namespace, so maybe they're no longer necessary?) haven't been picked up in the official repo? It didn't look like danbi was being too responsive on the matter and I got tired of flipping through the thread to look for the conversation really quickly (and just looked through your past posts to find your instructions/build). Also, do you have a Git/SVN/Mercurial/whatever repo that you maintain for your builds? If you do, I'm going to delete my fork and follow yours, even if it's not linked to the DMDcoin GitHub. And, finally, sorry for stepping on your toes if you were affronted. EDIT: clarification of boost scope/namespace usage No problem! :-) I do not plan to keep the arm build updated as I'm not using it any longer and there is no interest in it. I don't know why danbi didn't want to apply my modifications to the main tree, maybe he didn't want to risk modifying a stable source for very few users... |
|
|
|
Hi, everyone, Just announcing that I compiled some armv7 builds of the wallet/headless binaries since I couldn't find any (though I did discover that the Diamond-Coin-2.0 repo has essentially the same edits, but is not merged with the production wallet for some reason). If you're interested in an armv7 wallet (for many arm devboards and set top boxes, basically), you can download my prebuilt binaries here: http://starflakenights.net/crypto/wallets.html#dmd . (Diffs from the official repo are linked in my brief write-up.) If you'd like to take a look at the source I used, it's located here: https://github.com/feldenthorne/Diamond . The binaries on my site will be updated periodically/as-necessary. I hope someone else on here finds them useful! EDIT: I forgot to mention that this build uses libdb5.1, which is *allegedly* used in the official builds, as per the Readme, but the unix makefile readme suggests that they use libdb4.8. So blockchain databases that have been opened or generated with these prebuilts might not work with official clients. But they should. I already compiled the arm binary. You can find it, along with building instructions, if you search this thread. |
|
|
|
LOL, If all those other guys with the ASICS join in, it will be several billion credits per day. Kinda ridiculous. BU should just decrease the amount of credits they give, it is too disproportionate to other projects. I agree. BU makes the cross-projects credit statistics pointless Go to free dc. You can exclude BU from stats if that makes you happy. Funny joke! 😂 |
|
|
|
LOL, If all those other guys with the ASICS join in, it will be several billion credits per day. Kinda ridiculous. BU should just decrease the amount of credits they give, it is too disproportionate to other projects. I agree. BU makes the cross-projects credit statistics pointless |
|
|
|
Any news on this? I would donate for a working 280x kernel.
The 280x kernel is working fine but the hasrate is about the same of the stock kernel (1/1.1 Mh/s). I'm working on it, though. |
|
|
|
|
At least 8 KB of memory are needed for groestl. Not using global ram doesn't equal register only. In my case I'm using part local ram and part memory cache. Same for hetpas.
With bitslice you can reduce memory usage further but not completely.
Still asic can be done if enough volume, which is not the case with DMD IMHO. And with the other coins of the same algo which are dead or almost dead it's even more so.
|
|
|
|
|
Is there still interest in this? Utahjohn and.... :-D
I could dedicate some time to finish the opensource kernel v2 if it's worth.
|
|
|
|
|
Myr-groestl is about 1.5x faster than groestlcoin.
Since the 290x can go up to 35 mh/s in groestlcoin, I believe it should reach at least 50 mh/s in myr-groestl.
That's using the asm kernel or the latest, unfinished opencl (Hawaii only) kernel.
|
|
|
|
|
I'm having crash problems on 14.12 with 280x as well.
But only with the optimized lyra kernel and my miner, not with djm34's, that's pretty weird!
|
|
|
|
I created the italian language thread but, apart from some flame because "I'm not an usual italian forum writer", there was no interest at all...
Let's hope Russians and Chineses are different.
i guess regulary translate announcement and news to that thread would make u a "usual italian forum writer" but i understand that would be time consuming task but maybe u get in touch with interesting italian speaking people True, but I'm used to turn to "english mode" once I power on the PC, since I was a kid ;-) Sometimes I find it difficult to even write a good post in italian, even though I'm mother tongue, because I don't know the italian translation of many technical terms. I believe we would save a lot of resources if everybody would concentrate on learning a bit of english instead of translating programs, documentation, etc. but that's another story ;-) |
|
|
|
we have some people working to create a russian language DMD community up and running
it would be nice if we get such a language community going for chinese language too
is there anybody in community who can write mainland chinese
(Mainland China adopted simplified Chinese characters in 1956. They are also used in Singapore. Traditional Chinese characters are used in Hong Kong, Macau and Taiwan.)
or who know people who can and are maybe interested start and maintain a dmd chinese community?
Been to all of these countries while I was in US Navy but did not learn any language, would be nice to become a larger worldwide community  Gotta keep it english speaking in main thread but other threads are welcome with a moderator to translate if needed to cross-post to this thread. I created the italian language thread but, apart from some flame because "I'm not an usual italian forum writer", there was no interest at all... Let's hope Russians and Chineses are different. |
|
|
|
|
Just wanted to let you all know I've not stopped developing: I've been fighting with driver issues for some days (on the rig with 280x cards), on the quest to optimize the kernel for the Tahiti chipset.
|
|
|
|
silence in a way like what is he talking about?
research bitcoin 2.0 and evertime u hear bitcoin replace it in ur mind with diamond............
happy researching
hehe I'm sure many people understand, I guess they just wait to know more about the project ;-) |
|
|
|
I just tried with 835/1500 and 1000/1500, with the public kernel.. Compiled on 14.6. 835/1500: 1070khs 1000/1500: 1080khs Edit: Tahiti bin for others to try.. Download linkThen there obviously is some problem with my kernel, Tahiti and the original djm34 miner. I've just tried running my modified lyra2re miner on the Tahiti cards and it runs at the same speed as you are reporting. Thus it looks like my optimizations are not effective on Tahiti as they are on Hawai. That's bad but partly expected. It's not the end of the story, though, because I've used 14.9 to compile for tahiti which is worse then both 14.6/7 and 14.12 for mining. I will try with another driver later. I had a better look and it already is a bit faster: 1086 at 835/1500 (with my miner) Will look into making it faster in the coming days. |
|
|
|
Tahiti 64 bit bin working fine, hashing 1012 Kh/s at 835 core and 1500 mem, or 1018 at 1000 core.
This is without specific optimizations for the tahiti chip compared to hawaii and with the standard djm34 miner (not my own).
Will update the OP soon.
Whoever donated and wants the tahiti bin just ask me.
Hmm.. I have 1140Kh/s with the original public Lyra2RE kernel.. This is with 280x running at 1130/1570, though. Or is there some "hashrate halving" happened again, I haven't been following too closely. I didn't try a clock so high yet, the cards aren't mine so I must be careful :-) It must be tuned for Tahitii and I must try it with my miner which will probably provide another little boost. People are reporting much different hashrates for the same cards. It depends on driver version (for the standard kernel), but also on memory latency (for both kernels). I believe cards with Hynix ram have at least 8% advantage over Elpida ones. I don't know which type of ram the 280x I'm using do have. I just tried with 835/1500 and 1000/1500, with the public kernel.. Compiled on 14.6. 835/1500: 1070khs 1000/1500: 1080khs Edit: Tahiti bin for others to try.. Download linkThen there obviously is some problem with my kernel, Tahiti and the original djm34 miner. I've just tried running my modified lyra2re miner on the Tahiti cards and it runs at the same speed as you are reporting. Thus it looks like my optimizations are not effective on Tahiti as they are on Hawai. That's bad but partly expected. It's not the end of the story, though, because I've used 14.9 to compile for tahiti which is worse then both 14.6/7 and 14.12 for mining. I will try with another driver later. |
|
|
|
|
Additional information on comparing my kernel with standard djm34 one:
It looks like tweaking of the two kernels is very different; djm34's seem to like high core and mem clocks (like 1050/1625) while mine prefers "sweet spots" like 1000/1500 and 835/1500.
So you may end up with similar numbers on djm34 if you have the right driver to compile it. But it will consume more power and need better cooling.
I believe this is because the bottleneck is the memory and, even if you can optimize the code like I did, you are still limited (mostly) by the memory latency.
|
|
|
|
Tahiti 64 bit bin working fine, hashing 1012 Kh/s at 835 core and 1500 mem, or 1018 at 1000 core.
This is without specific optimizations for the tahiti chip compared to hawaii and with the standard djm34 miner (not my own).
Will update the OP soon.
Whoever donated and wants the tahiti bin just ask me.
Hmm.. I have 1140Kh/s with the original public Lyra2RE kernel.. This is with 280x running at 1130/1570, though. Or is there some "hashrate halving" happened again, I haven't been following too closely. I didn't try a clock so high yet, the cards aren't mine so I must be careful :-) It must be tuned for Tahitii and I must try it with my miner which will probably provide another little boost. People are reporting much different hashrates for the same cards. It depends on driver version (for the standard kernel), but also on memory latency (for both kernels). I believe cards with Hynix ram have at least 8% advantage over Elpida ones. I don't know which type of ram the 280x I'm using do have. |
|
|
|
|
Tahiti 64 bit bin working fine, hashing 1012 Kh/s at 835 core and 1500 mem, or 1018 at 1000 core.
This is without specific optimizations for the tahiti chip compared to hawaii and with the standard djm34 miner (not my own).
Will update the OP soon.
Whoever donated and wants the tahiti bin just ask me.
|
|
|
|
Sweet. Been fallowing.. any progress on acquiring a TAHITI card to optimize?
I've received an offer to use a remote rig (with 280x cards) to test the kernel. Thanks to that user I will not need to buy the card. Let's hope I can work it that way. Will keep posted. |
|
|
|
|
Show Posts
