The new algo looks interesting. Is the miner already optimized to use the advanced instruction sets of new CPUs?
Not yet. |
|
|
|
ghostlander what do you say??
Our partnership with Bitscoinshop seems very promising. |
|
|
|
Anyone have the blockchain uploaded?
I want to sync faster.
Same question, were can we find bootstrap.dat ? (832166 blocks, Windows only, 322Mb) md5sum (data.7z) = 4d3741b01d6609bf8f8a4b4fe36e863a Block chain data, block index and transaction data base. Decompress to your Orbitcoin data subdirectory cleaned up previously (keep wallet.dat, peers.dat and orbitcoin.conf). |
|
|
|
Arithmetic intensity, also known as ALU:TEX ratio... anyhow if it's not for GPUs then I guess this is the future of CPU mining?
I am very confused and I cannot make any sense of what you just wrote.
Well, it's still a decent choice for GPUs. Lower memory requirements allow to run more threads in parallel to work around access latency. I cannot tell how good it will be, but I expect NeoScrypt CPU and GPU miners to co-exist for some time. I don't expect ASICs soon because NeoScrypt is unlikely to be implemented as a by-product in SHA-256 or Scrypt devices due to different hardware requirements. SHA-256 ones are very simple high speed ALUs with next to nothing memory requirements. Modify the ALUs and add some eDRAM = universal SHA-256/Scrypt ASIC. I doubt their designers would like to modify the ALUs even more and include fast SRAM to satisfy NeoScrypt. |
|
|
|
Why don't you look at the documentation on GPU programming?
Original scrypt was already compute bound. Neoscrypt is even more compute bound. People in GPU programming would go great lengths to have half the arithmetic intensity original scrypt had.
I'll ask you again: what does "memory intensive" mean? Fetching some memory every once in a while isn't an "intensive" operation.
What am I supposed to do with your documentation on GPU programming? NeoScrypt has no sole purpose of running perfectly on GPUs either existing or to come. Neither Scrypt had it originally. NeoScrypt performs very well on CPUs now and it's going to be even better with the following optimised releases of CPUminer. It takes full advantage of large and fast L2 caches. This is something you don't find in GPUs and ASICs because high clock and low access latency multiported synchronous SRAM is very expensive. GPUs do very limited caching at all. They rely upon GDDR5 memory bandwidth and large thread count because access latency is terrible. Scrypt ASICs must be using eDRAM which is more expensive than GDDR5 and faster due to lower latency and wider internal data bus, but it's DRAM still and doesn't clock very well. Intel Crystalwell has made it to 1.6GHz which is absolutely not impressive if compared to ~4GHz of modern CPUs with their L1 and L2 caches. Even single ported asynchronous SRAM used for L3 caches seems better than eDRAM for performance reasons. Let's see how GDDR5 and eDRAM work against SRAM under NeoScrypt. What comes to memory intensity, you can calculate how many quarters it takes to produce a single hash for Scrypt and NeoScrypt. |
|
|
|
Recommended Phoenixcoin NeoScrypt settings for solo mining:server=1
daemon=1
defaultkey=1
logtimestamps=1
dns=1
addnode=prometheus.phoenixcoin.org:9555
addnode=menoetius.phoenixcoin.org:9555
addnode=atlas.phoenixcoin.org:9555
rpcuser=your_username
rpcpassword=your_password
rpcallowip=192.168.0.*
If you mine with a single machine, set rpcallowip=127.0.0.1; if your LAN subnet isn't 192.168.0.0/24, set rpcallowip accordingly. minerd.exe --no-gbt -a neoscrypt -R 10 -o http://192.168.0.2:9554 -O your_username:your_password
Replace 192.168.0.2 with the IP address of machine where you run the wallet. You can use this pxc_solo.bat to solo mine using many machines on your LAN. CPUminer detects number of cores automatically. Override with -t or --threads if necessary.
|
|
|
|
Coinmarketcap is showing PXC with 6 million coins outstanding. I don't think that's right. I thought there were around 22 million coins out now. Just an FYI, not sure if they're getting the wrong info.
Cheers!
They used my block explorer in the past ( http://explorer.phoenixcoin.org) until decided to switch to Coinplorer ( https://coinplorer.com/pxc). The latter wasn't upgraded in time before the NeoScrypt switch and re-loading the chain now. 3 days have passed and it is at #150K only. Ok thanks for the update. Have you considered possibly reducing the mining subsidy and max coin cap with the next code update. Given lower demand for alt coins right now and many more coins (supply) being added daily it would be wise for any coin to do the equivalent of a stock BuyBack and reduce its inflation rate and max dilution by as much as possible. I hope you consider this proposal as it will benefit everyone involved just as all investors in any stock (big and small) benefit from a stock BuyBack. Cheers! I'll consider your advice, but it is for the next hard fork which isn't going to happen soon. |
|
|
|
Considering the massive amount of computation, what does "memory intensive" mean?
Memory read/write operations. Why don't you look at the source code? |
|
|
|
I have a lot of trouble understanding. Claimed to be harder on memory, takes 20 rounds of salsa (already too much to be memory-bound) adding other 20 rounds of chacha? Half the memory amount, paper claims to be "1.25 times more memory intensive"... due to cache effects I assume? Anyway, scrypt was compute bound... I've been looking at this for a few days and I cannot understand what's the whole point.  What's your question? |
|
|
|
Any pool to mine PXC? bcoz I see all p2p either dead or outdated
MinePool - no neoscrypt support
Multipool - Abondoning PXC
so any pool left to mine?
http://pxc.theblocksfactory.com |
|
|
|
Could you explain in detail how to set up staking? I feel I have missed out on a ton of orb due to the lack of information.
Make inputs 20+ ORB each. Keep your wallet online 24/7. Use the Coin Control to spend the youngest inputs first. |
|
|
|
So in the scenario I described, with each PoW being 1 ORB, the wallet will never stake. Why isn't the limit set at 20 (or higher) so that virgin PoW inputs can be properly combined to stake? Surely there must be people who simply mine and hold - their wallets will never generate PoS...
Even if it was set higher, 1 ORB input had very little chance of generating stake kernel due to low weight (20 maximum). Right now, I see inputs in my wallet staking with weights 250 to 400. Each. |
|
|
|
It's late and I'm tired so perhaps I'm misunderstanding: if I mine PoW and never do anything else (sending 20+ ORB back to myself etc), my wallet will never stake?
Up to 10 inputs can be combined for staking. 10 inputs * 1 ORB < 20 ORB minimum. |
|
|
|
|
1487 / 72 = 20 coin days per average input. All of them are max. weight. I suppose you have solo mined 72 blocks 1 ORB each and left them staking without merging. If so, they will never stake. Too small.
|
|
|
|
Coinmarketcap is showing PXC with 6 million coins outstanding. I don't think that's right. I thought there were around 22 million coins out now. Just an FYI, not sure if they're getting the wrong info.
Cheers!
They used my block explorer in the past ( http://explorer.phoenixcoin.org) until decided to switch to Coinplorer ( https://coinplorer.com/pxc). The latter wasn't upgraded in time before the NeoScrypt switch and re-loading the chain now. 3 days have passed and it is at #150K only. |
|
|
|
wts 28890PXC=0.025BTC
cryptsy can't generate new address
Trade on AllCrypt. That's a decent exchange with a somewhat outdated interface and low volume, but fast and reliable. |
|
|
|
|
Looks promising. C-CEX is good for start, are there plans for other merchant APIs?
|
|
|
|
If you compile it yourself, it is configured without assembly code by default. If you want it, configure this way: env CFLAGS="-O2 -fomit-frame-pointer -DASM" ./configure
Compare your results with and without assembly. I know some AMD CPUs may deliver a little better performance without assembly code. Thanks Ghostlander. It did make a difference for FX-6300 and A4-6300, like +30%. Didn't make any difference in case of older k10 based CPU (Athlon II X2). I don't know if there is a point in playing with -O3 -march=native? Could you update github instruction with this tip? It only mentions ./configure CFLAGS="-O3" in *nix build instructions and readme as well. No point if -DASM is used. -O3 unrolls all loops possible resulting in larger executable size which may affect performance either way. -Ofast enables -ffast-math additionally which is a set of non-conformant tweaks making no effect because CPUminer doesn't use floating point for hashing. The following shows all optimisations enabled for -O3: gcc -c -Q -O3 --help=optimizers | grep enabled
This is the difference between -Ofast and -O3 in case of GCC 4.7: -fcx-limited-range [enabled]
-ffinite-math-only [enabled]
-fmath-errno [disabled]
-fsigned-zeros [disabled]
-ftrapping-math [disabled]
-funsafe-math-optimizations [enabled]
I'll update the documentation on GitHub later. |
|
|
|
I have just compiled the CPU miner.
My FX-6300 gives 1.9 kh/s per thread = 11.4 kH total.
I am curious of other desktop CPUs.
Could some people post their results?
Intel® Core™2 Duo processor P8600 (2.4GHz, 3MB L2, 1066MHz FSB, 25watt) on Lenovo T500 notebook hashes at ~ 1.5 khash per core using Win 64-bit wallet built-in miner. Not really worth it so I'm not mining PXC. Pentium 4 3.4GHz can do 1.4KH/s which is hardly worth the power consumed (100W+). Core 2 Duo is a not bad hasher, but notebooks are crappy miners in general due to weak cooling unless you edit ACPI P-states to reduce voltage or clock speed at least. |
|
|
|
at least one miner is GPU mining as of 1 hour ago, total hash increasing with ~800KH/s increments which suggests GPU.
but no GPU miner software is yet public.
Nope, there are people with large CPU farms like his one delivering 450KH/s. There are also botnets. |
|
|
|
|
Show Posts
