Topic: [ANN] | SUQA | New X22i Algo | SWIFFTX | No ICO | No Pre-mine | %5 Apr Interest - page 90. (Read 181863 times)

Super!!! diff go to the moon

Hi everyone ,


Finally SUQA x22i AMD miner is here

https://github.com/zjazz/zjazz_cuda_miner_experimental/releases/tag/x22i_amd_0993

Grab it and join the hash!

each pool will take care of its miners itself, if the pool is not popular and empty, does it make sense to indicate it in ann thread?

when it's new of course it's empty. If you dont announce it how will people know.

I dont find it strange.

Interesting project. Can't wait to dig in!

This is not the place direct these questions ...

Please take it to the relevant thread, but generally speaking, the CWI website is up, but only the conditional part of the website. The rest is being finished in the backend and will contain ALL the coins we have ALL the coins we support in that website alone. There will not be anything separate. This means that if we support SUQA as part of the CWI Supported coins, we will have that included also, alongside partnered coins, in the one place.

#crysx

Hello my friend! What about sweepstake? What about countdown on website sweep stake? One year gone

This miner will not work in Fedora 27 x64 ...

Due to version issues with the compile that was done, and the tests we performed in CWI.

We have not tested this on any other OS.

#crysx

maybe someone does not know.
new miner for x22i algo.
hashrate  x2 for all gpu.

https://github.com/zjazz/zjazz_cuda_miner_experimental/releases/tag/x22i_0991

Thanks ...

Reading now.

#crysx

Constructive CRITICISMS (not complaints) ARE what you in front of you Pallas ...

Majority does NOT mean you have looked and catered for even the simplest of things within the code, such as executable bits before committing to Git, or missing the majority of the compat/ directory so people cannot compile properly before committing in Git. Seriously? You think that is a difficult thing to do for the 'majority' of the community? You think that is 'perfection'? Or is it simply laziness and a penchant for NOT checking on what SHOULD be a simple thing to fix?

Had you been truly 'sorry', then I would think even some of these simple issues would have been fixed and sorted from the beginning, instead of allowing the this wound to open and prove that the laziness that comes with the code, also reflects with the project, hence the team involved. It is a domino effect that is simply uncalled for. something that I honestly believe you think is irrelevant. I am NOT a minority, I am one of the majority. So if you think I feel left out, you considerably wrong. It is the same for the request I made to YOU personally about the XCN miner GPU limitation (remember that coin mate? The one YOU are the team lead in?). YOU responded with the acceptance it also needs to be done AND will resolve the issue when you can. It has only been approximately three months since I requested, and in that time, not only have you NOT had the time to 'fix' the miner, you have been able to work on the miner here, and a few other projects.

Kudos to you mate. This is what I mean by the responsibility of setting up a coin/project to be done in a professional manner. It has NOTHING to do with setting a 'perfect' coin. There is no such thing. Yet you take my criticisms, which I meant in all honesty and sincerity to be an alert to you and the SUQA team that there is something 'wrong' here, only to be shrugged off like this, and accused of 'feeling left out'? Come on mate. You know me better than most here, and a response like that is no response at all.

I am about to read the white paper now, seeing it has just been released.

I like the X22i Algo - so it will be part of our mining system soon. So ALL this I am writing is for what? Just simply to allow you to know the shortcomings of something YOU are involved in, that has fallen short of YOUR level of skill and expertise. Maybe I place you on a higher pedestal than I should, but the help you gave me personally will never be forgotten, so maybe that is where I deem you to be one of the better coders that wouldn't allow these simple issues to be present, which can be deemed as laziness within the project itself.

I will admit you are doing a good job thus far, but to say that I'm basically complaining because I feel left out? Well mate, the multiGPU XCN miner is now a CWI internal miner that DOES mine with more than 8+ GPU (upto 25 now), as we now have working with us one of the top level CUDA developers in the Crypto space (about to be published soon) who is assigned to build these things that most of the 'other' devs are too damned lazy to do from the beginning. This means it will COST us internally to have another miner to the same thing, when the simple fact is that the miner and code should have been 'fixed' from the beginning. Community pay for this? Or donate? Or did you bring this to life? Hardly.

As for the optimizations? Well, we all know what happens there, don't we mate? I'll stay watching this project. As for 'support' and 'community', we will see how that pans out. As long as you are involved here, then there is a good chance that things will move well, but these shortcomings being as prevalent as they are may prove quite the unstable platform you won't want to continue building on.



#crysx

 The  X22i Algorithm Whitepaper is Released!
