Topic: [ANN][YAC] YACoin ongoing development - page 166. (Read 379873 times)

Here are all my GPU benchmarking results, and also the speed ratio of GPUs and CPUs, for good measure.

GPU: HD6990 underclocked 830/1250 -> 738/1250, undervolted 1.12V -> 0.96V. assuming 320W power usage
CPU: WindMaster's 4 year old dual Xeon, assuming 80W power usage. In reality it's probably more, but newer processors achieve the same performance with less power usage.


GPUs are getting comparatively slower bit by bit, until (as I've stated in an earlier post) at N=8192, GPU mining seems to break altogether.

EDIT: Replaced GPU/CPU ratio with a more useful power-efficiency ratio.

I'm measuring Nfactor=21 (N=4194304) to yield about 1.73 hashes/sec on a 4 year old dual Xeon E5450 server (combined performance in the ballpark of an i7-2600k).

EDIT - All my benchmarks out through Nfactor=21 are now posted in the table of Nfactor++ events:
https://bitcointalksearch.org/topic/m.2162620

It's readily apparent at what point the memory usage becomes high enough to no longer fit in the on-die L1/L2 caches on these particular Xeon CPU's and starts falling to entirely off-chip memory.

Indeed, that's the reason I mentioned I don't necessarily subscribe to Moore's Law in the more recent timeframe, due to slow rate of process node improvements.  Cost reductions for those process nodes may still occur and make it possible to continue increasing core counts at a lower cost per core over time though.



Ivy Bridge is built on a 22nm, so there's still some forward progress on process nodes occurring.  Just not as quickly lately.  Intel is aiming for 14nm, having started constructing the Fab 42 facility in Arizona, expected to come online for fabricating 14nm later this year (we'll see).  There's still some debate whether 14nm or 16nm will be the minimum size achievable before quantum tunnelling issues prevent any further scale reduction.  So, there will indeed be a stagnation in processes somewhere in the 14-16nm range.  At that point cost reductions of those processes and increased core counts are probably where things are going to head.



Sure, I'll test N=4194304 next and report back in a bit.



I actually have minimal familiarity with how the PoS side of things is going to work.  That part is still a mystery to me.

I know about Moore's Law. But there're still risks in it. Because current technology is reaching its limitation, remember that Intel/AMD/Nvidia still stick to 32nm or so for many years, this doesn't obey the Moore's Law, they can't make a faster CPU instead they can only make multi-core CPUs.

Can you check this Nfactor: 21      4194304      512MB      1636426656      Tue - 09 Nov 2021 - 02:57:36 GMT

If we can be safe at this year, then we can have another 9 years to upgrade our equipments.

This is for the PoW model, here is another story for PoS.

Tell from the code, PoS uses SHA256, right? Thank god, it doesn't use SCRYPT-JANE this gives me relief, if PoW blocks generation becomes slow, the PoS block can make the network continue functioning.

Oops, I made a booboo in that post that you quoted.  I meant Nfactor is capped at 30, not N.  I fixed my original post.

But otherwise yes, it's possible to compute a hash at Nfactor=30 with a box with 256GB, although some swapping of the OS and any other running software would occur since 100% of the RAM would be needed to compute one hash.  Now, it would certainly take a while to compute a hash at Nfactor=30.  I'm guessing by the year 2421, that won't be an issue though, and we're probably not going to be using cryptocurrencies in their current form anywhere near that long either.

Validation of the previous portion of the block chain would be happening at the original N at the time that block was mined, not at the current value of N.  I think where we would get into trouble is when it takes as much or more time to validate a block than the target time between blocks (1 minute).  Somewhere in the next few years, I'm sure the debate of storing the entire blockchain on every user's computer will be discussed more and more among all the coins.

I'm benchmarking large values of N right now.  The highest I've benchmarked so far is N=262144 on a dual Xeon E5450 server (which is ~4 year old server technology), and have around 30.55 hashes/sec at that value of N, which would be hit on June 23, 2015.  Looks like mtrlt benchmarked his 6-core Phenom to the next N increment beyond that (which I'm benchmarking right now) and got around 12 hash/sec.

Based on the slope of the N increases over the long run, Moore's Law (not that it's a hard and fast rule) will begin overtaking the N increases and average hash rates per user will start rising again.  I don't necessarily subscribe to Moore's Law actually being valid at the immediate moment, looking at the actual processing power changes over the last 18 months.  However, out in the future, YACoin's Nfactor++ events become less and less frequent.

