I'm getting what looks to be the same issue as mich, I'm on Debian 6: name@hostname:~$ ./phoenix.cfg
Traceback (most recent call last):
File "/usr/local/bin/phoenix", line 8, in <module>
load_entry_point('phoenix==2.0.0-rc1', 'console_scripts', 'phoenix')()
File "build/bdist.linux-i686/egg/pkg_resources.py", line 318, in load_entry_point
def has_metadata(name):
File "build/bdist.linux-i686/egg/pkg_resources.py", line 2221, in load_entry_point
def __getattr__(self,attr):
File "build/bdist.linux-i686/egg/pkg_resources.py", line 1954, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named phoenix I'll have CFSworks take a look at this later. In the mean time you can use phoenix by starting phoenix.py instead of executing the config file. |
|
|
|
|
The current code in Git has been updated with a few fixes:
1. Hashrate display should be working correctly now. Please report back if it still doesn't work.
2. Updated opencl and phatk2 to use Diapolo's method of detecting if the device is a CPU.
3. Autodetect messages will no longer appear for devices which have a config manually defined.
The Windows binary has also been updated with these changes.
|
|
|
|
Above config generates "Detected [cl:0:0]: [Tahiti 0] using opencl (rating 2)", which I don't understand. Shouldn't it simply use the kernel specified and tell that autodetect had been overridden by own settings.
That's because you still have autodetect = +cl in the config file. Any devices with specific settings defined in the config file will use those instead of autodetect. The autodetect messages are currently displayed even if the settings are overridden by the config file. This will be clarified in a future release by either hiding the autodetect message or changing the message to indicate that the user-defined settings were used. Another thing I don't understand is, why getDevice() and autodetect() reside in kernels\opencl\__init__.py I dislike the idea, that these functions are derived from there, because opencl is simply another kernel folder. I think they should be placed somewhere else (have no good idea currently, but perhaps in PhoenixCore.py).
The reason we have the device detection code at the kernel level is so that it can support any type of device. For example, the current FPGA miners don't have a standard API, which makes including this functionality in the Phoenix core a bad idea. We would have to add support for new devices into the Phoenix core. By doing these functions at the kernel level, it allows other developers to support new hardware with no changes to Phoenix itself. The supplied phatk2 version uses stuff in opencl\__init__.py, too via "opencl = sys.modules['opencl']", which seems sort of not ideal. I think every kernel should specify his own options and stuff, even if they are the same. Your idea was perhaps to edit only one place, if you add new changes, but for addon kernels like diakgcn I really have to specify my own options, which I would promote as a rule for all supplied or addon kernels to be better structured and to be independend of the opencl kernel folder. What do you think?
Using functions from opencl for other kernels isn't required. This is simply how we decided to implement the supplied version of phatk2. Kernels DO NOT need to be implemented in this way. Another small change I would suggest for analyzeDevice() is your CPU detection code, which could be replaced with: # Check if the device is a CPU
if device.get_info(cl.device_info.TYPE) == cl.device_type.CPU:
return (1, {'name': name, 'aggression': 0}, [devid, 'cpu:0']) Thanks for this code, I will modify opencl/phatk2 to use this method of detecting CPUs. |
|
|
|
Got DiaKGCN working ^^, will be released in the next 2 days! One thing, hashrate display seems a bit crazy currently ... starts at 5 GHash/s and takes forever to reach normal levels, where it belongs. Perhaps this can be reworked!? Oh, and I think BFI_INT whitelist should reside in the kernels init file and not be placed somewhere else  . PyOpenCL is still 0.92 are there any news in terms of higher AGGRESSION levels and getwork delays? Edit: CPU utilisation looks way better, than with Phoenix 1.X! Dia I think I know what's causing the hashrate display to initially show a huge value. I will fix this later today. The reason we decided to put the BFI_INT whitelist in BFIPatcher.py was so that it wouldn't need to be duplicated across all kernels. This also makes it simpler to update since we only need to change it in one place. Kernels can still include their own whitelist if they want. I will retest the newer PyOpenCL versions, but I highly doubt there will be any differences from previous tests. |
|
|
|
Update: Phoenix 2.0.0 beta corrects the unknown-work problem on slower hardware. The work queue in Phoenix 2 is aware of work age and will discard any work that is too old. You can get the beta here: https://bitcointalk.org/index.php?topic=62765.0 |
|
|
|
I want to use this miner.
How do I install it on an Ubunut 11.10 32bit system with one 5850?
I could not found any installation advice, readme or howto.
Thank you ...
In general this is what you will need to do: 1. Install drivers + APP SDK There are many guides for this around, so I won't go into the details here. In general SDK versions 2.1, 2.4, 2.5 are good, and 2.2, 2.3, 2.6 are bad. 2. Install prerequisites: sudo apt-get install python-twisted python-numpy python-pyopencl 3. Download Phoenix You can do this one of 2 ways: A. Clone the Git repo using: git clone git@github.com:jedi95/Phoenix-Miner.git /home/username/phoenix Obviously you will want to modify the directory to suit your needs. B. Download https://github.com/jedi95/Phoenix-Miner/tarball/master Extract to the directory of your choice 4. Start Phoenix: ./phoenix.py -u http://username:password@pool.com:8332 -k phatk2 AGGRESSION=6 WORKSIZE=128 VECTORS DEVICE=0 You will need modify the URL to connect to the pool of your choice. The above settings should be optimal for a 5850 running at normal memory clocks. (substitute WORKSIZE=256 if underclocking the memory) |
|
|
|
Would someone mind fixing the nonces for me? I'm modding it for 128-bit and seem to have hit a snag. And, just so you know, uint8 DOES work with a worksize of 32! However, without the nonces finished, I don't know how well. I would try uint16 as it works too with a worksize of 1, but the bitshifting is a bit more involved. After this, I'm going to have to compute some different constants for a SHA-512/256 kernel. I'll need the fractional parts of the seventeenth through twenty-fourth prime numbers as stated here: http://eprint.iacr.org/2010/548.pdfFrom that point, I'll attempt a 64-bit, 128-bit and 256-bit version of the SHA-512 algorithm (in one) and then truncate the results to SHA-256. ^_^ The problem is, I'm no math genius so I'm going to need loads of help with this little project. The problem with uint8 is that you are going to use way more GPRs. Even if you get better efficiency per thread, the higher GPR use it going to reduce the maximum number of threads that can be processed at once. This problem can be minimized with high RAM clocks, but the higher power use might not be worth it. Also, truncated SHA512 isn't the same as SHA256. |
|
|
|
Okay, I think I have the kinds worked out mostly. Give it a try and tell me what you think. It's phak2 with a few simple logic mods. I would try the AMD Kernel Analyzer tool, but it doesn't seem to work right for me. So, I just go off of hash rate and accepts or rejects/errors. So far, no errors. But I'm squeezing out a few more decimal place hashes. // This file is taken and modified from the public-domain poclbm project, and
// I have therefore decided to keep it public-domain.
#ifdef VECTORS4
typedef uint4 u;
#else
#ifdef VECTORS
typedef uint2 u;
#else
typedef uint u;
#endif
#endif
__constant uint K[64] = {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
};
__constant uint ConstW[128] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x80000000U, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000280U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x80000000U, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000100U,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
};
__constant uint H[8] = {
0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19
};
#ifdef BITALIGN
#pragma OPENCL EXTENSION cl_amd_media_ops : enable
#define rot(x, y) amd_bitalign(x, x, (uint)(32 - y))
#else
#define rot(x, y) rotate(x, (uint)y)
#endif
// This part is not from the stock poclbm kernel. It's part of an optimization
// added in the Phoenix Miner.
// Some AMD devices have the BFI_INT opcode, which behaves exactly like the
// SHA-256 Ch function, but provides it in exactly one instruction. If
// detected, use it for Ch. Otherwise, construct Ch out of simpler logical
// primitives.
#ifdef BFI_INT
// Well, slight problem... It turns out BFI_INT isn't actually exposed to
// OpenCL (or CAL IL for that matter) in any way. However, there is
// a similar instruction, BYTE_ALIGN_INT, which is exposed to OpenCL via
// amd_bytealign, takes the same inputs, and provides the same output.
// We can use that as a placeholder for BFI_INT and have the application
// patch it after compilation.
// This is the BFI_INT function
#define Ch(x, y, z) amd_bytealign(x,y,z)
// Ma can also be implemented in terms of BFI_INT...
#define Ma(z, x, y) amd_bytealign(z^x,y,x)
#else
#define Ch(x, y, z) bitselect(z,y,x)
#define Ma(x, y, z) bitselect(x,y,(z^x))
#endif
//Various intermediate calculations for each SHA round
#define s0(n) (S0(Vals[(128 - (n)) % 8]))
#define S0(n) (rot(n, 30u)^rot(n, 19u)^rot(n,10u))
#define s1(n) (S1(Vals[(132 - (n)) % 8]))
#define S1(n) (rot(n, 26u)^rot(n, 21u)^rot(n, 7u))
#define ch(n) Ch(Vals[(132 - (n)) % 8],Vals[(133 - (n)) % 8],Vals[(134 - (n)) % 8])
#define maj(n) Ma(Vals[(129 - (n)) % 8],Vals[(130 - (n)) % 8],Vals[(128 - (n)) % 8])
//t1 calc when W is already calculated
#define t1(n) K[(n) % 64] + Vals[(135 - (n)) % 8] + W[(n)] + s1(n) + ch(n)
//t1 calc which calculates W
#define t1W(n) K[(n) % 64] + Vals[(135 - (n)) % 8] + W(n) + s1(n) + ch(n)
//Used for constant W Values (the compiler optimizes out zeros)
#define t1C(n) (K[(n) % 64] + ConstW[(n)]) + Vals[(135 - (n)) % 8] + s1(n) + ch(n)
//t2 Calc
#define t2(n) maj(n) + s0(n)
#define rotC(x,n) (x<<n | x >> (32-n))
//W calculation used for SHA round
#define W(n) (W[n] = P4(n) + P3(n) + P2(n) + P1(n))
//Partial W calculations (used for the begining where only some values are nonzero)
#define P1(n) ((rot(W[(n)-2],15u)^rot(W[(n)-2],13u)^((W[(n)-2])>>10U)))
#define P2(n) ((rot(W[(n)-15],25u)^rot(W[(n)-15],14u)^((W[(n)-15])>>3U)))
#define p1(x) ((rot(x,15u)^rot(x,13u)^((x)>>10U)))
#define p2(x) ((rot(x,25u)^rot(x,14u)^((x)>>3U)))
#define P3(n) W[n-7]
#define P4(n) W[n-16]
//Partial Calcs for constant W values
#define P1C(n) ((rotC(ConstW[(n)-2],15)^rotC(ConstW[(n)-2],13)^((ConstW[(n)-2])>>10U)))
#define P2C(n) ((rotC(ConstW[(n)-15],25)^rotC(ConstW[(n)-15],14)^((ConstW[(n)-15])>>3U)))
#define P3C(x) ConstW[x-7]
#define P4C(x) ConstW[x-16]
//SHA round with built in W calc
#define sharoundW(n) Barrier1(n); Vals[(131 - (n)) % 8] += t1W(n); Vals[(135 - (n)) % 8] = t1W(n) + t2(n);
//SHA round without W calc
#define sharound(n) Barrier2(n); Vals[(131 - (n)) % 8] += t1(n); Vals[(135 - (n)) % 8] = t1(n) + t2(n);
//SHA round for constant W values
#define sharoundC(n) Barrier3(n); Vals[(131 - (n)) % 8] += t1C(n); Vals[(135 - (n)) % 8] = t1C(n) + t2(n);
//The compiler is stupid... I put this in there only to stop the compiler from (de)optimizing the order
#define Barrier1(n) t1 = t1C((n+1))
#define Barrier2(n) t1 = t1C((n))
#define Barrier3(n) Barrier2(n)
__kernel
//removed this to allow detection of invalid work size
//__attribute__((reqd_work_group_size(WORKSIZE, 1, 1)))
void search( const uint state0, const uint state1, const uint state2, const uint state3,
const uint state4, const uint state5, const uint state6, const uint state7,
const uint B1, const uint C1, const uint D1,
const uint F1, const uint G1, const uint H1,
const u base,
const uint W16, const uint W17,
const uint PreVal4, const uint PreVal0,
const uint PreW31, const uint PreW32,
const uint PreW19, const uint PreW20,
__global uint * output)
{
u W[124];
u Vals[8];
//Dummy Variable to prevent compiler from reordering between rounds
u t1;
W[16] = W16;
W[17] = W17;
#ifdef VECTORS4
//Less dependencies to get both the local id and group id and then add them
W[3] = base + (uint)(get_local_id(0)) * 4u + (uint)(get_group_id(0)) * (WORKSIZE * 4u);
uint r = rot(W[3].x,25u)^rot(W[3].x,14u)^((W[3].x)>>3U);
//Since only the 2 LSB is opposite between the nonces, we can save an instruction by flipping the 4 bits in W18 rather than the 1 bit in W3
W[18] = PreW20 + (u){r, r ^ 0x2004000U, r ^ 0x4008000U, r ^ 0x600C000U};
#else
#ifdef VECTORS
W[3] = base + (uint)(get_local_id(0)) * 2u + (uint)(get_group_id(0)) * (WORKSIZE * 2u);
uint r = rot(W[3].x,25u)^rot(W[3].x,14u)^((W[3].x)>>3U);
W[18] = PreW20 + (u){r, r ^ 0x2004000U};
#else
W[3] = base + get_local_id(0) + get_group_id(0) * (WORKSIZE);
u r = PreW20 + rot(W[3],25u)^rot(W[3],14u)^((W[3])>>3U);
W[18] = PreW20 + r;
#endif
#endif
//the order of the W calcs and Rounds is like this because the compiler needs help finding how to order the instructions
Vals[0]=PreVal0 + W[3];
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
Vals[4]=PreVal4 + W[3];
Vals[5]=F1;
Vals[6]=G1;
Vals[7]=H1;
sharoundC(4);
W[19] = PreW19 + W[3];
sharoundC(5);
W[20] = P1(20) + P4C(20);
sharoundC(6);
W[21] = P1(21);
sharoundC(7);
W[22] = P1(22) + P3C(22);
sharoundC(8);
W[23] = W[16] + P1(23);
sharoundC(9);
W[24] = W[17] + P1(24);
sharoundC(10);
W[25] = P1(25) + P3(25);
W[26] = P1(26) + P3(26);
sharoundC(11);
W[27] = P1(27) + P3(27);
W[28] = P1(28) + P3(28);
sharoundC(12);
W[29] = P1(29) + P3(29);
sharoundC(13);
W[30] = P1(30) + P3(30) + P2C(30);
W[31] = PreW31 + P1(31) + P3(31);
sharoundC(14);
W[32] = PreW32 + P1(32) + P3(32);
sharoundC(15);
sharound(16);
sharound(17);
sharound(18);
sharound(19);
sharound(20);
sharound(21);
sharound(22);
sharound(23);
sharound(24);
sharound(25);
sharound(26);
sharound(27);
sharound(28);
sharound(29);
sharound(30);
sharound(31);
sharound(32);
sharoundW(33);
sharoundW(34);
sharoundW(35);
sharoundW(36);
sharoundW(37);
sharoundW(38);
sharoundW(39);
sharoundW(40);
sharoundW(41);
sharoundW(42);
sharoundW(43);
sharoundW(44);
sharoundW(45);
sharoundW(46);
sharoundW(47);
sharoundW(48);
sharoundW(49);
sharoundW(50);
sharoundW(51);
sharoundW(52);
sharoundW(53);
sharoundW(54);
sharoundW(55);
sharoundW(56);
sharoundW(57);
sharoundW(58);
sharoundW(59);
sharoundW(60);
sharoundW(61);
sharoundW(62);
sharoundW(63);
W[64]=state0+Vals[0];
W[65]=state1+Vals[1];
W[66]=state2+Vals[2];
W[67]=state3+Vals[3];
W[68]=state4+Vals[4];
W[69]=state5+Vals[5];
W[70]=state6+Vals[6];
W[71]=state7+Vals[7];
const u Temp = (0xb0edbdd0U + K[0]) + W[64];
//Vals 5 & 6 are not used but gives us a complete chunk instead of a partial
Vals[0]=H[0];
Vals[1]=H[1];
Vals[2]=H[2];
Vals[3]=Temp + 0xa54ff53aU;
Vals[4]=H[4];
Vals[5]=H[5];
Vals[6]=H[6];
Vals[7]=Temp + 0x08909ae5U;
//#define P124(n) P1(n) + P2(n) + P4(n)
W[80] = P2(80) + P4(80);
sharound(65);
W[81] = P1C(81) + P2(81) + P4(81);
sharound(66);
W[82] = P1(82) + P2(82) + P4(82);
sharound(67);
W[83] = P1(83) + P2(83) + P4(83);
sharound(68);
W[84] = P1(84) + P2(84) + P4(84);
sharound(69);
W[85] = P1(85) + P2(85) + P4(85);
sharound(70);
W[86] = P1(86) + P2(86) + P4(86) + P3C(86);
sharound(71);
W[87] = P1(87) + P2C(87) + P3(87) + P4(87);
sharoundC(72);
W[88] = P1(88) + P3(88) + P4C(88);
sharoundC(73);
W[89] = P1(89) + P3(89);
sharoundC(74);
W[90] = P1(90) + P3(90);
sharoundC(75);
W[91] = P1(91) + P3(91);
sharoundC(76);
W[92] = P1(92) + P3(92);
sharoundC(77);
W[93] = P1(93) + P3(93);
W[94] = P1(94) + P3(94) + P2C(94);
sharoundC(78);
W[95] = P1(95) + P2(95) + P3(95) + P4C(95);
sharoundC(79);
sharound(80);
sharound(81);
sharound(82);
sharound(83);
sharound(84);
sharound(85);
sharound(86);
sharound(87);
sharound(88);
sharound(89);
sharound(90);
sharound(91);
sharound(92);
sharound(93);
sharound(94);
sharound(95);
sharoundW(96);
sharoundW(97);
sharoundW(98);
sharoundW(99);
sharoundW(100);
sharoundW(101);
sharoundW(102);
sharoundW(103);
sharoundW(104);
sharoundW(105);
sharoundW(106);
sharoundW(107);
sharoundW(108);
sharoundW(109);
sharoundW(110);
sharoundW(111);
sharoundW(112);
sharoundW(113);
sharoundW(114);
sharoundW(115);
sharoundW(116);
sharoundW(117);
sharoundW(118);
sharoundW(119);
sharoundW(120);
sharoundW(121);
sharoundW(122);
const u precomp = (Vals[0] + Vals[4]) + (K[59] + W(123)) + s1(123) + ch(123);
u v = W[117] + W[108] + Vals[3] + Vals[7] + P2(124) + P1(124) + Ch((precomp),Vals[1],Vals[2]);
u g = -(K[60] + H[7]) - S1(precomp);
uint nonce = 0;
#ifdef VECTORS4
if (v.x == g.x)
{
nonce = W[3].x;
}
if (v.y == g.y)
{
nonce = W[3].y;
}
if (v.z == g.z)
{
nonce = W[3].z;
}
if (v.w == g.w)
{
nonce = W[3].w;
}
#else
#ifdef VECTORS
if (v.x == g.x)
{
nonce = W[3].x;
}
if (v.y == g.y)
{
nonce = W[3].y;
}
#else
if (v == g)
{
nonce = W[3];
}
#endif
#endif
if(nonce)
{
//Faster to shift the nonce by 2 due to 4-DWORD addressing and does not add more collisions
output[OUTPUT_SIZE] = nonce;
output[get_local_id(0)] = nonce;
}
} Nice work! This kernel still uses 1356 ALU OPs (same as current phatk2) but it uses 1 less GPR (22 vs 23). However, the above is only true for VLIW5. On VLIW4 (69xx) it uses 2 more GPRs (25 vs 23) |
|
|
|
While attempting to use p2pool I get this error: /usr/local/src/phoenix-1.7.4/WorkQueue.py:80: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
if self.lastBlock is not None and (wu.data[4:36] == self.lastBlock): Any idea why/solution? Looks like I missed updating the "work from previous block" check when I added X-Work-Identifier. Basically the error occurs under P2Pool because self.lastblock is actually the P2Pool identifier from the previous 'block', and not the bitcoin previous block hash. I have fixed this in 1.7.5 on GitHub, but I am currently away from my main computer to compile a Windows binary. (will be up later tonight) Let me know if this resolves the issue. |
|
|
|
Just for curiosity I thought I'd see if there's any hashrate to be gained with compiling pyOpenCL in Visual Studio 2010 with Stream SDK 2.6 RC3:
Python 2.7.2
Base-12.1.1.win32-py2.7
numpy-MKL-1.6.1.win32-py2.7-2011-10-29
scipy-0.10.0.win32-py2.7
zope.interface-3.8.0.win32-py2.7
Twisted-11.1.0.win32-py2.7
I compiled boost_1_48_0 multithreaded in msvc-10.0, I now have boost_python-vc100-mt-1_48.dll. Compiled pyopencl-0.92 after doing the manifest tweaks and env variables to get it to work.
Results? Exactly the same 224.00 MHash/s as Phoenix 1.7.4 exe gives me. Yay. Three hours I won't get back... At least my python isn't slower than the exe's python any more.
I did some further tests with 1.7.3 and the latest pyOpenCL, too and have to say I never got a miner idle message nor other problems. So it would be nice if we were able to chose, which version pyOpenCL version we want to download jedi  . Thanks, Dia The bugs that caused the miner to idle were all related to the RPC implementation. Using twisted.web for the RPC backend always caused problems so that's why we re-wrote it to use httplib instead for 1.7.0. The extra delay getting work won't be enough to cause the miner to idle thanks to the work queue. (which is around 10 seconds of stored work on a fast miner like a 5870) For those who want to use other versions of PyOpenCL I suggest you run Phoenix from source rather than use the compiled binaries. Supporting more than one official binary is not something I want to deal with. If you want a binary with the newer versions you can always compile one yourself. |
|
|
|
Ummm, I think you forgot to either change the version number or did not upload the 1.7.4 source yet cause when I dl the latest git tarball it still says 1.7.3..just thought I'd let ya know :p Thanks, fixed. |
|
|
|
I'm getting a massive amount of rejected shares on many mining pools when using Phoenix-1.7.3. When turning on -v debugging it shows the reason for rejection is due to unknown-work?? I already did a search of this problem and found this link. However, it's unclear to me what the real problem is. The rejection rate I'm seeing when I mine on say abcpool.co and simplecoin.us, I get like 90%+ rejection(eg. 2 accepts, 13 rejects). This doesn't happen when I use ufaminer. Oddly, bitcoinpool.com seems to be okay with phoenix. Why does this happen and is there a way to fix this? I would have posted this on that thread I linked but since I'm a newbie, the forum won't allow me so I'm posting it here instead. Thanks The cause of this problem is low overall hashrate. Phoenix maintains a work queue to reduce hashrate disruptions caused by momentary connection problems. This works great on faster hardware like the ATI 5870, but it can cause issues with miners that get <100 Mhash or so. The reason for "unknown-work" rejects is that those shares were from work that has been sitting in the queue for long periods of time. (>1 minute) Some pools "forget" about assigned work after very shot time periods (1 minute for example) and any results returned based on that work are rejected as unknown. This problem has been known for a couple weeks, but I haven't come up with a proper solution for it yet. Updating to 1.7.4 won't help in this case, because the changes were aimed at improving P2Pool compatibility only. Your best option is to try another pool. Not every pool forgets about assigned work quickly. |
|
|
|
@jedi95: I observed a strange bug with the compiled Phoenix based on 2011.2, it crashes on this line, which works in your latest fixed version and worked with the one before, who had 2011.1beta3. self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)I know you won't give support for that one, but have you got any ideas why this happens? Edit: Removed the line for testing and changed all depracted stuff to the new function calls and made another observation. I never saw such stuff like which block we are on or that Server gave work from previous block. Is this info from the pool or new in Phoenix? [15/01/2012 15:29:45] LP: New work pushed
[15/01/2012 15:29:46] Server gave new work; passing to WorkQueue
[15/01/2012 15:29:46] New block (WorkQueue)
[15/01/2012 15:29:46] Server gave new work; passing to WorkQueue
[15/01/2012 15:29:46] Server gave work from the previous block, ignoring.
[15/01/2012 15:29:52] Server gave new work; passing to WorkQueue
[15/01/2012 15:29:53] Currently on block: 162310
[15/01/2012 15:30:52] Server gave new work; passing to WorkQueue
[15/01/2012 15:31:57] Server gave new work; passing to WorkQueue Edit 2: I tested 2011.2 for 30 minutes and got 0 rejects, which is great for my 6550D ... dunno if this was luck or if this version runs smoother. Thanks, Dia And this is exactly why I won't be using the newer versions. The "Server gave work from the previous block, ignoring" error is one of the many problems that occur because of the work delay. This is basically what happened: 1. Sometime before 15:29:45 Phoenix started a work request 2. LP returned new work at 15:29:45 3. The work request completes at 15:29:46, but because it took so long it's from the previous block and useless When this happens in reverse (sending work to server) you get stale shares. 30 minutes isn't really long enough for an effective stale share test, especially on a slower GPU like the 6550D. "Currently on block: " is sent by the pool using x-blocknum. Some pools send it, others don't. |
|
|
|
I'm not sure if I understand this behaviour, but it seems with finish(), results are confirmed imediately, while without finish() it takes a few seconds for the results to get processed. Any explanation for this?
Dia
My best guess is that removing finish() makes the delay getting/sending results worse. (assuming you used 2011.1 or 2011.2 for that test) Even if you don't see the same hashrate differences, the delay that 2011.1 and 2011.2 introduce to getting work/sending results is problematic. Have a look at these test runs using -q 20 and a local bitcoin client: 0.92C:\phoenix>python phoenix.py -u http://bitcoin:bitcoin@localhost:8332 -v -q 20 -k poclbm platform=1 device=0 aggression=2
[14/01/2012 10:13:35] Phoenix v1.7.3 starting...
[14/01/2012 10:13:35] Connected to server
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] New block (WorkQueue)
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[14/01/2012 10:13:35] Server gave new work; passing to WorkQueue
[137.12 Mhash/sec] [0 Accepted] [0 Rejected] [RPC] Notice how it is able to fully populate the queue is less than a second. Now compare that to 2011.2: C:\phoenix>python phoenix.py -u http://bitcoin:bitcoin@localhost:8332 -v -q 20 -k poclbm platform=1 device=0 aggression=2
[14/01/2012 10:17:14] Phoenix v1.7.3 starting...
[14/01/2012 10:17:14] Connected to server
[14/01/2012 10:17:14] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:14] New block (WorkQueue)
[14/01/2012 10:17:14] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:14] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:17] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:17] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:17] Server gave new work; passing to WorkQueue
[14/01/2012 10:17:17] Server gave new work; passing to WorkQueue
[133.43 Mhash/sec] [0 Accepted] [0 Rejected] [RPC] Notice how it now took a full 3 seconds to populate the queue. EDIT: It seems that higher AGGRESSION makes the problem worse: (again using 2011.2) C:\phoenix>python phoenix.py -u http://bitcoin:bitcoin@localhost:8332 -q 20 -v -k poclbm platform=1 device=0 aggression=8
[14/01/2012 10:59:12] Phoenix v1.7.3 starting...
[14/01/2012 10:59:12] Connected to server
[14/01/2012 10:59:12] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:12] New block (WorkQueue)
[14/01/2012 10:59:13] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:14] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:14] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:15] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:16] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:17] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:18] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:19] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:20] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:21] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:22] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:23] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:24] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:25] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:26] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:27] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:28] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:29] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:29] Server gave new work; passing to WorkQueue
[14/01/2012 10:59:30] Server gave new work; passing to WorkQueue
[143.70 Mhash/sec] [0 Accepted] [0 Rejected] [RPC] We are now looking at close to 1 second per work request, which is simply unacceptable. This delay gets worse when connecting to remote servers. Unless a means of fixing this problem is found the official binaries for Phoenix will never use these versions of PyOpenCL. However, I don't mind compiling a few binaries with the newer versions for testing: http://jedi95.com/files/phoenix-1.7.3-2011.1.ziphttp://jedi95.com/files/phoenix-1.7.3-2011.2.zipTo anyone who hasn't been following this thread: The above binaries are intended for testing only, and WILL cause an increase in stale shares. |
|
|
|
still quits after 10 sec
Its totally buggy
If by "quits", you mean "this version randomly crashes my computer with a frozen screen when using AGGRESSION=12, even at lower overclocks than before", then that's what I see too. I just tested with AGGRESSION=12 and the only problem I can see is extreme desktop lag. (to be expected though, on a GTX 580 this gives a kernel execution time of close to 2 seconds) I would test with higher values but this would trigger a TDR and driver reset due to the kernel execution time exceeding 2 seconds. Can you post your system specs and command line? I haven't really investigated, since this is my main PC where the symptom emerged, the problem only cropped up doing benchmarks, and things still work at an unintrusive phatk2 Worksize=128 Aggression=6 Fastloop=True. I got at least 5 lockups in an hour of testing on both phatk & dia's kernel at worksize=64 aggression=12, usually when clicking any other app but the miner. I would suspect it is something similar to diapolo's 8-27 kernel, where it's optimizations made a previous good overclock unstable (although that symptom was the kernel returning bad hashes). Catalyst 12.1a/OpenCL2.6/Radeon HD 5770 @ 970/970 (stable up to 990/1300)/win7x86/phoenix.exe 1.7.3. Benchmarks and more details of the config.This might be a TDR issue. When you do things with the computer it slows down the miner somewhat, which can push it just over the edge when it is close to causing a TDR as-is. Any time a kernel execution takes longer than 2 seconds a TDR should occur, which will either crash the system or result in a GPU driver reset. This won't be a problem when using sane values of AGGRESSION. To test this, try running AGGRESSION=13. It should instantly cause a TDR and lockup regardless of overclock settings on your configuration. More info on TDR: http://msdn.microsoft.com/en-us/windows/hardware/gg487368 |
|
|
|
still quits after 10 sec
Its totally buggy
If by "quits", you mean "this version randomly crashes my computer with a frozen screen when using AGGRESSION=12, even at lower overclocks than before", then that's what I see too. I just tested with AGGRESSION=12 and the only problem I can see is extreme desktop lag. (to be expected though, on a GTX 580 this gives a kernel execution time of close to 2 seconds) I would test with higher values but this would trigger a TDR and driver reset due to the kernel execution time exceeding 2 seconds. Can you post your system specs and command line? |
|
|
|
The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.
When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message: [13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3 thanks to these lines in __init__.py: # output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT) The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?) Ah, I must have missed some of the files when I was messing around with it trying to fix the delay getting work. The _cl.pyd file is from 0.92. I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip. |
|
|
|
|
Show Posts
