Topic: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!! - page 374. (Read 946654 times)

Maybe Nitro should take 1 for the team and just take their pool down, and put a message on their home page saying "Pool is offline until miners are distributed evenly among the network".

I am on a desktop not a mobile device. Site looks "mobile" in all 3 major browsers.

Caterpie69 i don't think that would work. Miners wouldn't even bother because their hash power would fall back to next big pool (automatically)
And now, this next big pool would have the majority of the hash power.


Can i access the "standard" interface somehow ? a hidden folder ? a hidden parameter ?

PS : Even on mobile i hate mobile versions of almost any site. I use the "Full version" link or in case there isn't one i use chrome and "Request desktop site".
I am a power user and like to have many options and many small things instead of big, shiny, less useful/powerful buttons.

Hi, we have actually redone the mobile interface to the classic while we work on fixing the issues on the mobile version

Lol @ Nitro

Est. Avg. Time per Round (Network)    32 seconds
Est. Avg. Time per Round (Pool)    30 seconds

I would mine l33tpools (they are in fact my failover) but i don't like the damn mobile interface style. I am always searching the buttons first before clicking them.
I like the neat, classic pool interface (like, for example, nitro's)
I consider myself a medium-sized miner, pushing almost 2 ultracoin MH.

I know this centralization is bad for our beloved coin, and i wouldn't mind nitro going as high as 10% fee to "spread the love", maybe 1% more per day until it reaches that (of course notifying everyone by email). Maybe there is just no other way. Registrations are closed now but ... isn't the damage already done ?

My .2 UTC.

PS : liked & shared FB page

OK EVERYONE GET OFF NITRO POOL RIGHT NOW ATLEAST HALF OF YOU GO JOIN OTHER POOLS.
WE ARE ALL STEPPING ON EACHOTHERS TOES HERE.
THE ENTIRE POINT OF CRYPTO IS TO BE DE-CENTRALIZED,

You are hurting other pools by mining on Nitro , what is so hard to understand?


If it doesn't change, the only pool left will be ...nitro because as it stands it is becoming increasingly difficult to mine on any other pool.

having such a large % of miners on one pool causes orphans on all other pools, other pools are solving work before nitro and their work is getting thrown out because nitro didn't get the memo.

As it stands tomorrow I have to stop mining this coin because
1) Any coin that has only one pool is essentially doomed to fail so there is no point in mining it.
2) mining on other pools atm sucks with the amount of orphans nitro is causing.


By mining on nitro, you are ensuring this coin dies.


Nitro needs to raise fees to 15% to re-distribute the network a little, it just has to happen, there are other good pools out there, there is no reason for everyone to bum rush one single pool.

ULTRABAMT

Bamt Ultracoin version  

I have just released  my custom   Bamt   With scrypt-jane cgminer  3.7.2    

this is a quick modification of the existing bamt 1.4 for  79xx cards

the 1.3  version   for  r9 series is coming soon,

This is for peoples who dont want to deal with linux commands and just want something plug&play

I hope it will help,  this is my small contribution to the Ultracoin scene

Enjoy


UltraBamt 1.4 https://mega.co.nz/#!JV9DyBgS!Ig7iqwsri6Ijcp055HZNtgNsVcUilE1mLJKew6xEXVs

Root Password  1234

You obviously don't realize that thread-concurrency actually has nothing to do with shader count when it comes to scrypt-chacha.  Thread-concurrency only sets the scratchpad buffer size (TC*128 / (1024/LG) = #MB in the buffer (with some rouding on Lookup gaps not evenly divisible into 1024).  I don't use thread-concurrency actually - my dev version (The 3_4_3-Testing branch on my github) finally supports setting just a buffer size - internally, it does set the TC value which is what gets passed to the scrypt-chacha openCL kernel program though.  So my command line looks really strange compared to yours I'm sure

yacminer -d 0,1 --remove-disabled --scrypt-chacha --worksize 128 -g 2 --lookup-gap 2 --raw-intensity 640 --buffer-size 1520 --lots-of-other-stuff

You are right about one thing - with 4 GB of system RAM, I cannot allocate enough system memory to allocate 3.6 GB per card when initializing them.  I can, however, allocate 1.5GB 2 times on each card just fine without any loss in performance (from what a colleague has tested on the same card allocating the whole buffer for 1 thread - he also gets 2.9 KH/sec).

With that said, the one thing from above that allows you to do that is :
-g 2
This runs two separate threads within the miner.  You cut your TC in half and then subtract a bit for headroom to ensure it isn't putting one of your threads in dynamic GPU memory.  If you aren't using YACMiner, you're missing out on being able to fine tune your intensity using --raw-intensity.  Using a miner with just -I, I would have to choose -I 9 (which correlates to --raw-intensity 512), I would be losing performance as I am able to launch an additional 128 shader threads per thread per card(128*2*2 = 512 shader threads, or roughly 25% performance).  Now, this card, even at N=14 it is actually shader limited.  On cards with higher shader counts, you do need to be able to set a higher buffer-size (meaning more system ram), or increase the LG (as you are doing), or run more threads (-g 2).  

Experiment - tuning cards for high N factor takes experience, patience, and a willingness to try lots of different configurations.  In my case, I found a better way to control the GPU and made the correlation to how it works at higher N factors.  I made the software updates, and those are available to anyone.

Just telling you whats exactly is going to happen so you can anticipate it

looks like someone is tryng to zig zag his way to profit