beta9 for AVX2 is now online in the usual place:  http://www.cs.cmu.edu/~dga/ptsminer/

This is a speed-boost release.  I'm still doing the benchmarking runs, but on my i7-4770, it's the first of my releases to crack 600 cpm.  Looks like it's going to settle in between 610 and 620 cpm with 7 threads running on my test box.

beta9 is haswell-only right now;  its optimizations are specific to avx2.  I plan to address some of the portability/pool selection issues soon (because I'm running out of great ideas for how to make this thing faster without getting ugly).

Hi dga,

After 3 or 4 days, the v8 avx slow down from 320 to 260 cpm.
v8 avx2 not sure since run as daemon, but profit seems drop to 75%。

kill the ptsminer and restart seems fix it.

I'm not sure what's happening, since the yam get a lot of reject from beeeeer.org too.

yam on 1GH has no problem using new xpt2h protocol and port 18120.

Now ptsminer is beeeeer.org lock-in.

Any plan to support xpt2h protocol?

I haven't seen avx2 slow down, but beeeeer has had a bad string of luck lately with block finding - my profit is also down a fair bit. 

My own avx beta8 client hasn't slowed down:

2014-Jan-25 17:00:19 | 760.0 c/m | 14.1 sh/m
2014-Jan-30 06:00:07 | 774.9 c/m | 12.2 sh/m

but that doesn't mean there's not something wrong.  What CPU are you running the avx one on and with how many threads?

I do hope to add more protocol support.  I have real work taking up all of my time until this weekend, but I'll check out xpt2h then.

  -Dave

I've placed beta8 for haswell/avx2 and now for avxsse online.  It fixes (I believe) the bug that was causing failures when not enough hugepages were available, and incorporates the latest round of speed improvements for Haswell/AVX2.  Speed isn't changed much for avxsse, but I'm narrowing in on some more general improvements that should help there too.

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

This is a quite worthwhile upgrade for the Haswell/AVX2 crowd.  Expect at least a 20cpm jump and probably more - I'm still letting the cpm benchmarks run, but my dev benchmarks suggest somewhere between a 5-10% speedup over beta7.  I'll update this post tonight with some actual CPM numbers from an i7-4770.

Update 2:
Totally rough guesstimate:

[STATS] 2014-Jan-25 17:34:57 | 570.1 c/m | 8.9 sh/m | VL: 299 (99.7%), RJ: 1 (0.3%), ST: 0 (0.0%)

I expect sustained rates of 565 c/m over a longer period of time.  Not bad, little CPU, not bad.

  -Dave

Hm.  What happens if you run with only 1 thread?

What happens if you first run, as root:
   echo 2048 > /proc/sys/vm/nr_hugepages

and then run with only one thread?

If it works with 1 thread, does it also work with 2?

  -Dave

I downloaded the beta7.1 static binary, and run it on my centos6 box but failed:

Code: [Select]

using SSE4
spawning 4 worker thread(s)
[WORKER[WORKER[WORKER2] starting
3] starting
1] starting
[WORKER0] starting
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
[WORKER1] GoGoGo!
[WORKER2] GoGoGo!
[WORKER0] GoGoGo!
[WORKER3] GoGoGo!
connecting to 54.201.26.128:1337
Mining for approx 60 seconds to support further development
Payments to: Pr8cnhz5eDsUegBZD4VZmGDARcKaozWbBc
[MASTER] work received - sharetarget: 03ffffffffffffffffffffffffffffffffffffffffffffffffffffffbeefde4d
ptsminer-dga-beta7.1-avxsse-linux64-static.bin: malloc.c:2369: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t)) < __alignof__ (long double) ? __alignof__ (long double) : 2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)) < __alignof__ (long double) ? __alignof__ (long double) : 2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
aborted (core dumped)
it failed also with sph mode:

Code: [Select]

using SPHLIB
spawning 4 worker thread(s)
[WORKER[WORKER12[WORKER] starting] starting

3] starting
[WORKER0] starting
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for big table.  Enable huge pages for a slight speed boost.
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
Couldn't use the hugepage speed optimization for small table.  Enable huge pages for a slight speed boost
[WORKER2] GoGoGo!
[WORKER3] GoGoGo!
[WORKER0] GoGoGo!
[WORKER1] GoGoGo!
connecting to 54.201.26.128:1337
Mining for approx 60 seconds to support further development
Payments to: Pr8cnhz5eDsUegBZD4VZmGDARcKaozWbBc
[MASTER] work received - sharetarget: 03ffffffffffffffffffffffffffffffffffffffffffffffffffffffbeefde4d
Segmentation fault (core dumped)

