Topic: Genesis Mining Presents: SGMiner-GM - now with Zawawa's GG! [Updated 17/01/2017] - page 25. (Read 140412 times)

Of course!

Would you be willing to accept pull requests to the repo from someone not in the group? I like the open source approach

Oh no, honey, you weren't a dick. Don't think that.

I'll do my very, very best to ensure we have monthly updates at the minimum.

I just want the community to understand that it is being worked on, actively. At least twelve hours a day on my end. It just takes time, because in addition to this, I have technical writing + pro bono stuff. Would it help if, maybe, I kept a sort of diary/journal showing what we accomplished for the day with SGMiner-GM?


Thank you so much, scryptr. Your words always inspire us to keep going.

I'm going to work on updating ZEC to SA v5. In addition to that, I've been closely following zawawa and nerdralph's optimizations + ideas. I'm working to implement those.


Hm.

I want to imagine you're a junior copyeditor, and your boss slaps a giant textbook of notes. It was penned in medical shorthand - doctor chickenscratch.

You're going to have to take that textbook and translate it into plain English. Difficult, right?

On top of that, you have a bunch of new notes from another doctor - this one Scottish - that you also need to weave into the textbook. Lots of 'wae', 'nae', 'tae' and 'shite' (though that one's easy to figure out). It's still in chickenscratch, but you don't have many Scottish friends, so it takes you a while to decipher the sentence. Even worse, this doctor has really awful handwriting! Some of it just looks like poorly drawn waves to you.

Your boss keeps adding notes from other doctors - all different ethnicities and backgrounds, all different writing styles.

Starting to get the big picture?

Now, let's get a little more technical:

Programmers will now how annoying it is to maintain another coder's work. Especially if it's not properly commented. Well, sgminer-gm (and other versions) aren't. Commit messages didn't follow a proper convention (subject explains WHAT changed, body explains WHY); huge blocks of code have no comment, so you need to figure out what's going on; documentation was not updated; there are old dependencies; there are a few faults, and that happens when having a large, open source project.

Some kernels have unique ways of handling, for example, Stratum: let's look at cryptonight (Monero). There's a custom function in util.c (built by previous sgminer developers) called json_array_string() which makes a strdup() of the actual string buffer returned by jansson. Usually, we free() all those buffers. Well, cryptonight, for example, doesn't do that - it doesn't return an array, so we have to pull the string values straight out of jansson, rather than using the custom sgminer function.

Starting to see the difficulty? It takes a lot of analyzing HOW a kernel works, then looking at HOW you can think of putting this into SGMiner-GM in a way that won't break anything else. And believe me, breaking happens. Oh, and bugs. So many bugs. And then you have to test, test, test. On both Linux, and Windows. And testing a mining program isn't as simple as just running it, waiting a few moments, then calling it a good day; you need to let it treat it like you would a hardware stress test for stability.

Let's look at scanhash_opencl. This should not have any algorithm dependent code - but it does. A function pointer (that points to different kernel dispatch functions) needs to step out and dish out stuff, based on the algorithm. And the goto statements need to be removed. But there are a lot of them. A lot.

It's not as simple as just plugging in a line of code, either. So many files need to be changed. I want drag and drop kernel support, I really do, but...that won't happen. With SGMiner-GM, at least. Folks have probably snooped and found out what we're planning, but, that's a post for another time and potentially another place.

I am really sorry for being a dick. I understand. I code myself mainly on genetic pipelines and it takes ages for making a pipeline of data such that other people can easily understand and use it. So plain and simple sorry

But I believe in competition. SGminer is probably the most versatile windows based GPU miner I have seen. I would like to see better softwares pushing limits on each front. So no hard feelings. Please accept my humble apologies

Great , thanks for this - getting around 100 sol/s with rx470 4gb

THE LINUX BINARIES RUN WELL AND MINE ZCASH--

But the mining  algorithm for Zcash (ZEC) needs to be updated and optimized.  The algorithm mines at about 1/2 the speed of Optiminer and Claymore's ZEC mining engines.  BUT, I am sure that Wolf0 and OhGodAGirl can bring SGminer-GM up to speed soon.

For the brief while that I tested the miner, an 8GB Sapphire RX 470 OC mined at about 80Sols/s without errors.  The familiar SGminer statistic display was a joy to watch.

Please keep up the progress!       --scryptr

Why is so difficult to develop the sgminer for the ZCash? Can you just remove some optimisation from your own miner and then implement it in sgminer?

Hey maxmad_x,

I know you're frustrated. I'm sorry.

I am working on the documentation, as well as a GUI - it's in the roadmap.md

These things take time, and I know that's probably frustrating and not what you want to hear. But I'm committed to making SGMiner-GM the most user friendly piece of software out there. I just need your patience. I've gone ahead and added your 'feature' requests to the GitHub tracker (they were on my personal to-do list).



It compiles correctly for Wolf0 and I; I will work on this.

No, we don't work with just Zcash, XMR, and Ethereum. It's just those are the main coins for this release.

The whole SGminer needs to go GUI approach.
Too many algorithms, too many options that are irrelevant to some algorithms while being important for others. Its just too messy.

SGminer depends greatly on CPU too. on intel dual core machines it sucks balls!! I love the concept but implementation, documentation and representation is miserable. They need to work on making it more user friendly

Yes, and the miner incomprehensible. Perhaps he only works with - ZCash  XMR Ethereum, since other algorithms miner produces delusions

i got that one
but it failes too 
I wish I had an updated windows-build files to compile corectly, but it seems that devs just ignores it

Understood nothing - W7-64  zmingw64

Configuration - file curses.h not found in sgminer-gm, although it is in the sgminer-gm\winbuild\dist\include

Well, do not curses

Make


In the configuration of the library are listed as in the poppy is no longer found?

280x only 82

speed is low r9 390 only 80 sol (

i have try a little time, for ethash the speed is same with --nofee on claymore's ethminer.
but with the good tuning of intensity, raw intensity, etc... maybe we can make same hashrate without the devfee of claymore, without the option of dual mining.
so claymore win
but sgminer have another good features (failover, multi-algo, etc...) on stock

just one thing, this sgminer don't have a option --no-retry where the miningpoolhub's sgminer have. without this feature i can't switch with another miner easily and quickly.
on the doc i have see --event-on "idle" --event-quit yes but must wait 10min, too long

Right, heading off for some sleep - keep posting your bugs, and I'll respond to everyone when I wake up in, well, at least eight hours. I'll walk you through installs or help troubleshoot as needed.

Happy mining, guys!

I-I don't think so. I'll work on optimizations soon.

Make sure you have the AMD APP SDK installed - it's required for Windows.

You can get it from here.

Is this one faster than Claymores miner?

I just tried to run zcash sgminer in windows 10 it's a new install and as soon as I try to run the bat the variables are set than it closes I tried to run it with pause and got nothing from it I also tried to run it with just the pool and my login with no other settings and it still just closes do you have any suggestions thanks