Bitcoin Forum
March 30, 2024, 03:08:00 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
Author Topic: Phoenix - Efficient, fast, modular miner  (Read 760536 times)
Raulo
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
April 27, 2011, 12:26:47 PM
 #221

In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded.
This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.

What if the work queue is half full and new getwork with new midstate is received?

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
1711768080
Hero Member
*
Offline Offline

Posts: 1711768080

View Profile Personal Message (Offline)

Ignore
1711768080
Reply with quote  #2

1711768080
Report to moderator
1711768080
Hero Member
*
Offline Offline

Posts: 1711768080

View Profile Personal Message (Offline)

Ignore
1711768080
Reply with quote  #2

1711768080
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
CFSworks
Member
**
Offline Offline

Activity: 63
Merit: 10


View Profile
April 27, 2011, 12:47:24 PM
 #222

In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded.
This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.

What if the work queue is half full and new getwork with new midstate is received?

Do you mean a new getwork with a new previous block hash? Because midstate would change on
every new getwork regardless of whether it's based on a new block or not.

When a getwork with a new previous block comes in, however, the queue instantly purges itself
and tries to prevent the Phoenix kernel from running any of the old work (regardless of whether it's full or half-full).
This can result in the devices going idle for a short period of time, if Phoenix can't restock its queue fast enough to
feed them all with new work... but it's better than having them work on shares that are just going to get
dropped on the floor the moment they are received by the pool server, at any rate. Wink

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
April 27, 2011, 12:49:52 PM
 #223

So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
kindle
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
April 27, 2011, 12:57:53 PM
 #224

So taken together can it be summarize that askrate=10 is sufficient and the same as askrate=5?

William Reed
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
April 27, 2011, 01:00:38 PM
 #225

So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.
Raulo
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
April 27, 2011, 01:12:29 PM
 #226

Do you mean a new getwork with a new previous block hash? Because midstate would change on
every new getwork regardless of whether it's based on a new block or not.

I'm curious how both situations are handled.

Quote
When a getwork with a new previous block comes in, however, the queue instantly purges itself
and tries to prevent the Phoenix kernel from running any of the old work (regardless of whether it's full or half-full).

Does it mean that the work is dropped only if the hash of previous block changes (good idea), otherwise new getwork is just added to the queue? I'm not sure how bitcoin daemon would handle a proof-of-work for old midstate that have current prevblock (e.g. in case of only merkleroot changed due to new transactions). Would it  be accepted?


1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
April 27, 2011, 01:14:07 PM
 #227

So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.

Yeah, I tried it both ways with the same result.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
luffy
Hero Member
*****
Offline Offline

Activity: 607
Merit: 500



View Profile
April 27, 2011, 01:18:30 PM
 #228

if you lower the aggression? perhaps to 10
William Reed
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
April 27, 2011, 01:21:50 PM
 #229

So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.

Yeah, I tried it both ways with the same result.


How many GPUs are you running? Are they all mining? How much CPU are they hogging? You could also try putting the miner in verbose mode (with -v flag) to see any possible errors.
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
April 27, 2011, 01:34:33 PM
 #230

How many GPUs are you running? Are they all mining? How much CPU are they hogging? You could also try putting the miner in verbose mode (with -v flag) to see any possible errors.

3 Miners (two are poclbm) on 3 5870's.  CPU usage is virtually nothing... 0.35 0.13 0.21

No errors shown with the -v flag.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
luffy
Hero Member
*****
Offline Offline

Activity: 607
Merit: 500



View Profile
April 27, 2011, 01:51:41 PM
 #231

Is there a possibility for 6xxx series cards to have a unique command (like BFI_INT) to make them more profitable than 5xxx?
i wonder....
drgr33n
Sr. Member
****
Offline Offline

Activity: 308
Merit: 251



View Profile
April 27, 2011, 02:06:03 PM
 #232

muchas gracias senor

With today's version my stale shares has dropped from 3.5% to 0% Cheesy !! As for the comment about BFI_INT for 6XXX cards. Phoenix runs exactly the same as poclbm without BFI_INT on my xfx 5830 xxx edition. With it I get the extra boost and it steadily sits around 267MH/s.

I'm runing debian sid with catalyst 11.3 installed via the ATI packages, fglrx version 8.831.2-110308a-115935C-ATI and AMD APP v2.4.

oh and todays version of phoenix from trunk Cheesy.
grndzero
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
April 27, 2011, 04:53:26 PM
 #233

So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


Try different AGGRESSION .. 12 was better than 13 or 11 for me.
Try lowering the WORKSIZE to 64, and try it without it completely.

Adding WORKSIZE, not matter what size, dropped my speed 10 Mh/s. I haven't had a problem running without it.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
JWU42
Legendary
*
Offline Offline

Activity: 1666
Merit: 1000


View Profile
April 27, 2011, 06:09:12 PM
 #234



Adding WORKSIZE, not matter what size, dropped my speed 10 Mh/s. I haven't had a problem running without it.

If not specified it defaults to your cards spec -- probably increased from 128 to 256 I would guess.

frankiebits
Full Member
***
Offline Offline

Activity: 155
Merit: 100



View Profile
April 27, 2011, 06:57:29 PM
 #235

Thank you sir, got my vapor x 5870 from 375 to 415 without any changes to hardware settings. Here is what works for me if anyone is interested

phoenix -u http://email@gmail.com:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10 WORKSIZE=2056
EgoPaintedGrey
Member
**
Offline Offline

Activity: 77
Merit: 10


View Profile
April 27, 2011, 06:58:28 PM
 #236

Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.

grndzero
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
April 27, 2011, 07:18:51 PM
 #237

Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.



So far I have only seen mine do that right before a Long Poll update when a block was found.

What were the circumstances? Was it right before or after a Long Poll Update? What pool are you using?

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
tripper22
Full Member
***
Offline Offline

Activity: 188
Merit: 100



View Profile
April 27, 2011, 07:22:42 PM
 #238

Nice work guys! I get the following warning messages right after I start up my miners (version 1.3).

KernelInterface.py:195: DeprecationWarning: struct integer overflow masking is deprecated hashInput = pack('>76sI', staticData, nonce)

KernelInterface.py:210: DeprecationWarning: struct integer overflow masking is deprecated formattedResult = pack('<76sI', nr.unit.data[:76], nonce)

But it seems to work great after the warnings. I'm using Ubuntu 10.10 SDK 2.1 with four 5870's.

Thanks in advance for any help.
travex
Member
**
Offline Offline

Activity: 158
Merit: 10


View Profile
April 27, 2011, 09:42:37 PM
 #239

Hi guys, what is the command line for mining solo ?
dbitcoin
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500

BTCDig - mining pool


View Profile WWW
April 27, 2011, 10:19:47 PM
 #240

Code:
Unhandled error in Deferred:
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 354, in _startRunCallbacks
    self._runCallbacks()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 330, in _continue
    self.unpause()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 325, in unpause
    self._runCallbacks()
--- <exception caught here> ---
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 244, in <lambda>
    d.addErrback(lambda x: self._failure())
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 307, in _failure
    self._setLongPollingPath(None)
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 174, in _setLongPollingPath
    self.activeLongPoll.cancel()
exceptions.AttributeError: Deferred instance has no attribute 'cancel'

BTCDig - mining pool (Stratum, VarDiff, DGM, SSL, JSON API)
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!