jedi95
|
|
February 22, 2012, 10:31:58 AM |
|
There has been a significant change to the Windows build in RC2. PyOpenCL has been updated from 0.92 to 2011.2. The included kernels have been modified to work correctly under both 2011.2 and 0.92. Kernel developers should target PyOpenCL 2011.2 now.
In short: Any kernels running under 2011.2 need to use is_blocking = False in order to prevent large delays getting work. PyOpenCL 2011.2 has a built-in kernel binary caching system that is enabled by default. The included kernels disable this and continue to use their own system.
|
Phoenix Miner developer Donations appreciated at: 1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
|
|
|
Diapolo
|
|
February 22, 2012, 11:11:15 AM |
|
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available . I want to make DiakGCN RC2 compatible ^^. Dia
|
|
|
|
|
CFSworks (OP)
Member
Offline
Activity: 63
Merit: 10
|
|
February 22, 2012, 11:25:43 AM |
|
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available . I want to make DiakGCN RC2 compatible ^^. Dia We had it uploaded with an extra dot in the filename... Oops! jedi95 fixed it. The changes for RC2 should really just be renaming MiningKernel to PhoenixKernel, and putting the kernel package in "plugins" instead of "kernels" (which is no longer used as the directory name) Edit: Let me clarify: Those changes are what are needed to get it working. You should also add jedi95's changes, since those fix some performance problems.
|
|
|
|
Diapolo
|
|
February 22, 2012, 12:52:21 PM |
|
I can confirm backups-support works, would be nice though, if in verbose mode the url would be displayed if pool get's switched so you know to which pool you are connected. The switch to the latest pyOpenCL is a good move and this works with my kernel, too.
Dia
|
|
|
|
Schwede65
|
|
February 23, 2012, 07:52:48 AM |
|
W7-64-bit rc-1 is running more stable then rc-2 running both versions on different rigs 1. when the rc-2 gave-up (server-disconnection + many rejects), backup-pool was not working (i had my guiminer parallel working ) 2. when the rc-2 gave-up (server-disconnection + many rejects), rc-1 started new and stable up to now
|
|
|
|
ssateneth
Legendary
Offline
Activity: 1344
Merit: 1004
|
|
February 25, 2012, 01:52:14 PM |
|
Hmm, RC1 works flawlessly. I tried RC2 but it's bugged bad? I thought it might have been incompatible with sdk 2.1 (wont hash at all), so I tried 2.6. It has a different error, but it hashes slow compared to 2.6, and I refuse to use 2.6 and be forced to use high memory clocks and waste power. heres my config file. [general] verbose = True backend = http://1CxcPP8FVktppy4PHTYJKnZFqQeyZ3jArb:x@mining.eligius.st:8337
[cl:1:1] kernel = phatk2 AGGRESSION = 14 VECTORS = true BFI_INT = true WORKSIZE = 256
[web] disable = true heres the error with 2.1 sdk (cl:1:1) heres the error with 2.6 sdk (cl:0:0) back to using rc1 until bug is fixed.
|
|
|
|
|
blandead
Newbie
Offline
Activity: 46
Merit: 0
|
|
February 25, 2012, 09:02:34 PM |
|
why was self.f[8] taken out? It's working better for me with the old one
|
|
|
|
ssateneth
Legendary
Offline
Activity: 1344
Merit: 1004
|
|
February 26, 2012, 03:55:34 AM |
|
wow, thanks for fast fix, thanks. eagerly awaiting next windows build.
|
|
|
|
|
blandead
Newbie
Offline
Activity: 46
Merit: 0
|
|
February 26, 2012, 09:36:11 AM |
|
oh sorry.. so i was going through some of the newer python methods
platform="None" is depracated now, maybe should just get rid of checking for platform and just check for device. I think platform has a function that looks it up anyways.
Also the "is_blocking" is defaulted to true, so wouldn't it be better to set it to false on the enqueue_write_buffer as well?
|
|
|
|
lodcrappo
|
|
March 01, 2012, 04:05:52 AM |
|
So finally got around to rolling phoenix2 into BAMT. It seems to work great, nice job.
I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.
Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.
I added simple counters for these and then included them in the results of listdevices, just like 'results' is done. Seems to work fine though I am not sure it's the best way. Could these types of status be added to the official rpc interface?
|
|
|
|
blandead
Newbie
Offline
Activity: 46
Merit: 0
|
|
March 01, 2012, 06:04:14 PM |
|
What about using atomic counters for the statistics part?
|
|
|
|
jedi95
|
|
March 02, 2012, 12:44:30 AM |
|
So finally got around to rolling phoenix2 into BAMT. It seems to work great, nice job.
I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.
Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.
I added simple counters for these and then included them in the results of listdevices, just like 'results' is done. Seems to work fine though I am not sure it's the best way. Could these types of status be added to the official rpc interface?
I have added accepted and rejected fields to the listdevices RPC interface. The number of shares that were not sent to the server for any reason can be found by: shares not sent = results - (accepted + rejected)
|
Phoenix Miner developer Donations appreciated at: 1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
|
|
|
lodcrappo
|
|
March 02, 2012, 05:01:42 PM |
|
So finally got around to rolling phoenix2 into BAMT. It seems to work great, nice job.
I thought originally we'd have to write a plugin, but actually the RPC interface does everything needed except a couple statistics, and I think those are simple to add.
Right now it reports 'results' per GPU but not accepted vs rejected, and not shares that are discarded as stale or if the "Result didn't meet full difficulty, not sending" condition in KernelInterface happens.
I added simple counters for these and then included them in the results of listdevices, just like 'results' is done. Seems to work fine though I am not sure it's the best way. Could these types of status be added to the official rpc interface?
I have added accepted and rejected fields to the listdevices RPC interface. The number of shares that were not sent to the server for any reason can be found by: shares not sent = results - (accepted + rejected) great, that means we can throw away all the custom stuff bamt used to have to hack into phoenix, very nice. also kudos on using a standard interface.. json/rpc might not be everyone's favorite thing but its a standard and its pleasant to deal with. the only area where phoenix2 does not now provide as good or better info than other miners is with pool summary data... this isn't something I've ever worried about with original phoenix since it basically supported only the one, or at best a single backup. However now that phoenix2 is supporting lots of backup pools, it might be worth consideration. some sort of "listpools" similar to listdevices that reported per pool info.. accept/reject/connection errors, latency that kind of thing might be nice. If you're interested and it helps, I could hack such a thing together.
|
|
|
|
aaa801
Member
Offline
Activity: 95
Merit: 10
|
|
March 03, 2012, 03:44:58 AM |
|
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2 [03:43:57] Failed to load plugin "opencl" [03:43:57] Failed to load plugin "phatk2"
|
LTC: LUUikznZrvDb65ZCNQUNCiTaCB4CWGYRSZ BTC: 1325TrScK8jkiPuMEMxNf1VXHHfnR1QtgN
|
|
|
jedi95
|
|
March 03, 2012, 09:58:16 AM |
|
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2 [03:43:57] Failed to load plugin "opencl" [03:43:57] Failed to load plugin "phatk2"
Those 3 lines are not enough information to determine the cause of the problem. Could you provide the following: Which OS? Are you using the compiled binaries or running phoenix from source? Which GPU(s) do you have? Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC)
|
Phoenix Miner developer Donations appreciated at: 1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
|
|
|
aaa801
Member
Offline
Activity: 95
Merit: 10
|
|
March 03, 2012, 10:38:22 AM |
|
[03/03/2012 03:43:57] Welcome to Phoenix v2.0.0-rc2 [03:43:57] Failed to load plugin "opencl" [03:43:57] Failed to load plugin "phatk2"
Those 3 lines are not enough information to determine the cause of the problem. Could you provide the following: Which OS? Are you using the compiled binaries or running phoenix from source? Which GPU(s) do you have? Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC) Which OS? Windows 7 64bit Are you using the compiled binaries or running phoenix from source? binaries Which GPU(s) do you have? 5850 Can you post a copy of your phoenix.cfg? (remember to edit out user/password for backend and RPC) [general] verbose = True autodetect = +cl -cpu # The rightmost parameter takes precedence. This enables all OpenCL devices, except those that are CPUs. backend = http://localhost:9332 # URL format is exactly as it was in Phoenix 1 backups = URL1 URL2 URL3 URL4 # Any number of backup backends (space-separated) to use in case the primary backend goes down.
[web] password = ### # Set an RPC password to keep people from messing with your miners.
AGGRESSION = 12 bfi_int = True vectors = True FASTLOOP=FALSE WORKSIZE=256
|
LTC: LUUikznZrvDb65ZCNQUNCiTaCB4CWGYRSZ BTC: 1325TrScK8jkiPuMEMxNf1VXHHfnR1QtgN
|
|
|
ssateneth
Legendary
Offline
Activity: 1344
Merit: 1004
|
|
March 03, 2012, 11:46:07 AM |
|
*Sigh* See, the problem is people just copy paste. They don't try to understand what a config file does or what you should put in there. Every time I see that autodetect line, I just facepalm.
|
|
|
|
|