Bitcoin Forum
December 10, 2016, 11:02:14 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
  Print  
Author Topic: BitcoinPool.com open thread  (Read 27634 times)
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 12, 2011, 12:17:09 AM
 #141

I've been using this pool for a day and just received my first payout.  So I thought I'd post my experience.
1) So far the payout seems to be in line with my expectations.

It's nice when the sub-1hr blocks hit, especially 2 in a row. There is still the occasional 16-24 hour block so it still evens out.

3) I don't really get the controversy over the efficiency issue.  This is an entirely reasonable thing for a pool to encourage.

With phoenix becoming really popular and managing it's own work queue and other miners improving other pools are going to see some efficiency gains whether they agree with the argument or not.

4) I am concerned about the pool hopping issue.  But the proposed solution seems reasonable and effective.

From what I have seen so far pool speed stays pretty consistent until the 6 hour mark then a lot of people hop out. Since there's not a graph of speed/round time or json data for the pool you can't be sure, but I end up checking it a lot and don't see a lot of big changes in within average round times.

5) The website isn't great.  It's impossible to navigate.  Why are the stats on the front page?  It took me almost a day to figure out what the statistics meant.  Estimated payouts are wildly inaccurate.  Since I joined at the end of a block, for the first few hours I was convinced I had hit some kind of Bitcoin jackpot.  Alas, that was not the case.

They wanted to be as open as possible with the data, so it's right out front. Estimated payouts are (your submitted shares/total submitted shares), they vary a lot at the beginning of the round. I don't see mine vary that much after the round has been going for a while.

6) Not encrypting passwords is dumb and will likely end up being a dealbreaker for my continued use.

This was fixed over a week (or two) ago now. I never had a problem with my account. I changed the password once after the compromise, and change it occasionally for good measure, and check to make sure my address hasn't changed occasionally also. It's really not that big of a deal for me.

Happy Mining

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
1481367734
Hero Member
*
Offline Offline

Posts: 1481367734

View Profile Personal Message (Offline)

Ignore
1481367734
Reply with quote  #2

1481367734
Report to moderator
1481367734
Hero Member
*
Offline Offline

Posts: 1481367734

View Profile Personal Message (Offline)

Ignore
1481367734
Reply with quote  #2

1481367734
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
benjamindees
Legendary
*
Offline Offline

Activity: 1288


View Profile
May 14, 2011, 09:04:05 PM
 #142

I was actually referring to encryption of the account login page.

But I have some more concerns with the stats.  Errors like this one make me wonder whether shares are being calculated correctly.



Also, poclbm-mod shows my hashrate as at least 300 Mh/s every time I look, yet my account page varies wildly and is regularly as low as 200 Mh/s.  What is the explanation for this?

Civil Liberty Through Complex Mathematics
bobR
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 09:26:44 PM
 #143

well their efficiency  bs is starting to take toll
with increased difficulty and Long poll  they no longer tolerate cpu miners or any slow gpu's
they just want the fast ...  and those that can't see what they do

how the He.. is mining every list bit of a get work efficient for the miner
continue hashing on bad getworks or those with no reward

and then deal with fifth grad math math skills
oh it's a mistake
excuses & down right lies ... well it will get better
abuse from the ... people in charge
they do little more than bad mouth anyone the has the BALLS to speak up
guess what it's not better it got BAD

after 2 months ...  may they do well

oh we give stuff away for the screw job we give .. more promises
do we lie & fU ...dua



slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
May 14, 2011, 09:32:39 PM
 #144

But I have some more concerns with the stats.  Errors like this one make me wonder whether shares are being calculated correctly.

To be correct - yes, this is possible. There can be more valid responses for one getwork request.

grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 10:10:19 PM
 #145

Also, poclbm-mod shows my hashrate as at least 300 Mh/s every time I look, yet my account page varies wildly and is regularly as low as 200 Mh/s.  What is the explanation for this?

They have abandoned poclbm-mod in favor of phoenix.

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
benjamindees
Legendary
*
Offline Offline

Activity: 1288


View Profile
May 14, 2011, 10:12:25 PM
 #146

Quote from: slush
There can be more valid responses for one getwork request.

Okay I see that now.  That makes sense.

Any insight on the hashrate issue?  I ran a log for several minutes and it shows an average of 320 Mh/s.  The website shows something around 250 Mh/s.  I can't be the only one to notice this.

Civil Liberty Through Complex Mathematics
keybaud
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 10:14:48 PM
 #147

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 10:16:49 PM
 #148

Quote from: slush
There can be more valid responses for one getwork request.

Okay I see that now.  That makes sense.

Any insight on the hashrate issue?  I ran a log for several minutes and it shows an average of 320 Mh/s.  The website shows something around 250 Mh/s.  I can't be the only one to notice this.

Every site does that. The site is not in direct contact with the mining client as to how fast it is processing, so it uses math to try to make a guess on depending how fast you submit results. If you submit a few valid responses at a time it looks like you are submitting more than the average speed of the client so the math says you're faster than you are.

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

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
benjamindees
Legendary
*
Offline Offline

