Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - noobster

Pages: [1] 2 3
1
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 19, 2014, 11:24:05 am »
Quote from: mmao on January 19, 2014, 08:45:25 am
Quote from: dga on January 18, 2014, 02:09:30 pm
Quote from: mmao on January 18, 2014, 02:03:51 pm
it's a centos6 box
Code: [Select]
%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

Ow.  gcc doesnt support avx2 until somewhere in the 4.7 release.  Best suggestion for now is to try the static avxsse binary - does it work for you?

Or if you're on an avx2 machine, upgrade. :-)

Next best is that it's getting higher on the TODO to make it easy to disable avx2 building.

I installed gcc4.7.2 but got the same errors,
I met exactly the same problem when compiling girino's opencl miner,
what version of gcc do you use?

try upgrading your entire system, gcc might not be enough since it uses libraries such as libstdc++ and more

2
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 18, 2014, 08:46:08 pm »
is a new sse4 version going to be available?

i get

core 2 duo t8100 @ [STATS] 2014-Jan-18 21:44:54 | 60.6 c/m | 1.0 sh/m | VL: 502 (83.8%), RJ: 97 (16.2%), ST: 0 (0.0%)

core i3 380um @ [STATS] 2014-Jan-18 21:43:03 | 47.2 c/m | 0.7 sh/m | VL: 409 (85.9%), RJ: 67 (14.1%), ST: 0 (0.0%)

damn i wish I had faster cpu
thanks

3
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 18, 2014, 11:31:34 am »
I wanted more ram options so I can experiment a bit with different settings. Say from 512 to 2048 MB per thread adjustable by 256MB… no idea this could take a lot of work maybe.

And you were right about the rejects, beta4 update increased the reject rate to over 30% in my case lol

4
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 18, 2014, 09:52:02 am »
with the pool fee the 3% miner fee is preety high together

also it would be nice if one can specify the amount of ram per thread

thanks

5
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 17, 2014, 03:28:33 pm »
the static bin does not work for me as well i am using non avx cpu (1st gen. core i3)
I get
Code: [Select]
Illegal instruction

6
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 17, 2014, 11:54:18 am »
anyway I did notice one thing, why using so many hugepages if the miner @ 4 threads only uses 4 hugepages:

Code: [Select]
# cat /proc/meminfo |grep -i hugepages
AnonHugePages:         0 kB
HugePages_Total:     512
HugePages_Free:      508
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
perhaps
Code: [Select]
echo 4 > /proc/sys/vm/nr_hugepagescould be enough? more than that i would consider waste of memory, or may it use more hugepages over time?

ps. still getting this:
Code: [Select]
Could not mmap hugepage, reverting to malloc: Cannot allocate memoryeven after I recompiled my kernel with
Code: [Select]
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
thanks

7
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 17, 2014, 08:56:33 am »
Quote from: dga on January 17, 2014, 02:17:07 am
Slight update:  There's now a beta3 that tries to reduce rejects a bit

http://www.cs.cmu.edu/~dga/ptsminer/

The miner works by processing an entire block of 2^26 hashes at once, and so if new work came in, it would still submit anything found in the previous block.  This could lead to excessive numbers of rejects (and thus, a disconnection).  Beta3 tries a little harder to avoid this - and the wasted work it entails - and also bumps up the number of rejects before reconnecting a bit for safety.

There are some small speed tuning-related changes, but probably not anything measurably different.  I'm still seeing in the 450-475 range on i7-4770.   The reconnect changes I just made + the beta2 dev mining changes should make it a lot easier for people to get longer-running performance measurements out of this code.

I've figured out several of these changes that should help improve performance on non-avx2 systems.  Once I get to that phase, if there's interest in beta testing a linux avx build for sandybridge/ivybridge, I can do that too.  Perhaps one optimized for Amazon's machines?  *grin*

Code: [Select]
$ ptsminer-dga-beta3-avx2-linux64.bin PkzbnN7Nkv6TcqJuNjpcLfmPqpPUphpu5W 2 sse4
ptsminer-dga-beta3-avx2-linux64.bin: error while loading shared libraries: libboost_system.so.1.53.0: cannot open shared object file: No such file or directory
I have gentoo linux and using repository libs boost 1.52 the binary you provided is compiled against boost 1.53 thanks

8
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 16, 2014, 06:08:48 pm »
yea, i did that already but thanks anyway :D

and I'm getting this now:
Code: [Select]
Could not mmap hugepage, reverting to malloc: Cannot allocate memory


btw is there any way to reduce memory usage to say 512 or 768 MB per thread?

9
BitShares PTS / Re: Open source optimized PTS CPU miner (BETA)
« on: January 16, 2014, 05:29:36 pm »
Code: [Select]
Couldn't use the hugepage speed optimization.  Enable huge pages for a slight speed boost.
kernel config:
Code: [Select]
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
Code: [Select]
$ cat /proc/meminfo | grep HugePages
AnonHugePages:     14336 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
followed https://wiki.archlinux.org/index.php/KVM#Enabling_huge_pages

What am I missing here?

10
BitShares PTS / Re: [ANN] ptsweb.beeeeer.org - Protoshares mining sub-pool
« on: January 15, 2014, 06:59:04 pm »
so with all these cpu and gpu miners, are we getting any blocks today?  :D

11
BitShares PTS / Re: [ANN] ptsweb.beeeeer.org - Protoshares mining sub-pool
« on: January 11, 2014, 05:35:00 pm »
is it somehow possible to modify the miner source to assign 768M of memory per thread?

i have searched through the code and found a snippet:
Code: [Select]
        void mineloop_start() {
                switch (COLLISION_TABLE_BITS) {
                        case 20: mineloop<(1<<20),(0xFFFFFFFF<<(32-(32-20))),shamode>(); break;
                        case 21: mineloop<(1<<21),(0xFFFFFFFF<<(32-(32-21))),shamode>(); break;
                        case 22: mineloop<(1<<22),(0xFFFFFFFF<<(32-(32-22))),shamode>(); break;
                        case 23: mineloop<(1<<23),(0xFFFFFFFF<<(32-(32-23))),shamode>(); break;
                        case 24: mineloop<(1<<24),(0xFFFFFFFF<<(32-(32-24))),shamode>(); break;
                        case 25: mineloop<(1<<25),(0xFFFFFFFF<<(32-(32-25))),shamode>(); break;
                        case 26: mineloop<(1<<26),(0xFFFFFFFF<<(32-(32-26))),shamode>(); break;
                        case 27: mineloop<(1<<27),(0xFFFFFFFF<<(32-(32-27))),shamode>(); break;
                        case 28: mineloop<(1<<28),(0xFFFFFFFF<<(32-(32-28))),shamode>(); break;
                        case 29: mineloop<(1<<29),(0xFFFFFFFF<<(32-(32-29))),shamode>(); break;
                        case 30: mineloop<(1<<30),(0xFFFFFFFF<<(32-(32-30))),shamode>(); break;
                        default: break;
                }
        }
any way to modify this list to contain 768M per thread?

12
BitShares PTS / Re: [ANN] ptsweb.beeeeer.org - Protoshares mining sub-pool
« on: January 11, 2014, 12:12:50 pm »
any progress on fixing current reject rate?

13
BitShares PTS / Re: best set up for mining?
« on: January 10, 2014, 09:17:13 am »
the intel cpus are known to be more energy efficient over amd

however i would wait with cpu rig since we have new gpu miners released at least until we can confirm it's efficiency and reliability

14
BitShares PTS / Re: [ANN] ptsweb.beeeeer.org - Protoshares mining sub-pool
« on: January 09, 2014, 10:29:08 am »
Quote from: jabbaah on January 08, 2014, 12:28:37 pm
Quote from: noobster on January 08, 2014, 11:38:57 am
Quote from: jabbaah on January 08, 2014, 11:25:52 am
Quote from: noobster on January 08, 2014, 11:12:42 am
also for fellow miners i did notice one thing:

i have 4 core cpu and 4 gig mem and I get better results if I fire up more threads @ 512M (say like 7 gives 3,5GB) than only four (given 4 threads on cpu)

conlusion: use more threads to fill up unused memory

waiting for your thoughts on that =)

That's intended. The more CPU power you put into mining, the higher the output. Configuring more RAM per CPU core only gives an advantage if you have very fast RAM in your machine. Testing this out is up to you. Anyway the difference is only very small. The big difference is the number of cores like you correctly stated already.

But the quad multicore cpu can handle more threads without any problem. My thought was not to provide more ram per thread, instead fire up more threads to fill up unused memory.

thanks

Ah, sorry. My fault. I should read an article more carefully before hitting the reply button. ;-)

That's indeed interesting. One should think that 4 threads on a 4 core cpu is 100% load and cannot be more increased.

Is there is significant difference? How much collisions/minute is the difference (4 threads / 7 threads)?

the difference is small with low-end ultra low voltage core i3-380UM i get:
@4 threads/512M about 20c/m
@7 threads/512M about 23c/m

not sure how this would impact high-end hardware

15
BitShares PTS / Re: Re-Open ★Giveaway I★ Claim your free PTS - after 20 posts in forum
« on: January 08, 2014, 11:40:03 am »
PkzbnN7Nkv6TcqJuNjpcLfmPqpPUphpu5W

thanks =)

Pages: [1] 2 3

Page created in 0.035 seconds with 23 queries.