Topic: [masterpool.eu] DISCONTINUED - shut down at the end of February - page 2. (Read 8945 times)
November 08, 2011, 01:19:50 AM
Please find some updated information about the pools status on the blog: http://blog.masterpool.eu/2011/11/current-pool-status/
October 30, 2011, 04:43:29 AM
your survey is invalid, 80% of those who didn't vote obviously do not want any changes otherwise they would vote, rest who voted are 54% vs. 46%
if you want a change - do it, but don't claim it was voted for, let's see what happen with those 80% that haven't voted, will they leave or stay?
if you want a change - do it, but don't claim it was voted for, let's see what happen with those 80% that haven't voted, will they leave or stay?
From what I can tell most of those 80% who didn't vote were inactive for quite some time. For sure they didn't either respond to the invitation to the survey nor to the reminder send out after some time. Thus I guess they already left or they didn't care. Nearly 20% response rate on a customer survey with this preconditions is very good and quite representative.
October 30, 2011, 04:30:40 AM
your survey is invalid, 80% of those who didn't vote obviously do not want any changes otherwise they would vote, rest who voted are 54% vs. 46%
if you want a change - do it, but don't claim it was voted for, let's see what happen with those 80% that haven't voted, will they leave or stay?
if you want a change - do it, but don't claim it was voted for, let's see what happen with those 80% that haven't voted, will they leave or stay?
October 26, 2011, 10:06:33 AM
Some time ago I started a survey asking if MasterPool should change its reward type. Now the survey has been evaluated. Here are the most important points in a nutshell:
MasterPool will be changed into a PPLNS pool within the next weeks. Furthermore I won’t implement a PPS option. The most used ingress server is EU01. Thus if I need to dismantle one mining ingress server due to too low usage it will be US01. However if BTC prices rise again and MasterPool needs further ressources then the next server will be added in Asia right after the US followed by Australia.
Please find all information and the results of the survey on MasterPools blog: http://blog.masterpool.eu/2011/10/masterpool-member-survey-102011/
MasterPool will be changed into a PPLNS pool within the next weeks. Furthermore I won’t implement a PPS option. The most used ingress server is EU01. Thus if I need to dismantle one mining ingress server due to too low usage it will be US01. However if BTC prices rise again and MasterPool needs further ressources then the next server will be added in Asia right after the US followed by Australia.
Please find all information and the results of the survey on MasterPools blog: http://blog.masterpool.eu/2011/10/masterpool-member-survey-102011/
October 24, 2011, 12:14:49 PM
Here are more details on my system in case it helps:
Windows 7 64-bit
Intel i7 920 @ 2.67 overclocked to 3.2
9 GB RAM
ATI Radeon 5870
Catalyst Version 11.5
overclocked to 990 MHz core clock; 300 MHz memory clock; default voltage
Windows 7 64-bit
Intel i7 920 @ 2.67 overclocked to 3.2
9 GB RAM
ATI Radeon 5870
Catalyst Version 11.5
overclocked to 990 MHz core clock; 300 MHz memory clock; default voltage
October 24, 2011, 02:24:55 AM
Thank you for testing. I'll install some Windows to my Linux Box and try to reproduce it the next days. Honestly I don't undestand it, as last poclbm is running fine under linux. I have reports that it is working on windows without flaws as well. Perhaps this is a GUI miner speciality.
Today I got hands on a Windows PC and installed the latest version of GUI miner. However I only had the possibility to use CPU. But I guess this shouldn't make any difference for testing connection issues. It connected without a problem hashing at about poor 8 MHash/s. I waited some long polls and submitted a share. Is anybody out there who can confirm this issue?
October 23, 2011, 05:48:17 PM
Thank you for testing. I'll install some Windows to my Linux Box and try to reproduce it the next days. Honestly I don't undestand it, as last poclbm is running fine under linux. I have reports that it is working on windows without flaws as well. Perhaps this is a GUI miner speciality.
October 23, 2011, 05:13:13 PM
Furthermore I fixed some stuff that should make it better compatible with newer versions of mining software. If you have the time would you mind to test again with your current version of GUI miner?
Still getting the "AttributeError: 'HttpTransport' object has no attribute 'failure'" error.
When I set it up in 'GUIMiner v2011-08-24' I choose the "File > New miner > New OpenCL miner..." option, so it is running poclbm,
according to the GUIMiner thread:
GUI mining - updated Aug 24 with new miner versions
October 23, 2011, 04:38:27 PM
Is this problem occuring occasionally while mining or is it even impossible to connect to the pool?
It won't connect at all with that latest GUIMiner client but it worked fine with the last version, so the port and all the other information is correct.
I can use the old client if I use your pool. It is just a hassle as I say if I have to switch back and forth between clients due to this or that pool being
down. Just inquiring in case there was a known and easy solution I could use to avoid that hassle, but not a big deal if not.
I made a big bunch of improvements to the pool (have a look at the blog: http://blog.masterpool.eu/2011/10/the-quest-for-performance/). The pool is again running smooth with very low stales. Furthermore I fixed some stuff that should make it better compatible with newer versions of mining software. If you have the time would you mind to test again with your current version of GUI miner?
October 20, 2011, 04:53:39 PM
Is this problem occuring occasionally while mining or is it even impossible to connect to the pool?
It won't connect at all with that latest GUIMiner client but it worked fine with the last version, so the port and all the other information is correct.
I can use the old client if I use your pool. It is just a hassle as I say if I have to switch back and forth between clients due to this or that pool being
down. Just inquiring in case there was a known and easy solution I could use to avoid that hassle, but not a big deal if not.
October 20, 2011, 04:19:38 PM
BTW. Did a mod change the topic or am I getting paranoid 
October 20, 2011, 04:16:37 PM
Welcome back. Pool is back online and operational. Downtime was about 18 minutes. Thank you for your patience. Happy mining!
Still getting that "AttributeError: 'HttpTransport' object has no attribute 'failure'" error.
Slush's pool is back up though, but it is a hassle having to manually load up the old GUIMIner client to go to this pool when they go down, instead of an automatic fallback.
Mhmm, that's really strange. I'm not using guiminer. But after the database had some time to settle I'm now getting pure accepts from my miner. Don't know if you still care to sort out this problem. If yes. Is this problem occuring occasionally while mining or is it even impossible to connect to the pool? In the latter case have you chosen the right port? Unlike most BTC pools MasterPool uses port 8888.
As mentioned before I don't know much about GUI miners (as I'm using Linux). But poclbm has a neat failoverfeature. Perhaps you might want to give it a try?
October 20, 2011, 03:52:46 PM
Welcome back. Pool is back online and operational. Downtime was about 18 minutes. Thank you for your patience. Happy mining!
Still getting that "AttributeError: 'HttpTransport' object has no attribute 'failure'" error.
Slush's pool is back up though, but it is a hassle having to manually load up the old GUIMIner client to go to this pool when they go down, instead of an automatic fallback.
October 20, 2011, 03:24:46 PM
Quote
I analyzed the problem and found out, that the database is the bottleneck.
Huh, reminds me my times back in January :-). Good luck with update.
In most cases I'm quite confident that rollouts run flawles as I'm using only cfengine in order to administrate production servers
Unfortunately it doesn't prevent stupid mistakes while designing a database layout. Such as plugin would've come in handy. 
October 20, 2011, 03:21:29 PM
Welcome back. Pool is back online and operational. Downtime was about 18 minutes. Thank you for your patience. Happy mining!
October 20, 2011, 11:25:24 AM
Quote
I analyzed the problem and found out, that the database is the bottleneck.
Huh, reminds me my times back in January :-). Good luck with update.
October 20, 2011, 11:12:47 AM
When I try to connect to your pool using using the latest GUIMiner - v2011-08-24, I get this error:
2011-10-20 09:34:23: Listener for "masterpool" started
2011-10-20 09:34:23: Listener for "masterpool": Traceback (most recent call last):
2011-10-20 09:34:23: Listener for "masterpool": File "poclbm.py", line 67, in
2011-10-20 09:34:23: Listener for "masterpool": File "BitcoinMiner.pyo", line 34, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "HttpTransport.pyo", line 20, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "Transport.pyo", line 46, in __init__
2011-10-20 09:34:23: Listener for "masterpool": AttributeError: 'HttpTransport' object has no attribute 'failure'
That version of GUIMiner works with all other pools I have tried.
Thanks
2011-10-20 09:34:23: Listener for "masterpool" started
2011-10-20 09:34:23: Listener for "masterpool": Traceback (most recent call last):
2011-10-20 09:34:23: Listener for "masterpool": File "poclbm.py", line 67, in
2011-10-20 09:34:23: Listener for "masterpool": File "BitcoinMiner.pyo", line 34, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "HttpTransport.pyo", line 20, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "Transport.pyo", line 46, in __init__
2011-10-20 09:34:23: Listener for "masterpool": AttributeError: 'HttpTransport' object has no attribute 'failure'
That version of GUIMiner works with all other pools I have tried.
Thanks
Yeah, I'm sorry
I guess this is related to the problem above. It should be fixed after the rollout. October 20, 2011, 11:11:50 AM
With the recent amount of new users the pool faced a massive problem with high stales and was responding very slowly. I analyzed the problem and found out, that the database is the bottleneck. I prepared a solution but it means a major downtime for the pool. In order to circumvent the bottleneck I need to split some tables. This however took about 30 minutes on the testing mashine. I guess it'll be the same for the production database cluster (perhaps a bit more, as they are synchronizing themselves). In order to get the pool back on track. I'd like to roll out this update very soon and apologize for this short announcement. But as the pool sometimes stops responding for some seconds anyway I guess it's better to address this ASAP.
I'll start with the rollout at 8 pm UTC.
You may want to switch your miners to another pool for this time or make sure you have configured a failover pool.
I'll start with the rollout at 8 pm UTC.
You may want to switch your miners to another pool for this time or make sure you have configured a failover pool.
October 20, 2011, 11:06:13 AM
(registering to the thread)
October 20, 2011, 10:40:59 AM
When I try to connect to your pool using using the latest GUIMiner - v2011-08-24, I get this error:
2011-10-20 09:34:23: Listener for "masterpool" started
2011-10-20 09:34:23: Listener for "masterpool": Traceback (most recent call last):
2011-10-20 09:34:23: Listener for "masterpool": File "poclbm.py", line 67, in
2011-10-20 09:34:23: Listener for "masterpool": File "BitcoinMiner.pyo", line 34, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "HttpTransport.pyo", line 20, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "Transport.pyo", line 46, in __init__
2011-10-20 09:34:23: Listener for "masterpool": AttributeError: 'HttpTransport' object has no attribute 'failure'
That version of GUIMiner works with all other pools I have tried.
Thanks
2011-10-20 09:34:23: Listener for "masterpool" started
2011-10-20 09:34:23: Listener for "masterpool": Traceback (most recent call last):
2011-10-20 09:34:23: Listener for "masterpool": File "poclbm.py", line 67, in
2011-10-20 09:34:23: Listener for "masterpool": File "BitcoinMiner.pyo", line 34, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "HttpTransport.pyo", line 20, in __init__
2011-10-20 09:34:23: Listener for "masterpool": File "Transport.pyo", line 46, in __init__
2011-10-20 09:34:23: Listener for "masterpool": AttributeError: 'HttpTransport' object has no attribute 'failure'
That version of GUIMiner works with all other pools I have tried.
Thanks
Jump to: