I have a doubt.
I have one rig with 2 5850...
When I set the GPU1 (device 1) with frames=1, I get about 348/349 mhash constantly...
so when I turn on the GPU0, no matter with frames, I get lower mhash and the GPU1 drops its mhash...
is that normal?
both cards have the exactly same configuration and they are the same model...
in my mind I though I could set both cards with frames=1 and get the 348/349 mhash individually.. besides the desktop lag
Topic: python OpenCL bitcoin miner - page 7. (Read 1239035 times)
Got a problem yesterday, when I checked the miner which had 4 servers for main + fallover it couldn't connect to any of them, although connection was up.
When I restarted the client - everything started to work.
Please check, I think some resource is getting exhausted upon reconnects to fallover servers.
When I restarted the client - everything started to work.
Please check, I think some resource is getting exhausted upon reconnects to fallover servers.
...and how does the client inform the server that it supports this feature?
There is version in user-agent, server can determine miner and act accordingly.
Sorry, this is not scalable approach. Please re-think.
If all miners implement this, then each pool server must implement version checking code for every supported miner. Each pool server must update their source code for each updated or new miner.
In contrast, if a miner client provides "X-Feature-Supported" in HTTP headers, then there is a simple check in the server that never needs to be updated.
User-Agent is the wrong approach.
Same for me in both windows and linux
It prints newlines on every hash rate update when run in lxterminal (linuxcoin).
Anyone experience the same? Know why?
EDIT: was told this is because of the width of the terminal window. There is some extra whitespace after the hash rate text which wraps around to form blank lines if the the terminal window isn't wide enough.
Anyone experience the same? Know why?
EDIT: was told this is because of the width of the terminal window. There is some extra whitespace after the hash rate text which wraps around to form blank lines if the the terminal window isn't wide enough.
Failover failed cuz there were no server change (it didnt react on such message)
Again, message 'Deepbit is temporaly unavailable' - which for me is equal to connection problems, but failover fails... Failover module must be more exact
Did you check your own connection? If primary and failover fail, it may be your connections, I have not seen any connection fails in the last 24hrs
Again, message 'Deepbit is temporaly unavailable' - which for me is equal to connection problems, but failover fails... Failover module must be more exact
With the last version of this minner I get less 10 MH/s in my NVIDIA GTS 250.
M0mchil, the help message for the failback parameter still refers to "2" instead of the new default "10":
Code:
group.add_option('-b', '--failback', dest='failback', default=10, help='attempt to fail back to the primary pool every N getworks, [b]default 2[/b]', type='int')
something is wrong with LP, I got rejected shares over 30 seconds after LP message shows up
Please note syntax is updated. Use:
poclbm.py user1:pass1@host1:port1#serv1 user2:pass2@host2:port2#serv2 user3:pass3@host3:port3#serv3
... instead of ...
poclbm.py --servers=serv1,serv2,serv3
... or ...
poclbm.py --user=x --password=x --host=x --port=x --backup=x
(miner will failover from serv1 to serv2 and serv3 if neccessary)
poclbm.py user1:pass1@host1:port1#serv1 user2:pass2@host2:port2#serv2 user3:pass3@host3:port3#serv3
... instead of ...
poclbm.py --servers=serv1,serv2,serv3
... or ...
poclbm.py --user=x --password=x --host=x --port=x --backup=x
(miner will failover from serv1 to serv2 and serv3 if neccessary)
...and how does the client inform the server that it supports this feature?
There is version in user-agent, server can determine miner and act accordingly.
- most of JSON-RPC fields made optional (to reduce pools bandwidth)
...and how does the client inform the server that it supports this feature?
From the server's perspective, it must support may different clients, and cannot know if 'target' or 'midstate' is optional without additional information.
New version is up
Changes:
- support for server provided failback hosts
- most of JSON-RPC fields made optional (to reduce pools bandwidth)
- increased default primary server retry interval to 10 getworks
- moved job processing to main thread
- improvements by gominoa, enolan @ github - options separation, server names, quiet output
Changes:
- support for server provided failback hosts
- most of JSON-RPC fields made optional (to reduce pools bandwidth)
- increased default primary server retry interval to 10 getworks
- moved job processing to main thread
- improvements by gominoa, enolan @ github - options separation, server names, quiet output
Can enyone explain --estimate function? I dont get it. Also compiling a windows version would be nice.
From the read me in the sources, it looks like the window of time that the average rate is calculated 900 secs = 15 min window (the last 15mins of hash rates are averaged) and displayed.
From: https://github.com/m0mchil/poclbm
Can enyone explain --estimate function? I dont get it. Also compiling a windows version would be nice.
Is there not a fallback command for Linux or what? It works on Windows...
New version today omits the --servers= part of the command line
update via command line
$ cd poclbm
$ git pull
get the options using
$ ./poclbm --help
Update your shell scripts or command line to reflect new option structure
Are you sure that you are passing a list of servers to "--servers" ?
What do you mean?
New version today omits the --servers= part of the command line
update via command line
$ cd poclbm
$ git pull
get the options using
$ ./poclbm --help
Update your shell scripts or command line to reflect new option structure
Is there not a fallback command for Linux or what? It works on Windows...
Are you sure that you are passing a list of servers to "--servers" ?
What do you mean?
Im getting similar errors:
EDIT: Also, a couple of miners have gone into a kind of a loop where it fails to connect to firs server, connects to second server and after 1 second tries to connect again to first server, fails, connects to second to second server, after 1 second tries to connect again to first server, fails,... (-failback = 1)
Code:
useast.btcguild.com:8332 08/07/2011 07:42:54, Setting pool xxxxxx_xxxxxxx @ useast.btcguild.com:8332
useast.btcguild.com:8332 08/07/2011 07:42:56, long poll exception:
Traceback (most recent call last):
File "/home/ben/poclbm_old/BitcoinMiner.py", line 338, in longPollThread
(connection, result) = self.request(connection, url, self.headers)
File "/home/ben/poclbm_old/BitcoinMiner.py", line 299, in request
response = connection.getresponse()
File "/usr/lib/python2.7/httplib.py", line 1027, in getresponse
response.begin()
File "/usr/lib/python2.7/httplib.py", line 407, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 371, in _read_status
raise BadStatusLine(line)
BadStatusLine: ''
api.bitcoin.cz:8332 08/07/2011 07:42:58, Setting pool xxxxxx.xxxxxx @ api.bitcoin.cz:8332
api.bitcoin.cz:8332 08/07/2011 07:42:58, Attempting to fail back to primary pool
EDIT: Also, a couple of miners have gone into a kind of a loop where it fails to connect to firs server, connects to second server and after 1 second tries to connect again to first server, fails, connects to second to second server, after 1 second tries to connect again to first server, fails,... (-failback = 1)
Jump to: