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

This cpu miner works awesome.  I am thoroughly impressed.  I am a small miner anyway but have effectively doubled my hashing power putting this miner on 3 good cpu machines.  Ready for the n factor change anytime.  Thanks guys.

Honestly, i was just too lazy to see if UTC chose a different group oh hashing functions than other scrypt jane coins.  I'm being lazy again, but if I remember correctly, scrypt jane has 3+ potential hashing functions.  Two are usually used for the PoW function.  If a coin dev chose too, he could use any of the 3+ available.  There might have be more than one mixing function, I really don't remember there.  Anyway, there should be different ways to implement scrypt-jane and I wasn't sure if they copied Yacoin, Ybcoin, etc and just changed the interest rate and start time, or if they did some more customization.  I figured it would be easier to just replace the 10 lines of code that return the N-factor to just return a bigger number and recompile it than to read and compare the code of the other coins.  

From what I can tell though, I really doubt they changed anything major with this coin.  

I find it scary that the devs don't even know how their own coin works.  The first n-factor change was a complete surprise to everyone!  Someone had to look at the source code and calculate the n-factor changes instead of the devs simply sharing this info with everyone. 

I still haven't heard a reasonable explanation as to why the N-factor is changing at such a rapid pace.  If the point is to discourage asics, then you could up the n-factor maybe once or twice a year at most.  Look at the vertcoin adaptive n-factor for something that makes sense.  As it stands the future of this coin is rapidly becoming a cpu-miner only, which is alienating the great community of miners that has come together to support this coin. 

Here is the vertcoin adaptive n-factor for comparison:

| N        | Memory | Timestamp   | Date/Time                     |   |
|----------|--------|-------------|-------------------------------|---|
| 2048     | 256 kB | 1389306217  | Thu, 09 Jan 2014 22:23:37 GMT |   |
| 4096     | 512 kB | 1456415081  | Thu, 25 Feb 2016 15:44:41 GMT |   |
| 8192     | 1 MB   | 1506746729  | Sat, 30 Sep 2017 04:45:29 GMT |   |
| 16384    | 2 MB   | 1557078377  | Sun, 05 May 2019 17:46:17 GMT |   |
| 32768    | 4 MB   | 1657741673  | Wed, 13 Jul 2022 19:47:53 GMT |   |
| 65536    | 8 MB   | 1859068265  | Tue, 28 Nov 2028 23:51:05 GMT |   |
| 131072   | 16 MB  | 2060394857  | Tue, 17 Apr 2035 03:54:17 GMT |   |
| 262144   | 32 MB  | 2463048041  | Sun, 19 Jan 2048 12:00:41 GMT |   |
| 524288   | 64 MB  | 2999918953  | Fri, 23 Jan 2065 06:49:13 GMT |   |
| 1048576  | 128 MB | 3536789865  | Wed, 28 Jan 2082 01:37:45 GMT |   |
| 2097152  | 256 MB | 5684273513  | Mon, 16 Feb 2150 04:51:53 GMT |   |
| 4194304  | 512 MB | 7831757161  | Sat, 07 Mar 2218 08:06:01 GMT |   |
| 8388608  | 1 GB   | 9979240809  | Thu, 25 Mar 2286 11:20:09 GMT |   |
| 16777216 | 2 GB   | 16421691753 | Fri, 19 May 2490 21:02:33 GMT |   |
| 33554432 | 4 GB   | 22864142697 | Sun, 15 Jul 2694 06:44:57 GMT |   |

I am still mining, and have been since day one, but I just don't understand some of the decisions that have been made.

Thirtybird, thank you for explaining, what cards do you use and would you share your settings for your cards per nfactor level?

All this detail should have been posted by devs on 1st page so we all knew what to expect, unless they were lacking knowledge at which point they should have said they didn't know what to expect. It was me who told bumface on CT that we needed to change our gpu settings when first 'public n-factor' came about, who then told ziggy. So if devs had no clue... leads me to believe they aren't even mining UTC anymore, since they would have been in same boat and had to of needed to tweak their own rig's settings and would have known about it instead of letting me tell them? So if dev's aren't mining their own coin.....UTC Pump and Dump coin added to the list.

To point 1 and 2 above;  yes I had not noticed the higher efficiency on the comparison page.  I do not ever intend to provide improper information.  Another found and posted right below me (Puycheval), the R7 250 was doing 2.47 kh/s @ 35w.  It would seem then an N = 15 would possibly be the last GPU point.  However, even at 14 it seems there are only 1 or 2 GPU's that are efficient?