Enjoy.
https://suqa.org/file/2018/10/x22i-proof-of-work-algorithm.pdf

by your own words, the fix you are requesting is not for "the majority", and if it was a one liner, and I could test it, I would have done it already.
but what about the majority? do you know there is no amd miner yet, for example? don't you think that, from the community perspective, that should be given priority?
releasing a perfect coin is impossible, pleasing everyone is impossible, we are doing our best and we are sorry if you feel left out.
constructive complains help.
good code commits help even more ;-)

No worries mate ...

The changes involved to increase GPU accessibility should be high on the list, regardless of whether they are farms or not. I am indicating (not stating anything about huge farms) that there are MANY single systems out there now who have much more than 8 GPU, which cannot be considered a farm by any stretch of the imagination, and should be supported also. So if the next version of the miner is that CURRENT technological advancements are taken into account, we can ALL benefit from it, not just the majority of smaller miners.

Two ways could have been approached here.

1 - Change the CURRENT fork of ccminer-tpruvot so that it allowed getblocktemplate direct mining.
2 - Change the older version of the fork (the one in git) to allow for multiple GPU, and able to compile properly with a COMPLETE codebase, not the partial one that is in git now.

Either way, I do write much because I write as I would explain in real life

Your opinion of a 'good' launch' is obviously different to mine mate, so I will leave it at that.

When decisions like this are made without community interaction or knowledge, then how much of a community project is it? Before or after you launch a coin/miner that benefits the select users that only have smaller machines (albeit the majority) AND know how to fix the issues in git? Just food for thought there mate

We are all in this together, so I will commit the changes to a Pull Request when I can this coming week.

#crysx

The real Founders fee is 7.5% because 2.5 % will go directly to SUQA Foundation Rewards. Total of 30 million SUQA will given as Rewards and Bounties in 5.78 years. Half of it in the 1st year because of the block rewards.

Thanks

SUQA Foundation

I don't think my posts shown anything about attacks; and I can explain everything, but you write so much :-)
We did not want to delay relase of the coin, nor make the miner unstable or buggy when first released, hence why we choose not to use the most recent ccminer and add getblocktemplate support to it. This meant no >9 gpu support, but I think a good launch and fair mining is more important. The miner will be enhanced and improved.
You are stating an absence of care for huge farms, I'm saying an absence of care would have been releasing a coin without gpu miner, and have all the private miners floating around, which happens on a lot of coins. We launched a fair coin, that was the goal. Now let the improvements come.
Feel free to make pull requests for any enhancement to the miner you might have. We are a community project after all.
Thanks for your support :-)

You need to create a text file located in appdata/roaming/SUQA and then save that file as “SUQA.conf” while selecting the “all files” option in the drop down menu.
Then fill that config file with addnodes located in the last few pages of this thread.
Restart the wallet and it should sync.

Yes - one question is answered ...

But I didn't ask ANY others, AND the reasoning you provided still doesn't fix anything Pallas. It just explains WHY.

It is this so called 'nitpicking' that you refer to that eliminates the confusion created when you speak generally of such things. It is something almost ALL developers seem to do in this Crypto space, and it causes more issue than resolve. Had there been specifics (those reasons) given from the beginning, confusion would not settle in and we would not be having this discussion. Better yet, had these issues been addressed BEFORE the release, the same would result. Either way, the issues remain and so the state of which the miner sits is still the same, getblocktemplate or not.

It is a few simple issues that could be easily resolved BEFORE the publication of the code, setting this project apart from all the others, instead of melding in with ALL the others that do the same thing.

BTW - I did NOT state that the GPU limitation was 'introduced' by the x22i Algo, I merely stated that there was NO CARE taken to allow larger miners a resolve to this GPU limitation issue of the miner. Something that could have been resolved also BEFORE the release of the miner, and something that is simply consequential of the lack of CARE taken once again, based on 'your' code or otherwise.

So thank you for answering my one question about the GPU limitation, and thank you for explaining why the issues in the git exist. It still doesn't help those that require a simpler way of compiling, nor does it help people who are new to this space (which unfortunately is the majority these days), to begin their journey into the mining/Crypto arena.

This is NOT an attack as you seem to have taken it, but specifics on what the ISSUES are in this project, at least from my/our side. Something this project NEEDS to consider when trying to show professionalism within the realms of the project, and all it has.

Much respect mate!

#crysx

Ty, but i got only 1,7 Mhs from 1063 and 1.8 Mhs from 1066 OC mode.
So, why your calculator used about 2.5 Mhs from 1063 and 2.6 Mhs from 1066 
btw i'm used windows ccminer