|
Infinium: Could we have some more info about you / your development work history? The more info you give people, the more buy-in you will get. Also get more dev's on-board.. 1 person running the show isn't really promising (no offence)..
|
|
|
|
Unfortunately Dashcoin is kind of dead.  You couldn't be more wrong my child ! For it is the will of THE GODS that this coin makes it to the exchange. As it is predicted in the testaments : One shall mine shitloads of this coin, for it has not been pre-mined like Bytecoin, and ye of little faith shalt be stricken by the almighty Cryptogods! .... or something like that  Someone with a great sense of humour.. I love it  |
|
|
|
Unfortunately Dashcoin is kind of dead. |
|
|
|
|
How about creating the first cryptonote multipool? That would get a considerable amount of users flocking to ghash.io
|
|
|
|
@Dev is this Coin Still mineable?  it is indeed still mineable, we have a tradeing thread atm... just waiting on an exchange... hitbtc please :/ |
|
|
|
|
What is the roadmap to get more coins onto HitBTC?
I much prefer the feel of HitBTC than Poloniex but Poloniex covers such a large number of coins that it makes sense to keep using them?
MonetaVerde / Dashcoin / Aeon coin would be a great start..
|
|
|
|
Anyone have any ideal performance/cost CPU desktop/server builds for XMR?
Thinking about buy a new single/dual CPU setup for this + gaming rig and GPU mine also.
AMD has some cheap setups, but don't want to waste money, but I also want to buy something on newegg with BTC....though the 10% discount expired I think =(
I'm uncertain of the CPU side (cost vs performance). GPU wise, merged mining (XMR+FCN) on a GeForce GTX 750 Ti hits 220->250 h/s. (can probably get more if its just dedicated to that as I'm running it inside of Linux as a desktop) At the moment its the fastest GPU per watt of power used and its relatively cheap. |
|
|
|
Ok, well I guess every day I have is a "bad day" compared to the world you live in where six figures USD worth of hardware is at your disposal and you nonchalantly work them like rented mules mining XMR like it's going out of style. Kick a brother down a Xeon server or two. will ya? It's more in the region of 7 figures USD worth of hardware. At the moment I'm just playing around on the portion of the development cluster. Need to make sure things are running optimally before XMR mining is moved to production. I'm responsible that way  |
|
|
|
Curl 7.31.1 compiled with :
./configure --disable-shared --enable-static --prefix=/usr/local --disable-ldap --disable-sspi
make -j 4;make install;
miner still errors out:
./autogen.sh
./configure CFLAGS="-static'
checking for the version of libcurl... 7.37.1
checking for libcurl >= version 7.15.2... yes
checking whether libcurl is usable... no
configure: error: Missing required libcurl >= 7.15.2
Any ideas ?
./configure is looking at curl prefix in /usr (depending on the distro). You might want configure curl like: ./configure --disable-shared --enable-static --prefix=/tmp/curl --disable-ldap --disable-sspi make ; make install then the miner: ./autogen.sh ./configure CFLAGS="-static' --with-libcurl=/tmp/curl make |
|
|
|
really, because 10,000/528 = ~19. 19 is a "few machines?"
edit: and that diff is pathetically low. 444 is for a pentium 2 or someshit.
Yes, 19 is a "few machines". There are plenty more to use across different pools / coins. Difficulty is assigned by the network and will scale up and down. 444 is the starting difficulty for that pool and its gotten considerably higher now. Lighten up, you sound like you're having a bad day |
|
|
|
Why does it automatically set thread count to ~cpu count?
Using your formula:
[2014-08-03 13:19:33] accepted: 12/12 (100.00%), 514.93 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:34] accepted: 13/13 (100.00%), 513.02 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:35] accepted: 14/14 (100.00%), 528.15 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:35] accepted: 15/15 (100.00%), 525.17 H/s at diff 444 (yay!!!)
Perhaps this should be added to the original post? Its a BIG improvement.
To answer my own question, it appears as though the improvement is noticed only when the server has a large number of cpus / cache etc. Older machines seem to perform better with a larger amount of threads, even when cpu count is lower. I'm breaking > 10 000 H/s without even breaking a sweat across a few machines. Thank you |
|
|
|
Don't set threads equal to number of CPU threads, that is wrong.
The general rule is threads = floor(L3 cache / 1024)
Use this: num_threads=$(($(cat /proc/cpuinfo | grep "cache size" | uniq | cut -d":" -f2 | cut -d" " -f2)/1024))
Should be 12 for X5650
You sir, are a legend. Why does it automatically set thread count to ~cpu count? Using your formula: [2014-08-03 13:19:33] accepted: 12/12 (100.00%), 514.93 H/s at diff 444 (yay!!!) [2014-08-03 13:19:34] accepted: 13/13 (100.00%), 513.02 H/s at diff 444 (yay!!!) [2014-08-03 13:19:35] accepted: 14/14 (100.00%), 528.15 H/s at diff 444 (yay!!!) [2014-08-03 13:19:35] accepted: 15/15 (100.00%), 525.17 H/s at diff 444 (yay!!!) Perhaps this should be added to the original post? Its a BIG improvement. Thanks! (Now to deploy this on a motherload of machines :/) |
|
|
|
You should be getting atleast 400 H/s out of those CPUs (mine are hashing at 451 H/s)
How though? I've tried on a variety of *very expensive* hardware from Dell. Each has 100gigs of ram, 24 cpus, etc.. Ubuntu 14.04: # sysctl -w vm.nr_hugepages=72 (confirmed that it is set) # git clone https://github.com/wolf9466/cpuminer-multi.git# cd cpuminer-multi # ./autogen.sh # ./configure CFLAGS="-march=native" # make # make install # screen -d -m -S minerd /usr/local/bin/minerd -o stratum+tcp://mro.pool.minergate.com:45560 -p x -u x # screen -r (after a few hours of running) [2014-08-03 06:05:25] accepted: 3952/7916 (49.92%), 288.94 H/s at diff 444 (yay!!!) example of hardware: 24 CPUs - Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz another example: 24 CPUs - Intel(R) Xeon(R) CPU X5650 @ 2.67GHz |
|
|
|
|
One thing I found rather interesting:
root@cami001:/# minerd --help
..
-t, --threads=N number of miner threads (default: number of processors)
..
root@cami001:/# grep processor /proc/cpuinfo | wc -l
24
root@cami001:/# /usr/local/bin/minerd -o stratum+tcp://x.x.x.x:x -p x -u xx
[2014-08-02 15:49:42] Using JSON-RPC 2.0
[2014-08-02 15:49:42] 31 miner threads started, using 'cryptonight' algorithm.
[2014-08-02 15:49:42] Starting Stratum on stratum+tcp://x.x.x.x:x
Out of interests sake, how/where is 31 processors being returned? If I set the thread count manually (-t 24), 24 threads are used and the H/S is extremely consistent.
|
|
|
|
Each optimization I tested worked on my CPU - I don't have all CPUs, so I can't test. That much of a reduction is odd, though... are you sure the test wasn't affected by other factors?
It's quite a difference. I have 8 of those monster servers that are freshly installed (+updated) with Ubuntu 14.04. They are all identical and unused (no running services, crons etc..) but the results are rather inconsistent across each so perhaps something else could be influencing things. I'll dig a bit deeper and see if anything comes of it. |
|
|
|
|
Btw.. Just thought i'd mention this:
Latest CPUMiner compiled from git: (24 x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)
Over a 20 minute duration:
[2014-08-02 20:25:25] accepted: 191/234 (81.62%), 230.74 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 192/235 (81.70%), 230.63 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 193/236 (81.78%), 230.61 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:31] accepted: 194/237 (81.86%), 230.16 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:40] accepted: 195/238 (81.93%), 231.01 H/s at diff 980 (yay!!!)
Then i removed all of the "optimizations" from the Makefile:
From:
am__append_3 = -Ofast -flto -fuse-linker-plugin -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerg
e-all-constants -fbranch-target-load-optimize2 -fsched2-use-superblocks -maes
to :
am__append_3 = -maes
The result?
[2014-08-02 20:26:44] accepted: 189/231 (81.82%), 289.83 H/s at diff 1384 (yay!!!)
[2014-08-02 20:26:45] accepted: 190/232 (81.90%), 290.09 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:03] accepted: 191/233 (81.97%), 291.41 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:07] accepted: 192/234 (82.05%), 290.47 H/s at diff 1384 (yay!!!)
There are numerous posts/warnings on-line about over-aggressive compile-time "optimizations".
Just thought I'd post my results/findings which concur.
Regards,
Cami
|
|
|
|
|
Show Posts
