Phoenix 2 beta discussion

[aaa801]

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

[1714896429]

1714896429

[1714896429]

1714896429

[1714896429]

1714896429

[1714896429]

1714896429

[1714896429]

1714896429

[1714896429]

1714896429

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

Well maybe if there was some actual sample code or less assholeism from forum members itd be easier to get working..?

You mean the example on the very first post of the very first page?  It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.

[aaa801]

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

You mean the example on the very first post of the very first page?  It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.

I put in the parameters from my other miner that is working fine
the fact that this cant load the freking plugins would mean that its fuck all to do with the config wouldnt it.

[TurdHurdur]

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

What cwd are you running it from?

[aaa801]

the root of the phoenix 2 folder, where phoenix.exe is located

[d3m0n1q_733rz]

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

You mean the example on the very first post of the very first page?  It's an example. It's not meant for you to copy paste. Understand it. Learn from it. Make your own to best suit your needs. I don't know what hardware you have or what parameters best suit your needs, only you do.

I put in the parameters from my other miner that is working fine
the fact that this cant load the freking plugins would mean that its fuck all to do with the config wouldnt it.

Actually, it could mean that they changed the kernel directory on you.  You might have to move your kernels over to the new directory.

[shackleford]

I have been using this for a few weeks and I have noticed something odd but I don't know if it is just me. It seems like the longer I leave it open less shares get submitted back to my pool. The hash rate that the pools report based on returned work has generally been pretty accurate over time . However the longer I leave phoenix 2.0 open the lower it goes until I close and restart it. The lowest I have let it go was around 30% off the expected.  As soon as I restart it immediately goes up to where I would expect it (and correlating share of block). The miner always reports the expected full speed hash speed.

This is not a big deal as long as I remember to restart it every few days but thought I would mention it so people could tell me I was crazy.

[shackleford]

I have been using this for a few weeks and I have noticed something odd but I don't know if it is just me. It seems like the longer I leave it open less shares get submitted back to my pool. The hash rate that the pools report based on returned work has generally been pretty accurate over time . However the longer I leave phoenix 2.0 open the lower it goes until I close and restart it. The lowest I have let it go was around 30% off the expected.  As soon as I restart it immediately goes up to where I would expect it (and correlating share of block). The miner always reports the expected full speed hash speed.

This is not a big deal as long as I remember to restart it every few days but thought I would mention it so people could tell me I was crazy.

NM, one of my cards was messing up and not hashing even though it was somehow counting towords the total. Running 1.75 for each gpu  stalls one miner, looks like you can't go by what is being reported for the hash rate. The missing 30% matches up with the cards hashing power.Lowered the OC 10mhz and all is well.

[flinder]

Hello,

i tried Phoenix 2 beta RC2 today. After some configuration I get a higher Hashrate than with Phoenix 1.
But I have one question to the output? What does "rolling time" means? I get this output very often.

I have an ATI 6850 with the following setup:

[general]
verbose = True
autodetect = +cl -cpu
backend = http://xxx.xxx:xxx@api2.bitcoin.cz:8332

[web]
password = rpc_password

[cl:0:0]       
kernel = phatk2   
autoconfigure = false
bfi_int = true
vectors4 = true    
WORKSIZE = 128      
AGGRESSION = 11   
FASTLOOP = false

Thanks for the explanation!

[jedi95]

Hello,

i tried Phoenix 2 beta RC2 today. After some configuration I get a higher Hashrate than with Phoenix 1.
But I have one question to the output? What does "rolling time" means? I get this output very often.

I have an ATI 6850 with the following setup:

[general]
verbose = True
autodetect = +cl -cpu
backend = http://xxx.xxx:xxx@api2.bitcoin.cz:8332

[web]
password = rpc_password

[cl:0:0]       
kernel = phatk2   
autoconfigure = false
bfi_int = true
vectors4 = true    
WORKSIZE = 128      
AGGRESSION = 11   
FASTLOOP = false

Thanks for the explanation!

"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.

[flinder]

"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.