To point 3.  Whew!  At least there was something 


Thanks for the reply with more information also.  Glad to see you post!

You need quite a bit of system RAM as the miner builds the OpenCL in system memory before passing it off to the GPU.  If you have a 4GB GPU, you will want 8 GB of system memory, or run the cards with 2 threads (-g 2) and half the memory.  This actually applies as you go up in number of cards as well.  My baseline is that the machine has to have at least half of the ram of the SUM of all the GPU's in the machine.  My miner with 4GB does okay with 2 4G cards, but even adding an additional 2GB card gets funny (I've found some workarounds, but it's a kludge).  One other miner has 4x 2GB cards and works great with just 4 GB system memory.

I've found you can fake this by either setting the --minf and --maxnf to the value you want to test, or, you know, mine a coin that is on that NFactor...  I maintain a list here if you want to test on a different coin:
[url]https://docs.google.com/spreadsheet/ccc?key=0Aj3vcsuY-JFNdC1ITWJrSG9VeWp6QXppbVgxcm0tbGc&usp=drive_web#gid=0[/ulr]

Absolutely incorrect.  I have done extensive work with YACoin, which is currently at N=14.  If you know what to look for in a card and how to work with it, the GPU is extremely more efficient.  My findings are out there if you do your research.  If you can't find it, the summary is : 2.9 KH/sec with a GPU consuming 25watts - compare that to any cpu and it favors pretty well.


Not bad, but what it actually boils down to is that the GPU runs out of memory to provide enough of a scratchpad to fully utilize all the shaders on the card without increasing the lookup gap, which in itself slows the hashing down. 