using same Internet connecion, my ivybridge (avx sse beta7) RJ is higher than haswell (avx2 beta7).

Now on several machine, VL 1013 and avxsse 14.3% : avx2 0.1%.

Ok, replying to a few of these:
 - I've put beta 7.1 online just for avxsse.  I've let a few small tweaks from what will be beta8 slip in, but it's basically the same as beta7 from a performance perspective.
 Changes:
    - It should improve the reject rate.  It's a bit more aggressive about checking for updates now without slowing down mining. (ptsrush)
    - Better handling of and diagnostic messages for out-of-memory / allocation errors. (dclark)

Update:  After about an hour of testing on a 64 core AMD machine:

    789.7 c/m | 12.3 sh/m | VL: 623 (99.7%), RJ: 2 (0.3%), ST: 0 (0.0%)

Looks like this one successfully pulls the submitted rejects down for avxsse also, though an hour isn't quite long enough to say what the overall reject rate will be.

Update 2:  After a day (the c/m and sh/m got reset but VL/RJ didn't):
    758.6 c/m | 12.0 sh/m | VL: 16570 (98.6%), RJ: 228 (1.4%), ST: 0 (0.0%)

Looks solid on rejects.

RJ is reject, ST is stale, VL is valid. 

I'm pondering the open-sourceness.  In the case of GPU, I'm happy - Invictus paid for the release.  Now that I'm doing unpaid improvements to the CPU miner, I want to see how it plays out - but I'm increasingly leaning towards keeping at least some of the cutting edge private as a way to get a bit of return on development time, and trying to keep the open source version updated at a reasonable level that lags a bit behind the latest and greatest but is still a good basis for people who want to learn / explore / improve.  It's a tough question.

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

Yes.  beta7 is now online for both avx2 and sse/avx. 

There aren't major changes from beta6 for avx2 users;  if you're running really happily, I wouldn't bother upgrading.  The changes are mostly internal to trying to make it easier to build, and to make available the reject-reducing improvements for SSE and AMD CPUs.  It should be even more aggressive for slower CPUs, but it's quite a bit better than it was.  Note:  You may still see a batch of rejects at the very start when the miner switches out of dev-mining mode for the first time.  Just depends on where things were when it switches.

One note:  More individually slower cores will result in a higher reject rate.  I'm seeing this, for example, if I push the hyperthreading too hard, and on AMD CPUs, which have more cores but no hyperthreading, with each core a bit slower.  Not horrible, but something you'll notice.

Updated:  I've also put the Mac build online for beta7, and tried to improve the static-ness of this one so it should be easier to run.  This also meets a second personal goal of mine:  It's now about as fast to mine with the CPU on the Macbook Pro than it is to use the GPU with cudapts.  Take that, cudapts!  It's about time to put the GPU-hardness back in Protoshares.  <grin>  (It does, however, make the fans spin more.)  I'm getting about 200 cpm using 4 threads on MBP, which is pretty close to GPU.  I don't recommend mining on a laptop, though, unless you don't like your laptop.

I'm not native speaker, but maybe in such case guess I should say it's "damn fast"!

Anyway, once a new block start, seems all my 6 worker print "Aborting scan run because of new work."

It's is a little annoying. Could you output them only 1 time?

And sometime it says "Not inserted: <298324783427234980742398> at 7744". Is it OK?

The RJ is about 5% in China. I'm not sure is due to broken internet or something else.

Thanks for these bug reports.  I've fixed both and pushed beta6 for haswell/avx2.

My benchmark hasn't been running long enough to really stabilize, but...

Beta5:   546.7 c/m | 8.7 sh/m | VL: 3937 (97.8%), RJ: 90 (2.2%), ST: 0 (0.0%)

Beta6:   543.0 c/m | 8.7 sh/m | VL: 142 (100.0%), RJ: 0 (0.0%), ST: 0 (0.0%)

I wouldn't read too much into the c/m and sh/m differences - it hasn't been running long enough - but the reject rate is reduced substantially.  The speed should be within 10c/m plus or minus once it's been running long enough to tell.

With more data:  540.2 c/m | 7.8 sh/m | VL: 1219 (99.5%), RJ: 6 (0.5%), ST: 0 (0.0%)

Much better reject rate with beta6.
  -Dave