Phoenix 2 beta discussion

[jedi95]

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.

[1713887302]

1713887302

[Diapolo]

Sounds pretty cool, thanks for the changes ... if only the Windows build would be available .
I want to make DiakGCN RC2 compatible ^^.

Dia

[jedi95]

Sounds pretty cool, thanks for the changes ... if only the Windows build would be available .
I want to make DiakGCN RC2 compatible ^^.

Dia

See second post:
https://bitcointalk.org/index.php?topic=62765.msg733433#msg733433

Or download it directly:
https://github.com/downloads/phoenix2/phoenix/phoenix-2.0.0-rc2.zip

[CFSworks]

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]

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]

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]

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.

Code:

[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.

[jedi95]

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.

A fix for this bug has been pushed to the Git repo.

https://raw.github.com/phoenix2/phoenix/9083008563fc6cffae99627e32ef8c39abf34859/phoenix2/plugins/opencl/__init__.py

[blandead]

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.

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

[ssateneth]

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.

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.

[jedi95]

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.

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

[blandead]

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]

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]

What about using atomic counters for the statistics part?

[jedi95]

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)

[lodcrappo]

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]

[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"

[jedi95]

[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)

[aaa801]

[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)

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

[ssateneth]

*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.