*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.
Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..? 
Topic: Phoenix 2 beta discussion - page 2. (Read 57899 times)
*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.
[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"
[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)
Code:
[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
[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"
[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)
[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"
[03:43:57] Failed to load plugin "opencl"
[03:43:57] Failed to load plugin "phatk2"
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 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.
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 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)
What about using atomic counters for the statistics part?
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 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?
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?
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?
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.
back to using rc1 until bug is fixed.
back to using rc1 until bug is fixed.
A fix for this bug has been pushed to the Git repo.
https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py
why was self.f[8] taken out? It's working better for me with the old one
You are confusing the phatk2 __init__.py with the opencl one. The only change is here:
https://github.com/phoenix2/phoenix/commit/9083008563fc6cffae99627e32ef8c39abf34859
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.
back to using rc1 until bug is fixed.
back to using rc1 until bug is fixed.
A fix for this bug has been pushed to the Git repo.
https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py
wow, thanks for fast fix, thanks. eagerly awaiting next windows build.
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.
back to using rc1 until bug is fixed.
back to using rc1 until bug is fixed.
A fix for this bug has been pushed to the Git repo.
https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py
why was self.f[8] taken out? It's working better for me with the old one
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.
back to using rc1 until bug is fixed.
back to using rc1 until bug is fixed.
A fix for this bug has been pushed to the Git repo.
https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py
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.
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.
heres my config file.
Code:
[general]
verbose = True
backend = http://1CxcPP8FVktppy4PHTYJKnZFqQeyZ3jArb:[email protected]: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.
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
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
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
Dia
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available 
.
I want to make DiakGCN RC2 compatible ^^.
Dia
.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.
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available .
I want to make DiakGCN RC2 compatible ^^.
Dia
.I want to make DiakGCN RC2 compatible ^^.
Dia
See second post:
https://bitcointalksearch.org/topic/m.733433
Or download it directly:
https://github.com/downloads/phoenix2/phoenix/phoenix-2.0.0-rc2.zip
Sounds pretty cool, thanks for the changes ... if only the Windows build would be available .
I want to make DiakGCN RC2 compatible ^^.
Dia
.I want to make DiakGCN RC2 compatible ^^.
Dia
Jump to: