Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 196. (Read 499702 times)
August 13, 2011, 09:26:05 AM
Just a question. My estimate on the current block is around 0.058 (I have a low hashrate). If I stop mining right now for gaming how much will I lose as time goes by? It's not going up from 0.058 for a long time now.
August 13, 2011, 09:22:23 AM
Now it's a long block 
Is this with tweaks to httpd.conf & my.cnf to ensure full throughput? Defaults on most systems are much too conservative to allow the proxy to keep up with very many requests.
What sort of tweaks are you referring to? It's going to be hard to overcome the http setup overhead.
(...)So, I've been running some tests on Bitcoin Mining Proxy.(...)
Is this with tweaks to httpd.conf & my.cnf to ensure full throughput? Defaults on most systems are much too conservative to allow the proxy to keep up with very many requests.
What sort of tweaks are you referring to? It's going to be hard to overcome the http setup overhead.
August 13, 2011, 06:29:03 AM
btc guild was/is being ddosed, irc lit up.
August 13, 2011, 05:30:06 AM
Now it's gone up. 
August 13, 2011, 12:50:59 AM
Na, we aren't even to difficulty yet, still at about +15%
August 13, 2011, 12:34:45 AM
Another huge block. 
August 12, 2011, 02:18:02 PM
Huh... we just passed 100 GHs. What's behind the increase?
So, I've been running some tests on Bitcoin Mining Proxy.
My test system is a VM running effectively nothing but BMP, bitHopper and the requisite requirements on a 30 Mbps symmetric connection.
BMP does not appear to scale very well, which I somewhat suspected from the start, since the overhead of Apache and HTTP setup would introduce lag. As the GH/s increase, the lag becomes a meaningful and ever increasing amount of your hash rate. From my tests, BMP saps approximately 12 - 20% of your hashing power in overhead. In my case, pushing 12 GH/s through it yielded ~9.85 - ~10 GH/s on average.
At lower hash rates, this decreased and at single card hashrates the difference may not be noticeable with out precise statistics. Even then, it may get lost in variance noise - but you are still losing the hashing power.
This can probably be mitigated by using a dedicated machine or even your localhost, though I have not tested either of these scenarios. I suspect from years of experience that in the likely event that you improve your hashrate you will never eliminate it due to the overhead of the connection setup. As miners get more efficient and profit margins become thinner and thinner, even small amounts of efficiency improvement are going to make a difference - possibly the difference between being in the red and in the black given energy costs.
The proxy idea is a good one, but unfortunately, it would likely need to be implemented at a much lower level than scripted PHP to be competitive.
This finding is a disappointment to me. I have some distributed miners and the majority of my miners are behind a NAT that I have no desire to open up to the outside world - the proxy is exceptionally convenient for me to redirect the miners or turn one or two off and on to test functionality on the pool. I have to manage 35 miners, and the proxy would make that much easier... but not at the cost of 2+ GH/s.
So, anyway, I thought I'd throw that out there for those of you using it to consider.
So, I've been running some tests on Bitcoin Mining Proxy.
My test system is a VM running effectively nothing but BMP, bitHopper and the requisite requirements on a 30 Mbps symmetric connection.
BMP does not appear to scale very well, which I somewhat suspected from the start, since the overhead of Apache and HTTP setup would introduce lag. As the GH/s increase, the lag becomes a meaningful and ever increasing amount of your hash rate. From my tests, BMP saps approximately 12 - 20% of your hashing power in overhead. In my case, pushing 12 GH/s through it yielded ~9.85 - ~10 GH/s on average.
At lower hash rates, this decreased and at single card hashrates the difference may not be noticeable with out precise statistics. Even then, it may get lost in variance noise - but you are still losing the hashing power.
This can probably be mitigated by using a dedicated machine or even your localhost, though I have not tested either of these scenarios. I suspect from years of experience that in the likely event that you improve your hashrate you will never eliminate it due to the overhead of the connection setup. As miners get more efficient and profit margins become thinner and thinner, even small amounts of efficiency improvement are going to make a difference - possibly the difference between being in the red and in the black given energy costs.
The proxy idea is a good one, but unfortunately, it would likely need to be implemented at a much lower level than scripted PHP to be competitive.
This finding is a disappointment to me. I have some distributed miners and the majority of my miners are behind a NAT that I have no desire to open up to the outside world - the proxy is exceptionally convenient for me to redirect the miners or turn one or two off and on to test functionality on the pool. I have to manage 35 miners, and the proxy would make that much easier... but not at the cost of 2+ GH/s.
So, anyway, I thought I'd throw that out there for those of you using it to consider.
Have you tried smartcoin? I use it's profiles in combination with a Web UI I wrote to control my 4 rigs from my iPhone, Work or wherever.
August 12, 2011, 01:41:48 PM
Why so?
The higher the hash rate of the pool, the lower my percentage. I once considered using Deepbit which at the time had about 100 times the hash rate of Eclipse. They solve many more blocks but my percentage would be about 1/100th what it was here. So all I need is for them to solve more than 100 blocks for each one that Eclipse finds. Then Inaba pointed out that I would be giving up 3% there.
Then, if I used one of the pools that has a lower hash rate than Eclipse I would get a higher percentage. That only works if they solve a block. I'm not sure where the optimal point is but I've settled in basically living off the people here that actually find the blocks. I think I like it more when our hash rate is around 60 MH/s.
I hope someday I stumble across a block so I can feel like I contributed.
August 12, 2011, 01:17:14 PM
Huh... we just passed 100 GHs. What's behind the increase?
So, I've been running some tests on Bitcoin Mining Proxy.
My test system is a VM running effectively nothing but BMP, bitHopper and the requisite requirements on a 30 Mbps symmetric connection.
BMP does not appear to scale very well, which I somewhat suspected from the start, since the overhead of Apache and HTTP setup would introduce lag. As the GH/s increase, the lag becomes a meaningful and ever increasing amount of your hash rate. From my tests, BMP saps approximately 12 - 20% of your hashing power in overhead. In my case, pushing 12 GH/s through it yielded ~9.85 - ~10 GH/s on average.
At lower hash rates, this decreased and at single card hashrates the difference may not be noticeable with out precise statistics. Even then, it may get lost in variance noise - but you are still losing the hashing power.
This can probably be mitigated by using a dedicated machine or even your localhost, though I have not tested either of these scenarios. I suspect from years of experience that in the likely event that you improve your hashrate you will never eliminate it due to the overhead of the connection setup. As miners get more efficient and profit margins become thinner and thinner, even small amounts of efficiency improvement are going to make a difference - possibly the difference between being in the red and in the black given energy costs.
The proxy idea is a good one, but unfortunately, it would likely need to be implemented at a much lower level than scripted PHP to be competitive.
This finding is a disappointment to me. I have some distributed miners and the majority of my miners are behind a NAT that I have no desire to open up to the outside world - the proxy is exceptionally convenient for me to redirect the miners or turn one or two off and on to test functionality on the pool. I have to manage 35 miners, and the proxy would make that much easier... but not at the cost of 2+ GH/s.
So, anyway, I thought I'd throw that out there for those of you using it to consider.
So, I've been running some tests on Bitcoin Mining Proxy.
My test system is a VM running effectively nothing but BMP, bitHopper and the requisite requirements on a 30 Mbps symmetric connection.
BMP does not appear to scale very well, which I somewhat suspected from the start, since the overhead of Apache and HTTP setup would introduce lag. As the GH/s increase, the lag becomes a meaningful and ever increasing amount of your hash rate. From my tests, BMP saps approximately 12 - 20% of your hashing power in overhead. In my case, pushing 12 GH/s through it yielded ~9.85 - ~10 GH/s on average.
At lower hash rates, this decreased and at single card hashrates the difference may not be noticeable with out precise statistics. Even then, it may get lost in variance noise - but you are still losing the hashing power.
This can probably be mitigated by using a dedicated machine or even your localhost, though I have not tested either of these scenarios. I suspect from years of experience that in the likely event that you improve your hashrate you will never eliminate it due to the overhead of the connection setup. As miners get more efficient and profit margins become thinner and thinner, even small amounts of efficiency improvement are going to make a difference - possibly the difference between being in the red and in the black given energy costs.
The proxy idea is a good one, but unfortunately, it would likely need to be implemented at a much lower level than scripted PHP to be competitive.
This finding is a disappointment to me. I have some distributed miners and the majority of my miners are behind a NAT that I have no desire to open up to the outside world - the proxy is exceptionally convenient for me to redirect the miners or turn one or two off and on to test functionality on the pool. I have to manage 35 miners, and the proxy would make that much easier... but not at the cost of 2+ GH/s.
So, anyway, I thought I'd throw that out there for those of you using it to consider.
August 12, 2011, 12:55:11 PM
Why so?
August 12, 2011, 12:30:55 PM
August 12, 2011, 12:28:44 PM
I've only got 340MH/s what's your mining rate?
Running two 5770s at about 200 MH/s each and a CPU at about 4 MH/s.
Just discovered bitcoin-miner (under Windoze) will run my CPU at 13.8 MH/s.
This weekend I'm going to see if I can run my GPUs under Winderz with out reducing their hash rate.
August 12, 2011, 11:38:16 AM
90 GH/s now. Wuhoo! 
August 12, 2011, 11:36:34 AM
Naw >_< 0.19783542 (-6.56%) Just getting to little.. 0.3 was nice.. less then 0.2 no phun anymore..
+1
Started out the morning with about .2 and clawing my way towards the .3
I've only got 340MH/s what's your mining rate?
August 12, 2011, 10:09:27 AM
Naw >_< 0.19783542 (-6.56%) Just getting to little.. 0.3 was nice.. less then 0.2 no phun anymore..
+1
Started out the morning with about .2 and clawing my way towards the .3
August 12, 2011, 09:52:42 AM
I guess I solved the last block....I guess there is something to this gaming thing. I guess the force was truly with me as I was beta testing the upcoming MMO last night.
You need to keep that up.
August 12, 2011, 09:31:44 AM
I guess I solved the last block....I guess there is something to this gaming thing. I guess the force was truly with me as I was beta testing the upcoming MMO last night.
August 12, 2011, 09:30:41 AM
Minor request...
Could you please add Athens,Greece in the timezone selections?
Thanx
Could you please add Athens,Greece in the timezone selections?
Thanx
You should be covered under one of these, depending on DST or not.
case "Africa/Cairo": return "+02:00";
case "Asia/Gaza": return "+02:00";
case "Africa/Blantyre": return "+02:00";
case "Asia/Jerusalem": return "+02:00";
case "Europe/Minsk": return "+02:00";
case "Asia/Damascus": return "+02:00";
case "Europe/Moscow": return "+03:00";
case "Africa/Addis_Ababa": return "+03:00";
Stupidpal - What is Cherry Picking? I mean, I know what that is and I can guess what it means in this context, but is that a setting in bitHopper I haven't seen?
I have been playing with Multi Mining Proxy for some test cases and I'm not liking what I'm seeing. I'm going to run some more tests before I comment further though. You guys might want to reassess using it though.
It's a Windows pool hopper not related to bitHopper.
https://bitcointalksearch.org/topic/introducing-cherrypicking-new-windows-linux-pool-hopper-33031
August 12, 2011, 09:29:33 AM
Naw >_< 0.19783542 (-6.56%) Just getting to little.. 0.3 was nice.. less then 0.2 no phun anymore..
August 12, 2011, 09:19:57 AM
Minor request...
Could you please add Athens,Greece in the timezone selections?
Thanx
Could you please add Athens,Greece in the timezone selections?
Thanx
You should be covered under one of these, depending on DST or not.
case "Africa/Cairo": return "+02:00";
case "Asia/Gaza": return "+02:00";
case "Africa/Blantyre": return "+02:00";
case "Asia/Jerusalem": return "+02:00";
case "Europe/Minsk": return "+02:00";
case "Asia/Damascus": return "+02:00";
case "Europe/Moscow": return "+03:00";
case "Africa/Addis_Ababa": return "+03:00";
Stupidpal - What is Cherry Picking? I mean, I know what that is and I can guess what it means in this context, but is that a setting in bitHopper I haven't seen?
I have been playing with Multi Mining Proxy for some test cases and I'm not liking what I'm seeing. I'm going to run some more tests before I comment further though. You guys might want to reassess using it though.
Jump to: