Bitcoin Forum
December 05, 2016, 08:34:33 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 »  All
  Print  
Author Topic: Phoenix 2 beta discussion  (Read 44691 times)
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
February 22, 2012, 10:31:58 AM
 #121

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
1480926873
Hero Member
*
Offline Offline

Posts: 1480926873

View Profile Personal Message (Offline)

Ignore
1480926873
Reply with quote  #2

1480926873
Report to moderator
1480926873
Hero Member
*
Offline Offline

Posts: 1480926873

View Profile Personal Message (Offline)

Ignore
1480926873
Reply with quote  #2

1480926873
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480926873
Hero Member
*
Offline Offline

Posts: 1480926873

View Profile Personal Message (Offline)

Ignore
1480926873
Reply with quote  #2

1480926873
Report to moderator
1480926873
Hero Member
*
Offline Offline

Posts: 1480926873

View Profile Personal Message (Offline)

Ignore
1480926873
Reply with quote  #2

1480926873
Report to moderator
1480926873
Hero Member
*
Offline Offline

Posts: 1480926873

View Profile Personal Message (Offline)

Ignore
1480926873
Reply with quote  #2

1480926873
Report to moderator
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
February 22, 2012, 11:11:15 AM
 #122

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

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
February 22, 2012, 11:21:35 AM
 #123

Sounds pretty cool, thanks for the changes ... if only the Windows build would be available Cheesy.
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

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
CFSworks
Member
**
Offline Offline

Activity: 63


View Profile
February 22, 2012, 11:25:43 AM
 #124

Sounds pretty cool, thanks for the changes ... if only the Windows build would be available Cheesy.
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.

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
February 22, 2012, 12:52:21 PM
 #125

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Schwede65
Sr. Member
****
Offline Offline

Activity: 309


View Profile
February 23, 2012, 07:52:48 AM
 #126

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

2. when the rc-2 gave-up (server-disconnection + many rejects), rc-1 started new and stable up to now

ssateneth
Legendary
*
Offline Offline

Activity: 1288



View Profile
February 25, 2012, 01:52:14 PM
 #127

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
Full Member
***
Offline Offline

Activity: 219


View Profile
February 25, 2012, 08:10:24 PM
 #128

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

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
blandead
Jr. Member
*
Offline Offline

Activity: 46


View Profile
February 25, 2012, 09:02:34 PM
 #129

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
Legendary
*
Offline Offline

Activity: 1288



View Profile
February 26, 2012, 03:55:34 AM
 #130

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
Full Member
***
Offline Offline

Activity: 219


View Profile
February 26, 2012, 03:58:06 AM
 #131

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

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
blandead
Jr. Member
*
Offline Offline

Activity: 46


View Profile
February 26, 2012, 09:36:11 AM
 #132

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
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
March 01, 2012, 04:05:52 AM
 #133

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?

If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
blandead
Jr. Member
*
Offline Offline

Activity: 46


View Profile
March 01, 2012, 06:04:14 PM
 #134

What about using atomic counters for the statistics part?
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
March 02, 2012, 12:44:30 AM
 #135

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
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
March 02, 2012, 05:01:42 PM
 #136

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.




If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
aaa801
Member
**
Offline Offline

Activity: 95



View Profile
March 03, 2012, 03:44:58 AM
 #137

[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
Full Member
***
Offline Offline

Activity: 219


View Profile
March 03, 2012, 09:58:16 AM
 #138

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

Activity: 95



View Profile
March 03, 2012, 10:38:22 AM
 #139

[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


LTC: LUUikznZrvDb65ZCNQUNCiTaCB4CWGYRSZ
BTC: 1325TrScK8jkiPuMEMxNf1VXHHfnR1QtgN
ssateneth
Legendary
*
Offline Offline

Activity: 1288



View Profile
March 03, 2012, 11:46:07 AM
 #140

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

Pages: « 1 2 3 4 5 6 [7] 8 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!