That's a poor comparison from the page.  What is unfortunately missing from that page is the amount of memory the card has - this is the most important aspect of how the card will perform at N=14.  I've put that info into many of the entries I've posted, but I'm not the only contributor.  The Xeon you quoted is actually mine, and it is horribly inefficient!  To get that, the server is running at over 400 watts, and I get a whole 1.53KH/sec (at idle it's over 260Watts), but I only get 1 miner out of it!  With a GPU mining machine, I can run 4 cards giving 10+ KH/sec for 200 Watts.  Actually, if you following cudaminer, the nvidia 750ti has come along and is now getting over 3 KH/sec for < 60Watts too. 


Finally, something I agree with

I'm having a weird problem with CGwatcher and UTC. When I start the miner with CGWatcher it doesn't seem to read the conf file properly. I don't get anywhere near the hash rate I should be getting and it throws out HW errors. If I start mining by double clicking the miner.exe  it runs perfect. It's seems like something happens when I add the miner exe to CGWatcher. I get the exact same problem on all my miners. Am I missing something?

I have been mining with my 1.2MH/s rig... But after leaving it for a day or so, the found shares drops down to almost 0... it still accepts fine... After I reboot the computer, the found shares speed goes back to "normal".... is there something wrong with my graphics card or is it just the way ultracoin works? It never did this when I was mining dogecoin

Get it repacked under a nice shiny UTC logo and get it on the webby 

Protagonus  --  Good explanation above.  More in detail than I was willing (and able in some cases) to go.  Everything you posted is correct.  Though, there was no discussion of how system RAM in multiple GPU machines will be affected by N-factor changes at 12 and above.  I haven't found much information about it either, but the trend isn't looking good.  I don't know if this is truly a system limitation or just an issue with how cgminer and it's derivatives allocate system RAM.  Either way, the hashrates are likely going to go down even more on multi-GPU systems.

The problem is this eventually leads to botnet mining taking over.  If they care to mine it at all.  It also alienates most people that are in it to mine with GPUs.  It's a bad case all around and completely unnecessary to be ASIC resistant.


edit:  If someone could hardcode the N-factor to 12, or 13 and recompile it, could we not test out how it would hash on a testnet?

lately I have tried to mine ybcoin but I couldn't find any working settings for it (n-factor is very high)..I have r9 290 and with ultracoin I'm getting 185kh/s...with ybcoin that is on higher n-factor, I was getting either 18kh/s!! with 100% hw errors, or 1,8kh/s stable     so, unless we fine tune it.even the 18kh/s with 0% hw would be nice..utc and all other coins will be pointless to mine on higher n-factors.

good find, looks like they just recently added the min/max and starttime parameters.
+1 internets to you sir

I don't get it. Everybody will suffer the same drop in hashrate for each N increase so diff coin output will stay the same unless people stop mining. And I think GPU are still ahead of CPU for 10 months+.

Anyway I prefer utc not being cpu efficiently minable else it'll mean botnets, aws instances ...

coin output remains the same whether there's cpu's or gpu's, n-factor or not, so...... why would there be a price change based on asic/gpu mining resistance?

Question is when is "the end" ?
For N=14  from your link :
Previous 7950 test was run with an old cgminer and/or unoptimized settings (lookup gap = 2 ...)

N=15 is  nearly 10 months from here so the end will wait  

So the coin is, in essence, ''miner resistant'' no matter what device mines it. pfft, advertise asic resistant when asics won't be mainstream for another few months. This changes everything and once again, hidden and tweaked info. utc seeming more and more like a sophisticated pump and dump since all ''miner-attainable coins'' will have been mined in 1 month with millions of coin inaccessible, in the blockchain. Diff will drop dramatically when gpu's no longer able to mine, so its good for the cpu's until the next nfactor after this next nfactor in april. Then pointless to mine completely.

I see there are some questions that keep popping up again and again.  Might as well pop in to see if I can help in some way. 



N = 14  07 / 12 / 14 @ 04:20:16am UTC   At this N and beyond it will be more cost effective to mine with CPU.


Both CPU and GPU are affected similar, in terms of dropping hash rate each N increase.  However, the gap in actual hashrate gets smaller with higher N.  As well, CPU's actually "fall-off" slower in hash slightly than gpu / perform better later.
 For example 600khs GPU with N increase may be similar to; 600>290>130>60>25>10>5.
                 Comparing this to a CPU over same N increases; 125> 65>  35> 20> 10>5>2.5

Part of this reason was described best and quoted here;

"CPU's still have a number of advantages over GPU's and ASIC's.  They come with double precision floating point hardware, employ very advanced branch prediction mechanisms, incorporate at least 2MB of on chip L2/L3 cache, and are able to speculate through 4-6 branches even in ten year old machines.  GPU's can manage 2-5x better double precision floating point performance than a typical CPU, but in some benchmarks, they cannot even manage even speed.  The problem is worse for ASIC's, which must be custom designed around a specialized pipeline. "


Again quoting another location;  here is a representation of hash rate on a CPU vs increasing N values.



    Running 1500 scrypt hashes with N=2048 - 0.00109417 avg. sec per hash
    Running 1500 scrypt hashes with N=4096 - 0.00216536 avg. sec per hash
    Running 1500 scrypt hashes with N=8192 - 0.00450547 avg. sec per hash
    Running 1500 scrypt hashes with N=16384 -  0.00928228 avg. sec per hash
    Running 1500 scrypt hashes with N=32768 -  0.01895874 avg. sec per hash
    Running 1500 scrypt hashes with N=65536 -  0.04028997 avg. sec per hash
    Running 1500 scrypt hashes with N=131072 -  0.08082690 avg. sec per hash


test written in python on an  i5-4250U CPU @ 1.30GHz,


In the end it's not that CPU's hash way faster than GPU's at high N's; specifically, it's that CPU's cost less Watts per Kh/s to mine at higher N's.

 Some examples of hash rates and setups with CPU's and GPUs @ N = 14;  can be seen here - http://yacoinwiki.tk/index.php/Mining_Hardware_Comparison

You can see, as an example here @ N14

2x E5645 Procesors    2x 80W --   1.53Kh/s    

7950 GPU                  (250w)    1.3-1.5 Kh/s

As shown above.  the Processors will give approximately the same Kh/s for 160w versus 250w of a 7950.


There are a few CPU miners.  One is listed on the Ultracoin forum too.  However, there is one specific miner that is best and most up to date.
 
-Manual N parameters for multiple coins
-X86 and 64bit formats
-Stratum pool capable
-Scrypt optimizations for Scrypt-Jane

https://github.com/thirtybird/cpuminer/releases/

This is the absolute best CPU miner out there currently.  I believe it has all the needs being asked for.



Even though I'm not actively posting here;  I still hate to not help if I can.

Thanks
Prot

UftrEhcPx5hTY4YJvSziPi13dfZT9nXSqw

The velocitycoin miner from http://velocitycoin.com/forum/index.php?topic=102.0 works.. I have just tried it with my i7