First thanx for the explanation.
Now when I know what it means, I found this feature on the website of bitcoin.cz (Slush's Pool) to. He has implemented this feature to his pool.

But maybe there is a problem. Or better to say it seems for me like I have a problem.
With Phoenix 2 I have a higher Hashrate on my system. But I get lower average BTC in the pool for my work on the last 2 days.

The pay out system on bitcoin.cz is in the way that the last shares are more important than the first ones.
Could it be, because of this proportional system and the fact X-Roll-NTime reduces the load on the pool server, that I submit hashes in longer distances? But you will get more BTC on bitcoin.cz when you are close to the moment, when the solution is found.

So this feature seems to be good for the pool, but maybe bad for me  
And I have to think about the probability, that I also will get more BTC, when I sometimes will submit more datas close to the end.

But there is one question. Is it possible to disable this feature in the miner? Is there a setting I have to set on false?

Thanks for the help again!  

[jedi95]

"Rolling Time" is a debug output that indicates when Phoenix increments the timestamp on a WorkUnit. This reduces the load on the pool server by generating more work locally instead of asking for more. This will only occur on pool servers which send the X-Roll-NTime header.

First thanx for the explanation.
Now when I know what it means, I found this feature on the website of bitcoin.cz (Slush's Pool) to. He has implemented this feature to his pool.

But maybe there is a problem. Or better to say it seems for me like I have a problem.
With Phoenix 2 I have a higher Hashrate on my system. But I get lower average BTC in the pool for my work on the last 2 days.

The pay out system on bitcoin.cz is in the way that the last shares are more important than the first ones.
Could it be, because of this proportional system and the fact X-Roll-NTime reduces the load on the pool server, that I submit hashes in longer distances? But you will get more BTC on bitcoin.cz when you are close to the moment, when the solution is found.

So this feature seems to be good for the pool, but maybe bad for me 
And I have to think about the probability, that I also will get more BTC, when I sometimes will submit more datas close to the end.

But there is one question. Is it possible to disable this feature in the miner? Is there a setting I have to set on false?

Thanks for the help again! 

A few things:

1. Measuring payout over a period of 2 days on any non pay-per-share pool is not enough data to make any conclusions. (pool luck makes a big difference)

2. Rolling time doesn't have any effect on sending results. You have the same odds of finding a share either way. (and thus the payout is not affected)

3. The pool doesn't care if a share is from locally generated rolltime work or work sent by the server. Either way it will count the same.

4. If you still want disable the feature you can modify your URL to set maxtime:
  http://name:password@api2.bitcoin.cz:8332/;maxtime=0

[flinder]

A few things:

1. Measuring payout over a period of 2 days on any non pay-per-share pool is not enough data to make any conclusions. (pool luck makes a big difference)

2. Rolling time doesn't have any effect on sending results. You have the same odds of finding a share either way. (and thus the payout is not affected)

3. The pool doesn't card if a share is from locally generated rolltime work or work sent by the server. Either way it will count the same.

4. If you still want disable the feature you can modify your URL to set maxtime:
  http://name:password@api2.bitcoin.cz:8332/;maxtime=0

First thanks for your answer!
But let me explain my thoughts again, because I think there is a uncertainty in my problem.

I work in Slush's Pool (bitcoin.cz). Because of pool hopping he implements in this pool a system, where older shares (from beginning of the round) has lower weight than newer shares, which demotivate cheater from switching between pools inside one round.
Matematically said, for every submitted share, pool perform:
 

score = score + exp(round_time/C)

So you will get relativly more BTC for one round, when you send shares close to the moment, when the solution is found and the round ends.
When I now submit shares in longer distances because of X-Roll-NTime, then the probability is higher that "a lot of other workers" send shares after me and gets more and more points for a round. So I'am interested to send results close to the end of a round, even if it are less shares. I will get proportionally more points for it.

For me it seems to be beeter to send shares more often to increase the odd, to be close to the end of a round and to get more points relativly to the others. It is an exponential function with the time. You said in your second point correctly, the odds of finding a share is the same, but the points I get for the shares depends on the time when I send. This is the way I understood the payment in this special pool (current hashrate: 1430.657 Ghash/s).

With your fourth point you gave me an explanation how to disable the feature. And after some rounds today it seems to be, that the average BTC for each round is higher, in each case closer together and the fluctuation in earnings per round seems smaller like yesterday. In any case, it feels like it.

So I'am happy now , higher hashrate with Phoenix 2.0 and a higher average BTC for each round.

Thank you again for solving my problem!

[ssateneth]

Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

[jedi95]

Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

[ssateneth]

Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

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

[jedi95]

Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

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

That's part of the kernel, so it's drop-in compatible with RC2. Just replace the original __init__.py with the latest version from the repo.

[ssateneth]

Jedi, could you please push a windows build with the fix to allow 2.1 sdk to work with the newest phoenix beta? i've been stuck with rc1 for a long time, and I had to format to allow booting off ssd, but now my miner while using 2.1 sdk won't create shares (either accepted or rejected, nothing) even though it shows it hashing and my gpu temperature goes up. 5 minutes with no shares and 450mhash is not the result of randomness, its a bug :/

I also deleted all .elfs in the phatk2 plugins folder to make it recompile.

I need more information to isolate the problem.

Please test RC2 with the kernels from RC1. I need to know if the problem is at the kernel level or something else.

You already fixed it though IIRC, you just never made a windows build for the fix.

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

That's part of the kernel, so it's drop-in compatible with RC2. Just replace the original __init__.py with the latest version from the repo.

Would that work for phatk2 kernel? I see its in the opencl folder and not phatk2 folder, so I don't know if they are compatible with each other.
Edit: Never mind. I chose to not question you and update it anyways, and lo and behold its hashing away on 2.1 sdk. Thanks. Too bad I didn't realize this over a month ago. Sorry for wasting your time <.<

[blandead]

Would you be interested in integrating my vectors3 method into phoenix 2?

I've been testing it with phoenix 2 lately and I'm getting some good results

[kakobrekla]

[07:39:47] Warning: work queue empty, miner is idle
[07:49:25] [Juniper 0] Result 00000000f4e9d2ab... REJECTED
[07:59:12] Server gave new work; passing to WorkQueue
[07:59:12] New block (WorkQueue)
[07:59:32] Warning: work queue empty, miner is idle
[08:09:03] Disconnected from server
[08:13:54] Connected to server
[08:13:54] Server gave new work; passing to WorkQueue
[08:13:54] New block (WorkQueue)
[08:14:14] Warning: work queue empty, miner is idle
[08:19:53] Disconnected from server
[08:29:26] Connected to server
[08:29:26] Server gave new work; passing to WorkQueue
[08:29:26] New block (WorkQueue)
[08:29:47] Warning: work queue empty, miner is idle
[08:39:03] Disconnected from server
[08:43:55] [Juniper 0] Result 00000000ef3e0789... REJECTED
[08:50:17] Couldn't connect to server, switching backend...
[08:59:28] Connected to server
[08:59:28] Server gave new work; passing to WorkQueue
[08:59:28] New block (WorkQueue)
[08:59:29] Primary backend is available, switching back...
[08:59:29] Disconnected from server
[08:59:48] Warning: work queue empty, miner is idle
[09:09:28] Connected to server
[09:09:28] Server gave new work; passing to WorkQueue
[09:09:48] Warning: work queue empty, miner is idle
[09:19:29] [Juniper 0] Result 0000000067b871b3... REJECTED
[09:29:54] [Juniper 0] Result 000000006d839047... REJECTED
[09:40:18] Disconnected from server
[09:50:18] Connected to server
[09:50:18] Server gave new work; passing to WorkQueue
[09:50:18] New block (WorkQueue)
[09:50:39] Warning: work queue empty, miner is idle
[10:00:19] Disconnected from server
[10:10:20] [Juniper 0] Result 0000000089992964... REJECTED
[10:20:20] Couldn't connect to server, switching backend...
[10:30:20] Connected to server
[10:30:20] Server gave new work; passing to WorkQueue
[10:30:20] New block (WorkQueue)
[10:30:21] Primary backend is available, switching back...
[10:30:21] Disconnected from server
[10:30:40] Warning: work queue empty, miner is idle
[10:41:39] Connected to server
[10:41:39] Server gave new work; passing to WorkQueue
[10:41:39] New block (WorkQueue)
[10:41:59] Warning: work queue empty, miner is idle
[10:59:04] Disconnected from server
[11:09:30] [Juniper 0] Result 00000000d21685c6... REJECTED
[11:20:19] [Juniper 0] Result 00000000f670e890... REJECTED
[11:31:40] Connected to server
[11:31:40] Server gave new work; passing to WorkQueue
[11:31:40] New block (WorkQueue)
[11:32:01] Warning: work queue empty, miner is idle
[0 Khash/s] [242 Accepted] [63 Rejected] [RPC (+LP)]


After some time it comes to this and I have to reset phoenix. Sucks if it happens in the beginning of the night.
Two pools are configured yet phoenix can't get its shit together and mine.

Anyone has an idea whats the deal with this? Other mining software does not exhibit this behavior.