Topic: [XPM]unofficial jhPrimeminer thread - page 38. (Read 180246 times)

yup, 2 xeons with hyperthreading

and since that post

Nice results. Which miner are you using on solo?

Are those Xeons your using?

Well, using identical settings on V4 and V5 and 4 days of testing V4 wins in terms of XPM/day (V4 day 1: 12.96, V5 day 2: 9.05, V5 day 3: 9.43, V4 day 4: 10.86)  V5 wins in terms of difficulty: 2 blocks found in 2 days vs 1 in 3 days.  So, as it stands, virtual tossup, but I give the win to V4.

1 day on pool = 12XPM (24 CPU threads, 60GB RAM)
1 day on solo mining = 34XPM (8 threads, 60GB RAM)

make your conclusions

btw I'm doing both at the same time (32 cores in total), so one complements the other

in 2 hours:

Does anyone have any idea how the pool miners currently compare to solo mining (assuming using a large enough number of machines to make the test fare)?  The HP solo miner was at one stage considerably better than the pool miner, but don't know whether that is still the case or not. 

I've been testing v4 and v5 on a Win7 64 i7 950 (4 core) and a Ubuntu 64 Opteron 365 (8 core) under wine.

The Win7 on v5 appears to be running OK with similar(ish) results to v4, although it is very difficult to compare the two.

However, the Ubuntu on v5 produces hardly any shares at all and nothing in the 7 ch/h. I tried -s from 200,000 all the way up to 5 million with even worse results. I'm back to v4 on Ubuntu and currently running at 14 Val/h.

The Win 7 on v5 is showing about 4 Val/h default settings.

Can I directly compare Val/h between v4 and v5?

Keep up the great work on this !!!!!!

Is it possible to add getwork support?

Mumus' build works significatly faster than the native client (and even hp client) for me but it's not good for the network to accumulate power at a single pool. I'd rather run it with my local primecoin node.

This is a great idea. Btw just wanted to say mumus that all your work is much appreciated and all the people you've helped won't forget your good name. Might I suggest people donate for all his hard work so far?

Thanks! Good idea! I already thought about logging to a csv and I will start implementing it.

mumus, how about trying to collect data on certain CPU's automatically, like, have the miner detect the cpu type (EX: i5 3570k) and collect enough information (for example if 100 people were to use an i5 3570k to mine primecoins, after you collect data from them, you can find out the best settings using that data and either relay the results to everyone, or have the miner automatically adjust to the best settings every xx blocks?)

Hi to the programmers (or anybody else who can help)

I am trying to build the miners ( all versions) and get the consistant error, when building)  as follows.

1>prime2.obj : error LNK2001: unresolved external symbol ___gmpz_mul
..
...
..

etc (25 errors total)

All seem to be about the MPIR libraries

I can not find the gmpz_mul but only the mpz_mul, which is in the mpirI.h file. I alos cna not find any reference to the variables.

Is there some setup I must do or which I have omitted with the mpir library?

When I set the verbose flag on it says the following

1>  Unused libraries:
1>    lib\openssl\ssleay32MT.lib
1>    lib\mpir\mpirxx.lib
1>    lib\mpir\mpir.lib
..
..

Please help. I am a fair noob on this, but I would like to learn. (BTW I have googled)


Followup:

I think I found it. The project must be compiled in X64 but the project was set to default Win32. Builds and compiles now, however, what mpri libraries are now win32 and which are x64? Why cant mpri libraries be simpler and standard provided? A hell of a lot of forced changes by compiler ... makes things suspicious... Maybe some more refinements?

You're right. In V4 the calculation for the Val/h used the old formula which gave higher value for lower difficulty shares, and the counting of the 6,7,8 chains was different where I increased the counter of the lower chains when I found a higher one. I mean for example when a 8 length chain was found also the 6 and 7 counters were increased. I also introduced in v4 some kind of rescanning feature (I thought this will increase the chances to find  a share) which had a bug resulting an increased value in the 5+ chain counters.
So in V4 these problems were fixed, and as a result the numbers are lower. After all when comparing what matters is the earned XPM/day, using the same settings and same machines with both version. Personally I don't have the resource and the patience to do these kind of long running tests. I always have a new idea the I have to try.

With higher sieve size (-s) and higher sieve percentage (-d)  there is a higher chance to get longer chain but if they are to high then the test/s (PPS) are lower so this means less chance. The secret is to find the balance which differs for each environment. But this can be done just using longer test periods. (because the nature of randomness to get longer chains). I'm also trying to find a way to automatically balance every parameter but there are too many, each affecting the performance in a little bit different way.

is there any way to "prefer" 7 chain and up instead of tiny 6 chain values?

  Rough tests:

Baseline C2Q(40 hours):
11.5kPPS, 60SPH, 4.3VPH, 235-5ch/h, 17-6ch/h, 1.5-7ch/h

-s 200000 C2Q(1 hour):
15.9kpps, 44SPH, 2.3VPH, 140-5ch/h, 14.6-6ch/h, 0-7ch/h

-s 400000 C2Q(1 hour):
14.3kPPS, 65SPH, 2.9VPH, 270-5ch/h, 17.5 6ch/h, 0-7ch/h

-s 600000 C2Q(1 hour):
13.1kPPS, 49SPH, 2.6VPH, 232-5ch/h, 6.33-6ch/h, 1.27-7ch/h

Used mumus' V4 on a fairly matched pair of C2Q Q6600's.  Looks like luck plays a huge part, longer tests needed.

Initial analysis: More PPS, mostly less SPH, less VPH.

I'm gonna try it...doesn't matter if you get lower pps vs 8% and 1500000, right?

You are probably right in the lost cause area, but, he's correct, he found a block through the pool.  The majority his whining centers on July 13/14 when he 'mined' 9 orphans.

From his statements, he must have been mining on V0.1.0 as he states he upgraded the client (V0.1.1 came out July 13th, so he didn't upgrade right away) and they all 'disappeared'

7857 blocks were mined on the 13th, 6918 on the 14th.  So, ~6x the normal rate.  With all the bot nets, I'd bet there were tons of orphaned blocks, especially if someone was running an out of date i3.

What I find most hilarious though is the fact that I told him ~6 days ago to use ypool and either cabin's or mumus' build, but he kept whining for days before finally switching and now is bragging over his find.

In addition, he keeps referring to $300 lost.  If he had mined them on the 13th or 14th, he would have had them in hand no later than the 15th.  The XPM value at the beginning of the 15th was .0021 and climbed to .0043 before starting to fall to .0034.  This greedy schmuck would have sold right then and there thinking it was headed back to .0021.  But his $300 claim would have come from the 19th when the price spiked .017 briefly before falling.  Hindsight is 20/20 but he wants you to think he'd have been smart enough to sell at the peak (when he's not even smart enough to understand what an orphaned block is).

So, yea, maybe he's a lost cause, but sometimes you have to rub the puppy's nose in it's shit for it to understand.

what is the best configuration for 64GB of RAM and 32 cores?

I'm using -s 2000000 -d 15 but it doesn't seem to be finding more shares than usual (at 88k PPS)

Please do, he's a greedy fool. Looks like he's confusing blocks with shares at this point...

My XPM earned per day was higher (w/v4 before and after v5 test) and that's the stat I pay the most attention to.

The actual valid shares were lower (than reported in the stats on v4, but still higher than v5), you are correct, but 7ch & 8ch counts were observably much higher in rate under v4 on my rig and reflected in earned XPM during the v4 runs.

Again, this is simply my personal experience on my rig, ymmv.