[ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!

[red5standingby]

diff >= 4  more pools online.

Welcome to the new world order. The new crypto holy trinity: BTC/LTC/UTC  

bye bye ftc


UTC is rising

[1715328764]

1715328764

[1715328764]

1715328764

[Thirtybird]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

[Rabbit80]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

Yes - I have to run lookup-gap 3 due to low ram in order to avoid hw errors.. without that i would be pushing 190KH/s

[Rabbit80]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

Unless somebody creates a way to run higher tc on 4GB systems without increasing lookup-gap then on a 290 more is needed

[AceCobra1]

diff >= 4  more pools online.

Welcome to the new world order. The new crypto holy trinity: BTC/LTC/UTC   

bye bye ftc


UTC is rising

What you on about? The price has just gone back down to 0.00018502

[Thirtybird]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

Unless somebody creates a way to run higher tc on 4GB systems without increasing lookup-gap then on a 290 more is needed

I'm running 2 4GB and 1 2GB card in one machine that only has 4 GB system RAM.  It can be done!

[fiatslugg]

I've been trying to encourage folks to hang out over at the UTC official site and it's forum. It's essential that we use it because new people will automatically head over there first and wouldn't it be nice to see something other than tumbleweeds? You never get a second chance to make a first impression.

On that note. It appears that UTC is being traded on a new exchange. I can not vouch for it yet, but it looks promising. They are advertising that they offer futures contracts on cryptos. Now you are talking my language. How cool would it be to buy and sell futures on UTC. I'm investigating. Oh, by the way. It was first announced here:

http://forum.ultracoin.net/index.php

If you are not using the UTC forum you are missing out.

[fabietech]

Hey there all,

Checking my stats ot Leetpools and see that i have 2996 valid shares and 300 invalid.
This is almost 10%, what can i do to fix this? someone experience?

this is my script ( 3 x 290 )
ultracoinminer -o stratum+tcp://ultra.leetpools.net:3333 -u x -p x --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -I 18 -g 1 --thread-concurrency 42000,42000,42000 --lookup-gap 3,3,3 --gpu-threads 1 --gpu-powertune 20,20,20 --expiry 10 --scan-time 1 --queue 0 --auto-fan --gpu-engine 1010,1010,1010 --gpu-memclock 1390,1390,1390  -T

[MasterCATZ]

Hi all
Maybe anybody knows how to stop cgminer in SMOS 1.3  remotly?
I tried to stop it via putty, but error occurs:

root@smos-1:~# mine stop
Stopping mining processes...: mine..cgminer api failed...
root@smos-1:~# gpumon
root@smos-1:~# mine stop
Stopping mining processes...: mine..cgminer api failed...
root@smos-1:~#

maybe log file may help, where it could be located?

sudo /etc/init.d/mine restart
sudo /etc/init.d/mine start
sudo /etc/init.d/mine stop


screen -ls
screen -x cgminer

nano / etc/bamt/cgminer.cfg

or other cfg files in that folder

my guess their is an , at the end of one of your cgminer settings on the bottom ( last one MUST have NO , and the rest NEED to have ,

[sakr]

Maybe its pools faul, did you check on other pools? I was mining on couple pools ( on scrypt ) and i found that on one i have 0.9% rejects and on other with the same config i get like 5 % -.-
What is the best pool for mining utc? - lowest reject rate and non stealing;d
How do you find mining utc profitability? My friend switched to mining utc few minutes ago and from his calculation its like 20% more profitable than scrypt mining;p

Check our new pool http://thepool.pw/ultracoin/ with 1.45% rejects so far, we need more miners!

[red5standingby]

diff >= 4  more pools online.

Welcome to the new world order. The new crypto holy trinity: BTC/LTC/UTC   

bye bye ftc


UTC is rising

What you on about? The price has just gone back down to 0.00018502

I know.  Keeping positive. 

[derBruchpilotPro]

Maybe its pools faul, did you check on other pools? I was mining on couple pools ( on scrypt ) and i found that on one i have 0.9% rejects and on other with the same config i get like 5 % -.-
What is the best pool for mining utc? - lowest reject rate and non stealing;d
How do you find mining utc profitability? My friend switched to mining utc few minutes ago and from his calculation its like 20% more profitable than scrypt mining;p

Check our new pool http://thepool.pw/ultracoin/ with 1.45% rejects so far, we need more miners!

More miners would be cool, I'm almost on top of the pool stats site with my little 2 rigs...

[Rabbit80]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

Unless somebody creates a way to run higher tc on 4GB systems without increasing lookup-gap then on a 290 more is needed

I'm running 2 4GB and 1 2GB card in one machine that only has 4 GB system RAM.  It can be done!

Sure it can - albeit slowly What cards and what KH/s?

[azerbaidjan]

Despite some obvious dumps from today UTC price remains impressively stable.
Not even the slightest decline, this is absolutely excellent.

I long for a rise now...

Stay tuned.

[Thirtybird]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

Unless somebody creates a way to run higher tc on 4GB systems without increasing lookup-gap then on a 290 more is needed

I'm running 2 4GB and 1 2GB card in one machine that only has 4 GB system RAM.  It can be done!

Sure it can - albeit slowly What cards and what KH/s?

They're running on YACoin, N=14
R7 240 4GB 2.9 KH/sec
XFX 7750 2GB - 2.2 KH/sec (this one doesn't overclock well)
you can compare them here to determine if they are "slow" http://yacoinwiki.tk/index.php/Mining_Hardware_Comparison

I'm not sure why you think it can only be done slowly.  4GB is a fine amount for a machine with only a couple of miners, or a number of miners with low memory.  I feel I am pushing the limit of what can be done with 4 GB though, and if I ever wanted to expand, I would choose 8 GB.

[Rabbit80]

Thanks a lot ;p do you think that with more ram it is possible to get higher hashrate?

No, not necessary ... yet...

Unless somebody creates a way to run higher tc on 4GB systems without increasing lookup-gap then on a 290 more is needed

I'm running 2 4GB and 1 2GB card in one machine that only has 4 GB system RAM.  It can be done!

Sure it can - albeit slowly What cards and what KH/s?

They're running on YACoin, N=14
R7 240 4GB 2.9 KH/sec
XFX 7750 2GB - 2.2 KH/sec (this one doesn't overclock well)
you can compare them here to determine if they are "slow" http://yacoinwiki.tk/index.php/Mining_Hardware_Comparison

I'm not sure why you think it can only be done slowly.  4GB is a fine amount for a machine with only a couple of miners, or a number of miners with low memory.  I feel I am pushing the limit of what can be done with 4 GB though, and if I ever wanted to expand, I would choose 8 GB.

Fair enough.. However the R7 240 only has 320 stream processors, the 7750 only 512. This allows much lower TC without errors for some reason. The 290 has 2560 stream processors. With a TC of 28000, a lookup gap of 2 and intensity down at 12 it only manages 75KH/s. Any increase in intensity then causes hw errors.

Using my earlier config of TC 42000, lookup gap 3 and intensity 19, i can get nearly 150KH/s. Increasing system RAM to 8GB and lowering lookup gap back to 2 gives me around 190KH/s.. (getting a new board in the next couple of days with more RAM on it - YAY!!)  

[laterbreh]

OMG orphaned galore  

What causing this?

UTC does NOT have a DE-centralized network anymore.Congrats to miners insisting on just one (Nitro) pool.

Nothing wrong with the Stuhlman here,but this needs to change.Otherwise miners are going to see more orphans,who try to keep mining in other pools.That's what I suspect.

Why not somebody create P2P pool(s) for UTC? I'm not technically talented but I keep asking that question...

I've moved to leetpools since last week because of continuous dc of nitro.

I thought leetpools have this issues.

Its none of the pool owners fault, the network is unbalanced, and Nitro has more than 50% of the network (No fault of theirs). If the hashes spread out there would be less orphans on the network as I understand it. Nitro's hashrate is so large, they define the network. The hashes need to spread out.

Whats funny is that when Nitro goes down for maintenance, 35% of the miners instantly Failover to our pool (LeetPool), and the orphan rates go down immediately.  

We need the miners to spread the hashes to all the pools on the network, and it will keep the coin healthy.

http://bitgo.pw/utc/ <--- Look at the bottom at the pool hashrate chart.

Since the hashrate is so enourmous as one pool compared to another this happens:

We will solve a block:


Nitro will solve the same block:


See what happens here? Nitro will beat everyone to the punch if they happen to solve the same block as another pool even if we might have solved it first, or if Nitro might have solved the block first, we will be late because the network is defined by the hashrate.

I was talking with TheSerapher in IRC, and he suggested that other pools add Nitro as a node for UTC -- But he did not elaborate on how to do this. If anyone can think of a solution, please chime in.

[Thirtybird]

Fair enough.. However the R7 240 only has 320 stream processors, the 7750 only 512. This allows much lower TC without errors for some reason. The 290 has 2560 stream processors. With a TC of 28000, a lookup gap of 2 and intensity down at 12 it only manages 75KH/s. Any increase in intensity then causes hw errors.

Using my earlier config of TC 42000, lookup gap 3 and intensity 19, i can get nearly 150KH/s. Increasing system RAM to 8GB and lowering lookup gap back to 2 gives me around 190KH/s.. (getting a new board in the next couple of days with more RAM on it - YAY!!)  

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.

[fredeq]

I wonder why running more threads on 290 gives nothing.

[Rabbit80]

Fair enough.. However the R7 240 only has 320 stream processors, the 7750 only 512. This allows much lower TC without errors for some reason. The 290 has 2560 stream processors. With a TC of 28000, a lookup gap of 2 and intensity down at 12 it only manages 75KH/s. Any increase in intensity then causes hw errors.

Using my earlier config of TC 42000, lookup gap 3 and intensity 19, i can get nearly 150KH/s. Increasing system RAM to 8GB and lowering lookup gap back to 2 gives me around 190KH/s.. (getting a new board in the next couple of days with more RAM on it - YAY!!)  

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.

Great explanation - I stand corrected.

If I set g=2 then my whole system freezes regardless of i / tc. On my 280X it has a significant impact on performance (more so than lookup-gap).

The version of cgminer I am using supports raw-intensity, but I have no idea of the values so I left it alone.