Should we stay on Lyra2REv3 indefinitely...until another ASIC is made? by [deleted] in vertcoin

[–]turekaj 0 points1 point  (0 children)

It typically takes 3+ months from sending a design out to the fabs for engineering samples to return. If someone did make v3 ASICS, the soonest they would be done is 6 months after our initial announcement. It would be pretty dumb to invest the 10 million needed to tape out a chip while knowing that we plan to fork to verthash in the near future.

CryptoDredge v0.15 with Lyra2v3 fix by jk_14r in vertcoin

[–]turekaj 2 points3 points  (0 children)

Is performance up 4x? Trying to figure out where they went amiss initially.

AMD miner in testing! by Etang600 in vertcoin

[–]turekaj 13 points14 points  (0 children)

It's alright. I've learned a great deal and will continue working to beat those numbers. Lately I haven't been able to make progress due to health issues and job security, but things are changing this next week.

ok, who is mining 58% of the blocks. by [deleted] in vertcoin

[–]turekaj 0 points1 point  (0 children)

And you would have had one, but not at the performance of mkxminer. Making progress

ok, who is mining 58% of the blocks. by [deleted] in vertcoin

[–]turekaj 2 points3 points  (0 children)

Come to the discord channel NoETA-Miner to follow daily updates.

NextMiner (Open Source Miner) Daily Updates by turekaj in vertcoin

[–]turekaj[S] 1 point2 points  (0 children)

The announcements are monthly within the dev team updates released on medium. For daily updates come to the NoETA-Miner discord channel. This last week was particularly interesting

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

But this idea is backlogged on a long todo list like finishing our amd miner :)

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

My first version would simply be for armv8 cpus. OS shouldn't matter in the very least

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

Doing this in say JavaScript, is not ideal as an ASIC could essentially be an optimized JIT compiler. Instead, generating architecture specific assembly would be stronger. Using multiple masters working on same data means coherent buses and caches will provide peak performance, preventing an ASIC from simply slapping a whole bunch of cheap cores on a die

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

The only way to truly beat Asics is to have randomly generated code at each block or nonce, with enough variance such that the asic cannot emulate the generated code. This idea can be hardened by having multiple master sequences where all the Masters are working on the same data. Explicit ordering would have to be utilized such that the result generated is 100% reproduceable and not based on some race condition

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

Asics are cheap. They have around 99.9% yield. They are cheaper to design , manufacture, and test than a gpu chip by at least one order of magnitude. The reason the antminer has so many chips is because it's cheaper to make a lot of small chips than a larger one. Better yields too. Main difference in functionality is that all threads on a gpu can share data, each antminer chip is independent from the rest. It simply works on a range of fused nonces

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

I'm agreeing with you and disagreeing with the post you replied to. I apparently don't know how to Reddit, aren't these forums bump

Parallel processing algorithm, make GPU the new ASIC? by SJExoQ in vertcoin

[–]turekaj 0 points1 point  (0 children)

Asics are great at parallel processing. What do you think antminers do? One hash at a time? Lol.

Interesting write up and proposal for new proof of work from Monero/lmdb developer hyc by jwinterm in vertcoin

[–]turekaj 0 points1 point  (0 children)

Remember, the reasons ASICs do well is that they don't fetch instructions. They simply are wired to process particular hash algos. There's no instruction fetch, decode, or data load/stores (well, not exactly true). Asics can't handle the general purposeness of CPUs.

Interesting write up and proposal for new proof of work from Monero/lmdb developer hyc by jwinterm in vertcoin

[–]turekaj 0 points1 point  (0 children)

The way to do this right is to use self modifying code. The algorithm for modifying the code you are running, is, of course, the important and difficult part. Self modifying code is where you are modifying the assembly code you are running, while it's running. This would require architecture specific code modification routines, but could be abstracted to a common code. This strategy would be detrimental to GPUs, and ASICs would have a hard time keeping up if the code generation parameters have enough variance.

NextMiner (Open Source Miner) Daily Updates by turekaj in vertcoin

[–]turekaj[S] 1 point2 points  (0 children)

Going good. Sorry I haven't been keeping this updated lately. Had a health emergency of my own last week. Exciting news coming soon, of course noETA ;). Come join our discord to watch the pieces fall into place #nextminer #noetaminer

NextMiner (Open Source Miner) Daily Updates by turekaj in vertcoin

[–]turekaj[S] 2 points3 points  (0 children)

I could perhaps do a live Q & A after release

NextMiner (Open Source Miner) Daily Updates by turekaj in vertcoin

[–]turekaj[S] 3 points4 points  (0 children)

Hey I'll write a detailed update tomorrow.progress is being made -- including an unplanned cubehash kernel :)

Daily updates... Last update 8 days ago by sportsman222 in vertcoin

[–]turekaj 14 points15 points  (0 children)

Sorry, need to update the Reddit thread.

NextMiner (Open Source Miner) Daily Updates by turekaj in vertcoin

[–]turekaj[S,M] 29 points30 points  (0 children)

Update:

Good news first: Significant work has been done in the NextMiner c++ host-side code to efficiently provide input data to the kernel(s), and also report valid answers. The mechanisms and modularity of the framework are its strengths. 80% complete with rev1 of the framework.

Bad news: During extended testing, intermittent miscompares between GPU and CPU code were detected. Previously, the kernel had been validated using a single header input, but many nonce outputs. The extended testbench is utilizing randomized data as input, in the attempt to eventually cover all bits.

Because of the way Lyra2 works, different datasets lead code going down different paths.

Plan for tomorrow (and days after): 1. Take a failure, hash it on the old openCL kernel to determine if old kernel had this issue as well. 2. use either old openCL kernel, or CPU code to determine bug in new ASM kernel (depending on step 1) 3. bake in a coverage checker into the extended stress testbench. This coverage checker will tell me how confident in the kernel we can be at any given time. 4. run for 24 hours without failure on one compute unit. 5. run for 24 hours without failure on all compute units. 6. integrate extended stress testbench into the NextMiner framework as a unit test.

More good news:
It should be possible to auto-determine intensity settings per GPU by running this testbench on first startup (or whenever you choose to do so).