Activity: 1288


View Profile
May 14, 2011, 10:30:23 PM
 #149

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

Wouldn't you say that's kind of a huge efficiency hit (1/3)?  I consistently see values that are 1/4 less than what my local client shows.  Isn't the value on the website an average (over 5 min)?

Civil Liberty Through Complex Mathematics
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 10:43:50 PM
 #150

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

The B.S. part is his attitude and how he bans just about any CPU miner. Statistically speaking there is no good reason for worrying about "efficiency".

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 10:46:26 PM
 #151

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

Wouldn't you say that's kind of a huge efficiency hit (1/3)?  I consistently see values that are 1/4 less than what my local client shows.  Isn't the value on the website an average (over 5 min)?

That's speed, not efficiency. If you are seeing values that low try restarting your client(s). I'm seeing an unusually high "queue empty, miner idle" messages on my phoenix clients, could be bitcoinpool getting hit really hard with ddos today or something going on in the system.

The average is supposed to be 5 minutes, yes. I saw the same swings both ways on all sites that I have been on, I have been on 3 different sites in the past 2 months.

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
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 10:56:54 PM
 #152

well their efficiency  bs is starting to take toll

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

The B.S. part is his attitude and how he bans just about any CPU miner. Statistically speaking there is no good reason for worrying about "efficiency".

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there. If you used a client that let you set the askrate so that it fulfilled the efficiency requirement they would probably allow it to run on their site.

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
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 11:05:39 PM
 #153


They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
keybaud
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 11:11:27 PM
 #154


They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

A $100 video card will get you 350 MH/s, so by your maths it will take 420 CPU miners to equal one GPU miner. The GPU miner will be running at 90% efficiency, whereas the slow speed of the CPU will make it worse. This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner. The idea of bitcoinpool is that they try to make every block count.
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 11:18:41 PM
 #155


They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

Before I bought video cards I put my CPU on there and watched it and it was terrible. It was grabbing up a lot of getworks that it was never going to process through. After about a half hour I just shut it down because it was ugly.

80 MH sounds pretty small compared to the size of the smallest pools and easily done with a low end graphics card. If that was coming from 1 person that wanted to try it and could tune the efficiency to meet the requirements then it might be worth it to them. Trying to manage 100 clients at 800 kH/s would be not be a advantageous unless there was a miner that managed cpu efficiency for them like the new generation of gpu miners are doing.  

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
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 11:18:55 PM
 #156


A $100 video card will get you 350 MH/s, so by your maths it will take 420 CPU miners to equal one GPU miner. The GPU miner will be running at 90% efficiency, whereas the slow speed of the CPU will make it worse. This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner. The idea of bitcoinpool is that they try to make every block count.

And... explain to me how turning away free workers makes "every block count"?

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
benjamindees
Legendary
*
Offline Offline

Activity: 1288


View Profile
May 14, 2011, 11:40:42 PM
 #157

And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.

Civil Liberty Through Complex Mathematics
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 14, 2011, 11:46:47 PM
 #158

And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.

It doesn't take much bandwidth to maintain a client. I think I saw somewhere tyco said something like 10 kb/s per client. The issue is that cpu miners are fractions slower than gpu's and if they are requesting work at the same rate then they are eating up valid getworks and never processing through them all.

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
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
May 14, 2011, 11:53:19 PM
 #159


It doesn't take much bandwidth to maintain a client. I think I saw somewhere tyco said something like 10 kb/s per client. The issue is that cpu miners are fractions slower than gpu's and if they are requesting work at the same rate then they are eating up valid getworks and never processing through them all.

Correct on the getwork requests being small.

However, if BitcoinPool is implement so that every client is operating off the same private key, then this is a failure with the way they implemented their pool.

If every client is operating on their own private key (which, by "their own" I mean one generated for them and known only by BitcoinPool), then they would never have this problem you are speaking of.

In addition to nonce, the hash varies based on timestamp and private key (already discussed). So, in theory, every second a new "address space" (as you've called it) opens up. Not to mention, if every client IS operating off the same private key, then they are duplicating efforts. The miner client picks their nonce range, not the pool.

My guess is that they do use multiple private keys.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
May 15, 2011, 01:51:01 AM
 #160

This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner.

This is not true. Period. MHash/sec is MHash/sec. It doesn't matter how many clients it required to do that. It doesn't matter how many getworks. It especially doesn't matter how far into the getwork a client processes before starting a new one. Over time, they will ALL find the same number of solutions per MHash/sec in the same time period.

Quote
The idea of bitcoinpool is that they try to make every block count.

No, the idea of bitcoinpool's "efficiency" is to reduce the amount of server processing and bandwidth load.  This load is absolutely minimal.

Before Long Polling came around, working the entire getwork was idiotic because of the increase in stale shares (especially for a CPU miner!), but now that most of the pools support Long Polling, there is no reason for the miners not to reduce the server load in this manner.

But doing so does absolutely nothing for the miner and DOES NOT increase the number of shares that you find.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!