|
c00w (OP)
|
 |
August 19, 2011, 12:39:18 AM |
|
@crashing with interpolate error
That should be fixed. An unnamed person who wasn't me moved something down three lines.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
|
Keninishna
|
|
August 19, 2011, 01:13:32 AM |
|
For the page http://localhost:8337/stats you need to move the "backup" servers to the top of the page, right under the "mining" servers. It is so horrible that I can't see the servers that I actually care about without scrolling through a ton of crappy servers that I disabled and don't even want to look at. Please make the http://localhost:8337/stats page go something like... Mine Mine_slush+deepbit etc Backup Info Disabled Thank you. _______________________________________________ * Working as of newest version.Also, something is broke with the "pools.cfg" and this.[swepool] name: SwePool.net mine_address: swepool.net:8337 api_address: http://swepool.net/json?key=%(swepool_user_apikey)sapi_method: json api_key: round_shares api_key_hashrate: pool_speed api_key_duration: round_time api_key_duration_sec: (\d+) url: http://swepool.net/profileWith this in the pools.cfg, I crash no matter what. When I delete it, I have no problems. Not working in Windows 7.Just delete the disabled pools from user.cfg and they won't show in the stats page. |
|
|
|
|
joulesbeef
Sr. Member
 Offline
Activity: 476
Merit: 250
moOo
|
|
August 19, 2011, 01:26:41 AM |
|
D:\Users\joulesbeef\Desktop\currentminer\githopper>bithopper.py
Traceback (most recent call last):
File "D:\Users\joulesbeef\Desktop\currentminer\githopper\bitHopper.py", line 32, in <module>
from lpbot import LpBot
File "D:\Users\joulesbeef\Desktop\currentminer\githopper\lpbot.py", line 27
self.chan_list = []
^
IndentationError: unindent does not match any outer indentation level never mind.. fixed now |
mooo for rent
|
|
|
joulesbeef
Sr. Member
Offline
Activity: 476
Merit: 250
moOo
|
|
August 19, 2011, 01:33:40 AM |
|
|
mooo for rent
|
|
|
r2edu
Member
Offline
Activity: 68
Merit: 10
|
|
August 19, 2011, 01:58:20 AM |
|
optimal for efficiency, variance, or the best of both? Also what size pools are you using and how many of each?
this is my setup:  I´m starting with: "--auth xxxx,xxxx --scheduler OldDefaultScheduler --startLP --p2pLP" (v0.1.9.1-18) I don´t get the difference between efficiency and variance, I want more bitcoins! hehe ------ BTW, if I put a pool under "mine_deepbit", it still scrapping their stats? I ask that cause btcpool, for ex., is set as "mine_deepbit" but every time that resets their stats bh thinks they start a new block, so... are they announcing false blocks in the LP too?? And bclc have no idea how it works, the stats show some thing, bh other and sometimes they change their stats in it´s web (delayed i guess) but bh keeps counting the previous round, and other times bh shows 150% (ex.) and the pool stats show round duration of 9hs! I think that something is wrong |
|
|
|
|
joulesbeef
Sr. Member
Offline
Activity: 476
Merit: 250
moOo
|
|
August 19, 2011, 02:12:35 AM |
|
put btcpool on info.. they are broken.
|
mooo for rent
|
|
|
user7516
Newbie
Offline
Activity: 41
Merit: 0
|
|
August 19, 2011, 05:27:44 AM |
|
Log from cgminer: http://pastebin.com/kszzpHSL. As you see, connection with bH left every 5 second. Is it normal behavior? |
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
August 19, 2011, 05:57:44 AM |
|
put btcpool on info.. they are broken.
They've also started IP banning and tax 50% shares if you're there for less than half the round - even if you are a 2% donator. |
|
|
|
|
Keninishna
|
|
August 19, 2011, 05:59:04 AM |
|
I like how mtred goes from 150 gh/s to 400 gh/s on the start of a new round.
|
|
|
|
|
leveer
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 19, 2011, 10:19:20 AM |
|
Is there any progress on hopping deepbit and BTCGuild via LP announces, or also maybe in conjunction with pident?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
|
|
|
|
|
cirz8
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 19, 2011, 11:49:05 AM |
|
Here are my mine_deepbit stats using the AltSliceScheduler:
(full command line: --scheduler=AltSliceScheduler --altslicesize=180 --startLP --p2pLP)
Bitcoins.lc: 339
BTCGuild.com: 0
DeepBit: 17
PolMine.pl: 1369
Total Shares during the same period: 129.000
Version: no idea, how does one check? it's from the git 4 days ago
|
|
|
|
|
cirz8
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 19, 2011, 02:26:30 PM |
|
Just tried out the latest git, lots of API-errors. [16:10:14] Updating Difficulty
[16:10:19] 1805700.8361937
[16:10:19] Updating NameCoin Difficulty
[16:10:25] 94037.96
[16:10:25] Checking Database
[16:10:25] writing to database
[16:10:25] Selecting scheduler: AltSliceScheduler
[16:10:25] [scheduler-altslice] Initializing AltSliceScheduler...
[16:10:25] [scheduler-altslice] - Min Slice Size: 60
[16:10:25] [scheduler-altslice] - Slice Size: 180
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] Server change to btcpool24_pps
[16:10:25] Starting p2p LP
Connecting...
[16:10:25] bclc: 1805712 493.5gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] swepool: 4245274 4.2gh/s 28298min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] slush: 654984 1866.9gh/s 25min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://bitcoins.lc:8080/LP
[16:10:25] btcserv: 1159784
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] triple: 5824275
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://pit.deepbit.net:8332/listenChannel
[16:10:25] LP Call http://swepool.net:8337/LP
[16:10:25] LP Call http://su.mining.eligius.st:8337/LP
[16:10:25] deepbit: 1806047 5520.0gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://btcworld.de:8332/LP
Connect returned
[16:10:26] eligius: 3714571
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://arsbitcoin.com:8344/LP
[16:10:26] LP Call http://bitcoinmonkey.com:8332/LP
[16:10:26] bitclockers: 2279465 190.3gh/s
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcworld: 2378671
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://mtred.com:8837/LP
[16:10:26] LP Call http://uscentral.btcguild.com:8332/LP
[16:10:26] polmine: 2094070 146.0gh/s 956min.
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://pool.bitclockers.com:8332/LP
[16:10:26] btcpool24_prop: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcpool24_pps: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] digbtc: 573727
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] [scheduler-altslice] digbtc sliced to 180.00
[16:10:26] Server change to digbtc
[16:10:26] Error in pool api for digbtc
[16:10:26] LP Call http://digbtc.net:8332/LP
[16:10:26] mtred: 876616 196.5gh/s
[16:10:26] Error in pool api for mtred
[16:10:26] arsbitcoin: 206292
[16:10:26] Error in pool api for arsbitcoin
[16:10:26] LP Call http://pool.unitedminers.com:8332/LP/
[16:10:26] LP Call http://pool.bitminersunion.org:8341/LP
[16:10:26] btcmonkey: 4093595 2.1gh/s
[16:10:26] Error in pool api for btcmonkey
[16:10:26] RPC request [fb29d000] submitted to digbtc
[16:10:26] bcpool: 2813 187.6gh/s 1min.
[16:10:26] Error in pool api for bcpool
[16:10:26] LP Call http://ozco.in:8332/LP
[16:10:26] btcg: 1806228 2160.0gh/s
[16:10:26] Error in pool api for btcg
[16:10:27] ozco: 653252 212.2gh/s 222min.
[16:10:27] [scheduler-altslice] Re-Slicing...
[16:10:27] [scheduler-altslice] digbtc sliced to 95.83
[16:10:27] [scheduler-altslice] ozco sliced to 84.17
[16:10:27] Error in pool api for ozco
[bunch of works cut out]
[16:12:25] bclc: 1819610 497.3gh/s
[16:12:25] Error in pool api for bclc
[16:12:25] slush: 699186 1866.2gh/s 27min.
[16:12:25] Error in pool api for slush
[16:12:25] RPC request [f1aa5000] submitted to digbtc
[16:12:25] RPC request [411be000] submitted to digbtc
[16:12:25] swepool: 4245385 4.2gh/s 28300min.
[16:12:25] Error in pool api for swepool
[16:12:26] btcserv: 1159862
[16:12:26] Error in pool api for btcserv
[16:12:26] triple: 5824678
[16:12:26] Error in pool api for triple
[16:12:26] deepbit: 1960109 5504.0gh/s
[16:12:26] Error in pool api for deepbit
[16:12:26] Error in pool api for btcworld
[16:12:26] eligius: 3729500
[16:12:26] Error in pool api for eligius
[16:12:26] bitclockers: 2288996 190.0gh/s
[16:12:26] Error in pool api for bitclockers
[16:12:26] Error in pool api for digbtc
[16:12:26] Error in pool api for digbtc
[16:12:26] polmine: 2098468 146.0gh/s 956min.
[16:12:26] Error in pool api for polmine
[16:12:26] btcpool24_pps: 2240710
[16:12:26] Error in pool api for btcpool24_pps
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] RPC request [1fbc5000] submitted to digbtc
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] bcpool: 8484 187.6gh/s 1min.
[16:12:27] Error in pool api for bcpool
[16:12:27] Error in pool api for bcpool
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] btcg: 1866963 2155.0gh/s
[16:12:27] Error in pool api for btcg
[16:12:27] btcg: 1866977 2155.0gh/s
|
|
|
|
|
|
BurningToad
|
|
August 19, 2011, 03:12:00 PM |
|
After investigation I come to conclusion that arsbitcoins block/rate limit tcp connections and bitHopper tries to open new connections to the host until it runs out of free sockets. Disabling arsbitcoins helps, but I think there should be a better way for bitHopper to handle TCP timeouts/SYN-packets dropped by pools. I am not sure if http/1.1 keep-alive is implemented. But it could help to reduce stressing pools with huge load of new tcp connections.
You are correct, ArsBitcoin does rate limit/block TCP connections. Why does BitHopper needs to open up 1000+ TCP connections to my pool in order to mine? It seems to be just temporary, when trying to connect for the first time.... but yeah, its crazy. Occasionally I'll whitelist some of the IPs I see doing this, cause it doesn't seem to have too bad of an effect, but is this something that can be fixed? |
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
August 19, 2011, 03:32:34 PM |
|
After investigation I come to conclusion that arsbitcoins block/rate limit tcp connections and bitHopper tries to open new connections to the host until it runs out of free sockets. Disabling arsbitcoins helps, but I think there should be a better way for bitHopper to handle TCP timeouts/SYN-packets dropped by pools. I am not sure if http/1.1 keep-alive is implemented. But it could help to reduce stressing pools with huge load of new tcp connections.
You are correct, ArsBitcoin does rate limit/block TCP connections. Why does BitHopper needs to open up 1000+ TCP connections to my pool in order to mine? It seems to be just temporary, when trying to connect for the first time.... but yeah, its crazy. Occasionally I'll whitelist some of the IPs I see doing this, cause it doesn't seem to have too bad of an effect, but is this something that can be fixed? hy, sorry to hear that seems like it's fixed in the latest version |
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1011
|
|
August 19, 2011, 03:48:10 PM |
|
Is there any progress on hopping deepbit and BTCGuild via LP announces, or also maybe in conjunction with pident?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable. Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining. The rest of your mining time should be spent with a temporally agnostic mining method such as solo (high variance), PPS (high fee or griefing problems), PPLNS (recommended, check out simplecoin.us for an example); mining at another proportional pool will nullify the advantages of this method. This method will give a better profit margin than solo mining for moderately sized 0% fee pools, more for larger pools, but is unfortunately inferior to a pool-hopping method which can use the pool's block discoveries to it's advantage. If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method. I'm afraid I'm not familiar enough with bitHopper to explain how to do this but I'd be surprised if it is difficult. |
|
|
|
|
cirz8
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 19, 2011, 04:13:15 PM |
|
I don't understand the details on how LP works.
Is it only the server that one has sent a LP-request to that sends a LP-reply when it has a new block, but it doesn't say it's name?
Or is there some kind of broadcast involved?
|
|
|
|
|
joulesbeef
Sr. Member
Offline
Activity: 476
Merit: 250
moOo
|
|
August 19, 2011, 06:16:13 PM |
|
put btcpool on info.. they are broken.
They've also started IP banning and tax 50% shares if you're there for less than half the round - even if you are a 2% donator. Ok they are my new most hated pool. If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable. HUh?.. Hop on deepbit for every single block found on the network? yeah thats pretty much the hopper not too long ago(not on purpose but in effect).. we are trying to fix that. It isnt very effecient. And you know using this method you describe we would be 60% of the time, wrong? The methods we are working on have a better success rate than that. Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining. so why do it? mining at another proportional pool will nullify the advantages of this method. how so? most of our other prop pools not set to "mine_deepbit" WE DO KNOW WHEN THEY FOUND A BLOCK.. plus we have chart porn.. have you seen our chart porn? . If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method. Thanks for the thought, but I dont agree. There are many ways and yours is probably the first we considered. You can also do the guess thing, but first see if any of your pools that give you proper info goes to zero, this reduces our error rate from 60% to about 20% then their is pident, which has it;s own method for guessing who got the block, there is a fork of c00ws trying just to use that. then there is the lp guess which works great for some pools for some people.. but not great for everyone.(and there are at least two different methods of this) then there is the voting method.. which every client reports it;s best guess.. this should work better than the previous method for everyone.. and we are working on this method as well. Sorry but I just dont think hopping on deepbit on every block announce will be as good as the things we have tried and it is the first thing people think to do, as deepbit finds 40% of all the blocks on the network. |
mooo for rent
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1011
|
|
August 19, 2011, 07:49:10 PM |
|
put btcpool on info.. they are broken.
They've also started IP banning and tax 50% shares if you're there for less than half the round - even if you are a 2% donator. Ok they are my new most hated pool. If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable. HUh?.. Hop on deepbit for every single block found on the network? yeah thats pretty much the hopper not too long ago(not on purpose but in effect).. we are trying to fix that. It isnt very effecient. And you know using this method you describe we would be 60% of the time, wrong? The methods we are working on have a better success rate than that. Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining. so why do it? mining at another proportional pool will nullify the advantages of this method. how so? most of our other prop pools not set to "mine_deepbit" WE DO KNOW WHEN THEY FOUND A BLOCK.. plus we have chart porn.. have you seen our chart porn? . If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method. Thanks for the thought, but I dont agree. There are many ways and yours is probably the first we considered. You can also do the guess thing, but first see if any of your pools that give you proper info goes to zero, this reduces our error rate from 60% to about 20% then their is pident, which has it;s own method for guessing who got the block, there is a fork of c00ws trying just to use that. then there is the lp guess which works great for some pools for some people.. but not great for everyone.(and there are at least two different methods of this) then there is the voting method.. which every client reports it;s best guess.. this should work better than the previous method for everyone.. and we are working on this method as well. Sorry but I just dont think hopping on deepbit on every block announce will be as good as the things we have tried and it is the first thing people think to do, as deepbit finds 40% of all the blocks on the network. I must admit I am not fully aware of the current pool-hopping capabilities and am speaking in general. I thought that one standard method that big proportional pools used to try to reduce pool hopping is to try and hide when new blocks were found by the pool. I only meant to suggest that even if they are perfectly successful and it is impossible to tell when a certain pool has found a block you could still use the idea behind pool hopping to make some gains using only the information in the bitcoin network. If you have any information on when a pool finds a block beyond the bitcoin network new-block announcements then you will certainly do better with the standard method. A quick look at pident suggests that it is quite easy to tell when a certain pool has finished a block so I assume that the remaining problem is finding a pool which doesn't detect and ban pool-hopping behaviour. Again, I know little about the existing practical situation and am speaking purely in terms of theory and mathematics. I'm sure if I mined with a proportional pool I'd know more but I'm with simplecoin.us (which uses PPLNS) specifically so I don't have to worry about implementing pool hopping. The "guess thing" you describe is a good idea when you have partial information. All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large). |
|
|
|
|
joulesbeef
Sr. Member
Offline
Activity: 476
Merit: 250
moOo
|
|
August 19, 2011, 08:09:25 PM |
|
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large). cool with out a doubt it is a strategy that can work on pools the size of deepbit. Pident is ok.. but does have high error rate as well. Higher for some pools than others but it is an option. The only truely effective anti hopping technique is a fair payout system. The rest can be gotten around by means of varying difficulty... derpbit being one of the hardest. not every pool hates us.. which is nice. IMO the best payout method that keeps us happy and their users happy, is to have a choice between prop and pps. WE could then hop them on prop, and use pps for backup and set back up to jump to the poll with the most shares over all. This way when they are on a really long block(and hate us the most at this time, mainly cause we are not there), we can come back and help them finish it out.(which we do on occasion anyways for pools we like even if they dont have pps) And we can be quite effective at ending blocks from hell. An extra 150gh is a welcome site when you are on a 5 million plus share drought. |
mooo for rent
|
|
|
cirz8
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 19, 2011, 08:22:12 PM |
|
Tried a newer version(commit bbe980b1d7fa3284c6b6e02cbe0297789c31e5fd was the latest at the time) and now no API-errors  Just tried out the latest git, lots of API-errors. [16:10:14] Updating Difficulty
[16:10:19] 1805700.8361937
[16:10:19] Updating NameCoin Difficulty
[16:10:25] 94037.96
[16:10:25] Checking Database
[16:10:25] writing to database
[16:10:25] Selecting scheduler: AltSliceScheduler
[16:10:25] [scheduler-altslice] Initializing AltSliceScheduler...
[16:10:25] [scheduler-altslice] - Min Slice Size: 60
[16:10:25] [scheduler-altslice] - Slice Size: 180
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] Server change to btcpool24_pps
[16:10:25] Starting p2p LP
Connecting...
[16:10:25] bclc: 1805712 493.5gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] swepool: 4245274 4.2gh/s 28298min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] slush: 654984 1866.9gh/s 25min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://bitcoins.lc:8080/LP
[16:10:25] btcserv: 1159784
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] triple: 5824275
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://pit.deepbit.net:8332/listenChannel
[16:10:25] LP Call http://swepool.net:8337/LP
[16:10:25] LP Call http://su.mining.eligius.st:8337/LP
[16:10:25] deepbit: 1806047 5520.0gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://btcworld.de:8332/LP
Connect returned
[16:10:26] eligius: 3714571
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://arsbitcoin.com:8344/LP
[16:10:26] LP Call http://bitcoinmonkey.com:8332/LP
[16:10:26] bitclockers: 2279465 190.3gh/s
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcworld: 2378671
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://mtred.com:8837/LP
[16:10:26] LP Call http://uscentral.btcguild.com:8332/LP
[16:10:26] polmine: 2094070 146.0gh/s 956min.
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://pool.bitclockers.com:8332/LP
[16:10:26] btcpool24_prop: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcpool24_pps: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] digbtc: 573727
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] [scheduler-altslice] digbtc sliced to 180.00
[16:10:26] Server change to digbtc
[16:10:26] Error in pool api for digbtc
[16:10:26] LP Call http://digbtc.net:8332/LP
[16:10:26] mtred: 876616 196.5gh/s
[16:10:26] Error in pool api for mtred
[16:10:26] arsbitcoin: 206292
[16:10:26] Error in pool api for arsbitcoin
[16:10:26] LP Call http://pool.unitedminers.com:8332/LP/
[16:10:26] LP Call http://pool.bitminersunion.org:8341/LP
[16:10:26] btcmonkey: 4093595 2.1gh/s
[16:10:26] Error in pool api for btcmonkey
[16:10:26] RPC request [fb29d000] submitted to digbtc
[16:10:26] bcpool: 2813 187.6gh/s 1min.
[16:10:26] Error in pool api for bcpool
[16:10:26] LP Call http://ozco.in:8332/LP
[16:10:26] btcg: 1806228 2160.0gh/s
[16:10:26] Error in pool api for btcg
[16:10:27] ozco: 653252 212.2gh/s 222min.
[16:10:27] [scheduler-altslice] Re-Slicing...
[16:10:27] [scheduler-altslice] digbtc sliced to 95.83
[16:10:27] [scheduler-altslice] ozco sliced to 84.17
[16:10:27] Error in pool api for ozco
[bunch of works cut out]
[16:12:25] bclc: 1819610 497.3gh/s
[16:12:25] Error in pool api for bclc
[16:12:25] slush: 699186 1866.2gh/s 27min.
[16:12:25] Error in pool api for slush
[16:12:25] RPC request [f1aa5000] submitted to digbtc
[16:12:25] RPC request [411be000] submitted to digbtc
[16:12:25] swepool: 4245385 4.2gh/s 28300min.
[16:12:25] Error in pool api for swepool
[16:12:26] btcserv: 1159862
[16:12:26] Error in pool api for btcserv
[16:12:26] triple: 5824678
[16:12:26] Error in pool api for triple
[16:12:26] deepbit: 1960109 5504.0gh/s
[16:12:26] Error in pool api for deepbit
[16:12:26] Error in pool api for btcworld
[16:12:26] eligius: 3729500
[16:12:26] Error in pool api for eligius
[16:12:26] bitclockers: 2288996 190.0gh/s
[16:12:26] Error in pool api for bitclockers
[16:12:26] Error in pool api for digbtc
[16:12:26] Error in pool api for digbtc
[16:12:26] polmine: 2098468 146.0gh/s 956min.
[16:12:26] Error in pool api for polmine
[16:12:26] btcpool24_pps: 2240710
[16:12:26] Error in pool api for btcpool24_pps
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] RPC request [1fbc5000] submitted to digbtc
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] bcpool: 8484 187.6gh/s 1min.
[16:12:27] Error in pool api for bcpool
[16:12:27] Error in pool api for bcpool
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] btcg: 1866963 2155.0gh/s
[16:12:27] Error in pool api for btcg
[16:12:27] btcg: 1866977 2155.0gh/s
|
|
|
|
|
|