Now I have a question for the N value becomes even larger in a year, the hash speed drops to only 100 hashes/second even on a server.
Won't the client be able to validate the block chain because the hash speed is too slow? I don't know if the client will validate the whole block chain after it makes a fresh download.

This is true.  I'm not going to dispute that.  



Thanks for the link, I'll have a read of your memcoin thread.  In a quick glance through, I'd say we're both in agreement YACoin's starting N was far too low, at least.



Roger that.

Thanks! So even existing workstations (e.g.) can handle N=30.

I don't know yet. It just stops working on its own.


Yes, in fact I tested CPU mining up to N=2^19=524288, where my puny Phenom x6 1055T got around 12 H/s.

Have a look at the table of N increments I posted:
https://bitcointalksearch.org/topic/m.2162620

The memory column shows how much memory is needed to compute a hash (assuming no TMTO shortcut is in use).  Total memory required is equal to that multiplied by the number of hashes you're trying to compute simultaneously.  For CPU mining, it would be the number in that table multiplied by the number of threads you're using.

As you can see from the table, it's going to be a couple decades before N reaches high enough that even today's typical desktop PC would start swapping.  Even in the year 2421, memory requirements only rise up to 256GB at Nfactor=30, and Nfactor won't go any higher than that (it's capped at 30).

You're a feisty one.  You're correct on the date, it was during the memcoin thread which was apparently November of last year, so I guess only six months old.  Guess my memory slipped, but things move quickly these days.


It works fine above that, I've used it beyond 32768 (see that thread).

Benchmark and test run at N=32768 I ran and posted on the previous page to dispute TacoTime's claim hash rates will drop to double digits in a year:


If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork.

Since we are doing some Q & A, I've been wondering if an insane high N would (painfully try to) use swap memory.

Very interesting news. Might there be some additional optimizations that you could do to get it to output (perhaps like messing with the lookup gap or some other TMTO hacks?)

I'm wondering two things:
a) why do you think it stopped working at 8192 (physical GPU limitation with current gen GPUs, or more a limitation of the code that can be more easily overcome)?
b) does CPU mining still work at 8192 and beyond? (if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).

Thanks for your insightful work on the GPU miner around YAC.

The actual code that calculates the Nfactor isn't a nice smooth progression, it combines a couple calculations together that each cause Nfactor to change on different intervals.  The actual code in main.cpp looks like this, if curious:

why does n stay at 512 for only a few days?

7      256      32kB      1369039776      Mon - 20 May 2013 - 08:49:36 GMT
8      512      64kB      1369826208      Wed - 29 May 2013 - 11:16:48 GMT
9      1024      128kB   1370088352      Sat - 01 Jun 2013 - 12:05:52 GMT



I appreciate all the discussion in this thread. and specifically the posts by windmaster.

It's good that yacoin did not change the 1 week average window of ppcoin's adjustment. So the attack can only change difficulty by ~2.5% for the next block, which may or may not be attacker's block.

This is not an exploit specific to the continuous difficulty adjustment of ppcoin. In bitcoin style step adjustment, an attacker can manipulate the timestamp of the last block of an adjustment interval. If attacker manages to mine the last block of an adjustment interval, the entire next interval's difficulty could be lowered. That's why one should stay with a longer adjustment window.

I don't have a proof for that but I'm fairly sure he is some other guy. He is obviously very knowledgeable and I don't think he appeared just like that.

Damn, I guess WindMaster might have some other nick too

It's interesting and unique enough (as indicated by the speculation and debates it provides (such as those by WM and taco))  that I've kept an eye on it since day one. The only thing that the cookie cutter coins have provided is a point-and-shoot solution for the pump~dumpers. YAC has some substance, which - along with active development, should hopefully keep it viable for the long term.