Phoenix - Efficient, fast, modular miner - page 22.

jedi95

full member

Activity: 219

Merit: 120

Quote from: Mousepotato on June 15, 2011, 11:43:07 PM

Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back. I"m seeing the "miner is idle" lines again, although less frequent than before.

The problem that was fixed in 1.50 was the miner getting stuck idle due to a bug in the RPC protocol. You will still get "miner is idle" from time to time, but it shouldn't get stuck idle unless it can't connect to the server.

dikidera

full member

Activity: 126

Merit: 100

Hmm, for me, i see a drop of 2 Mhash/s with 1.50. Not something to kill for, but 2 mhash/s more is the equivalent of 5 mhz overclock for me.

Mousepotato

hero member

Activity: 896

Merit: 1000

Seal Cub Clubbing Club

Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back. I"m seeing the "miner is idle" lines again, although less frequent than before.

jedi95

full member

Activity: 219

Merit: 120

Quote from: RedLine888 on June 15, 2011, 05:04:05 PM

Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?

My guess is that hashkill has less overhead from host <--> device transfers:

Quote from: gat3way on June 10, 2011, 05:28:04 PM

Another thing is (don't know if that's possible with pyopencl) - don't use clenqueuereadbuffer() (or whatever it's equivalent is). Use clenqueuemapbuffer() instead. It's noticably faster. Hm really started wondering about modifying some python miner to incorporate that kernel there, looks like a quick way to make it portable to windows. Besides, there are obvious problems with the non-ocl part which are due to code inmaturity.

I have looked at the hashkill OpenCL kernel in AMD's KernelAnalyzer and theoretically it should be the same speed as phatk on SDK 2.4

RedLine888

full member

Activity: 236

Merit: 109

Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?

SchizophrenicX

member

Activity: 112

Merit: 100

"I'm not psychic; I'm just damn good"

Quote from: jedi95 on June 14, 2011, 06:10:50 PM

Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)

@SchizophrenicX

You need to add the port after the server:

http://username.workername:[email protected]:8332

Nope. Didn't work. seriously. am I the only one kept having problems keeping a dedicated rig running 24/7 I really need some help

bongo

newbie

Activity: 9

Merit: 0

1.50 works well

, stales have come down a bit Grin

jedi95

full member

Activity: 219

Merit: 120

Quote from: niooron on June 15, 2011, 11:56:55 AM

Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?

This can happen if the share was already being sent when the LP request returned a new block. Shares are checked against the current block before being sent, but after that there are no further checks.

niooron

full member

Activity: 193

Merit: 100

Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?

Nachtwind

hero member

Activity: 700

Merit: 507

Ok, started without BFI_INT and with commands put together like suggested:
It seems to be doing "Something".

Code:

2011-06-15 08:36:09: Listener für "btc" gestartet
2011-06-15 08:36:10: Listener für "btc": [15/06/2011 08:36:10] Phoenix 1.50 starting...

Then nothing (no more console output) - but my shares on BTCGuild are increasing. Yet without BFI_INT i have a performance drop of roughly 20% to 25%

Now with BFI_INT and commands put together in the new order there is still no console output but it seems to work with about 5% less MH (compared to 1.48).

In case you dont see a reason for your software behaving that odd - i have a shitload of SDKs on this PC and there might be something interfering somewhere... wouldnt be the first software...

d.james

sr. member

Activity: 280

Merit: 250

Firstbits: 12pqwk

new version works flawlessly with the phoenix rising guiminer here

innervisi0nn

member

Activity: 98

Merit: 10

Tutorials, guidelines, optimizations for all!

[14/06/2011 22:23:17] Phoenix 1.50 starting...
[14/06/2011 22:23:17] Connected to server
MSG: upstream RPC error
[14/06/2011 22:23:40] Disconnected from server
[14/06/2011 22:23:54] Warning: work queue empty, miner is idle
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

getting that issue...only with 2 pools tho, any idea?

brunoshady

sr. member

Activity: 262

Merit: 250

Dubs Get

Quote from: Nachtwind on June 14, 2011, 08:38:18 PM

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:[email protected]:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

try the command like this, yours is very confused...

phoenix -v -u http://xxxx:[email protected]:8332 -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=5

Clipse

hero member

Activity: 504

Merit: 502

Heres a pickle, I seem to get 3mhash on the dot less on 4 rigs i just updated with 1.50 from 1.48 with same arguments used.

Retried with 1.48 and hashrate went up exactly 3mhash o_0

Is there a reason for the slight drop, or is 1.48 reporting wrong hashrate ?

BitMinerN8

hero member

Activity: 626

Merit: 500

Mining since May 2011.

Quote from: jedi95 on June 14, 2011, 10:00:39 PM

Quote from: Nachtwind on June 14, 2011, 08:38:18 PM

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:[email protected]:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?

For testing I have put this on a number of rigs (4 of 12) in my farm and am not having any issues like you are describing. I am not using GUIMiner though, just running it through command prompt/script. All my mining rigs are extremely clean, just Win7 x64 w/SP1, the ATI Drivers with only the AMD APP/SDK selected, then I use ATI Tray Tools for the OC. Set to autologin and run the scripts. Options:
-k phatk PLATFORM=0 DEVICE=1 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=11

jedi95

full member

Activity: 219

Merit: 120

Quote from: Nachtwind on June 14, 2011, 08:38:18 PM

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:[email protected]:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?

Nachtwind

hero member

Activity: 700

Merit: 507

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:[email protected]:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

BitMinerN8

hero member

Activity: 626

Merit: 500

Mining since May 2011.

Quote from: jedi95 on June 14, 2011, 06:10:50 PM

Version 1.50 has been released.

Thanks! I'll start updating the farm. Tongue

jedi95

full member

Activity: 219

Merit: 120

Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)

@SchizophrenicX

You need to add the port after the server:

http://username.workername:[email protected]:8332

SchizophrenicX

member

Activity: 112

Merit: 100

"I'm not psychic; I'm just damn good"

yea. I'm having windows trouble right now and I have been trying to get my miners running on linux since it's free. I don't even have a working windows machine right now unfortunately... although at this moment it seems like one of my old XP machine is able to restore it's OS from a recovery partition.

Anyway... Here is what shows in terminal

Code:

me@ubuntu:~/poclbm$ ./poclbm.py
No device specified or device not found, use -d to specify one of the following

[0] AMD Phenom(tm) II X4 B55 Processor
[1] Cypress
[2] Cypress
[3] Cypress
[4] Cypress
[5] Cypress
me@ubuntu:~/poclbm$ cd ../phoenix
me@ubuntu:~/phoenix$ ./phoenix.py -u http://username.workername:[email protected] -k phatk DEVICE=1 VECTORS BFI_INT WORKSIZE=256 AGGRESSION=7
[15/06/2011 01:47:29] Phoenix r101 starting...
[15/06/2011 01:47:30] Failed to connect, retrying...
[15/06/2011 01:47:45] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]^Cme@ubuntu:~/phoenix$ cd ../poclbm
wenbin@Binbuntu:~/poclbm$ ./poclbm.py -d1 -o api.bitcoin.cz -u username.workername --pass=workerpassword -v -w256 -f30
15/06/2011 01:48:39, 0b7c45c9, accepted
15/06/2011 01:48:44, f2c5f913, accepted
299841 khash/s

Topic: Phoenix - Efficient, fast, modular miner - page 22. (Read 760701 times)