Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :) - page 22. (Read 101960 times)

Sorry Geebus, I was using:

 -a 120 --defspd

on the command line for my faster GPU's and

 -a 1200 --defspd

for my CPUs and slower GPUs. With -b this yielded a respectable efficiency. Now with the removal of --defspd my eff is dropping like a rock.

Maybe I'm half brained fail-tard, but shouldn't the behavior of the old -a 1200 --defspd options be the default going forward if long-polling is so hot.

Even if you disagree with me on the default behaviors. I still want my --defspd back as my slower instances are giving up on a "getwork" without completing it even if a long-poll hasn't come in.

EDIT: As is it seems this release with hurt efficiency more then it helps it.

Unfortunately with Kiv's miner, since it is overlaid on the original poclbm, askrate doesn't really affect anything, and it will stay fairly low ratio of submitted vs requested. I recommend using the last version of the command-line miner and seeing if your ratio improves.

You can download it here.

Really new to bitcoins in general and no knowledge or programming, decided to join you're pool and downloaded Kiv's version so as to not deal with it but been having very low efficency ratio's, 9% atm and wondering if there's any suggestions on how to increase it, have tried adding the
-workrefershms=20000 and -d for the extra flags but both stopped it from working, currently running with -v and -w128 on my geforce 9600gt at about 9-10 Mhash/s but wondering if anyone has any suggestions for increacing my efficency

I'm not so sure you did.

It's true that you can ignore it and it wont affect your mining, but the point of that whole explanation by FairUser was that you should get a different miner that supports long polling so that you're not repeatedly trying to send old answers for old work because your miner is always a step behind everyone else.

ok I think i got it
just ignore it if it pops up occasionally

wow >250% EFF, really unbelievable. But the saying "DUPLICATE NOT SUBMITTED" makes me feel both good & bad that i mined same share 2 times in same time(like giving birth to twins) & one is rejected, coz its a duplicate.

A share you got to solve which is a small part of a very large block.
you solve the share & you submit it, the server checks the share you submitted is from which block.
If the block you got the share has been solved even before you submitted the share, then server rejects your share saying, its stale or invalid.
Every 10 minutes a block is released in the network.
So, the share will become stale if you are solving very slowly, that is low hash/s.
All users get stale shares, even the one who has more hash/s. But low hash/s users get more, because, they don't no yet that the share they are trying to solve is already solved by the network & 50 coins sent to them.
Long polling tells the miner that a new block is released, so leave the current share & get new share.


I am not that good in understanding the backgrounds & basis of mining, so i may be wrong.
Correct some one, if i am wrong.

I don't use pudinpops miner, and I do not know if it supports long polling.  You should ask him that.
You could get jgarzik's CPU miner which does support long polling:   https://bitcointalksearch.org/topic/new-demonstration-cpu-miner-available-1925

The bitcoin network has a "block count".  This "block count" changes anytime someone finds an answer for the current block.
A share is a *possible* answer for the block.  If the block count of the bitcoin network increases, and your mining is still working on finding an answer for the older block, it has become stale.
So the idea behind long polling is that when the block count increases, it will notify your miner right away, and then your miner starts working on the new getwork instead of the old one.

Or to put it another way, your "getwork" request may have a share (answer), and that answer may solve the current block.  If it takes you too long to find an answer on your current getwork, it will go stale when the block count increases on the network.  The only reason the block count increases is because someone found an answer for the block.  A share can become stale at any moment, so you are literally racing against time.  If you want to find more shares, you need to get a good ATI video card.  It sounds like your CPU just isn't cutting it for you.



Also, it makes perfect sense why our pool hasn't found anything in 24 hours.
Put the speed of the pool into the bitcoin calculator:  http://www.alloscomp.com/bitcoin/calculator.php

The pool speed is about: 4600000 khash/s   or 4.6 Ghash/s
That comes out to:

Probability   Time
Average   19 hours, 45 minutes
50%        13 hours, 41 minutes
95%        2 days, 11 hours, 12 minutes

At the speed we're going, it could take 2 days.  Be patient.
If don't like being patient, you might want to check out another pool.

Again you are talkin above my head
i'm usin pudinpops miner

What does long polling have to do with it

I get work ... every so often as per your edit
why should it be stale when i'/v never hashed the whole chunk
You want wait before I ask for another
my wait and hash times ... i never hash a whole chunk
Why should it go stale
your pool hasn't solved a block in over 24 hrs
This makes no sense

The block is changing before you find a share. 
This is why we recommend that people start using long polling with our server, so that wouldn't happen.

Fixed.  Thank you for reporting it.

Why are stale messages being kicked up on a slow machine

Nothing happens clicking the link. It just opens a empty page with this address http://bitcoinpool.com/file.php?id=4
No file is downloading on chrome, firefox, IE9

*** MINER UPDATE - 03/21/2011 ***

DOWNLOAD: poclbm-mod.03.21.2011b.zip (Win32/Linux) 7.9MB

Changes / Updates:

• Proper tracking of the percentage of hashspace worked through.
• Local tracking of all submitted shares prevents duplicates from being submitted.
• "Emp." is now an integer and not a percentage
• Resolved issue resulting in ~40% drop in submitted:requested
• Searches as much of the hash space as possible without causing re-work.

I recommend you update ASAP.

Happy mining!

Edit: Minor fix in the code for slow clients. Askrate was being automatically capped at 55 seconds and is not anymore.

I would likewise say the same. BitcoinPool is a 50/50 effort between FairUser and I, and it would be doing a disservice to either of us to say different. But, aside from that, I like your post.

++

But I would call it BitcoinPool, not Geebus.
Technically it's in my house, but Geebus and I both work on it and regularly bounce ideas off of each other.  It's a team effort.

This is not "pseudo-science", it's a fact.  We spent over a month working, testing, and analyzing results. 


I'm not sure what you're trying to correlate, but we never said you get more or less shares/nonces using this miner vs yours.  In fact, you get about the same number of them in a given amount of time, but ours does it with less getwork requests.  That's all we're saying. 
I'd love to see any data you have proving your statement, cause we have LOTS of results to prove ours.  Besides, I like being able to find more than one nonce in a single getwork request.  It happens quite often too.


What other methods would you propose?

BTW, thanks for the code.  We didn't want to tell you how to manage your miner, hence why we forked it and did our own.  Have you looked at the changes at all?

We did all of this because slush started charging people a "forced donation" or a fee under the notion that his amount of used resources was too high and he needed to cover the cost.  So we looked into why the usage of resources was so high, and excessive getwork request end up costing him $$$ on his VPS provider.  The tweaks we made to your miner would help slush, but he said he didn't want it and likes his miners using a askrate of 1 second (causing a flood of getwork), so we launched our own pool instead of complaining about it.

Our goal wasn't to 'find more faster' or anything like that, we simply wanted to be more efficient about the way our miner worked with the pool.  We don't see the need to excessively call to a server for a new getwork every 10 seconds.  Now with long polling, their really is no need for that type of behavior. 

Working through the entire getwork isn't a bad thing.  If you feel it is, please elaberate.
------------------------------------------------------------------------------------
http://dictionary.reference.com/browse/efficiency

Hi
Getting this om my iMac:

20/03/2011 23:50:40, d29e1a8c, accepted at 78% of getwork[13]                 
20/03/2011 23:50:42, long poll: new block                                     
[GW: 14][AR: 83][0/100%]-[kHash/s: 51038]-[Eff: 86%][I/S: 0%][Emp: 21%]Exception in thread Thread-1:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py", line 522, in __bootstrap_inner
    self.run()
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py", line 477, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/torsteinwikene/Downloads/poclbm-mod-03/sources/BitcoinMiner.py", line 313, in longPollThread
    if getworkCount != 0:
UnboundLocalError: local variable 'getworkCount' referenced before assignment

[GW: 14][AR: 83][87/100%]-[kHash/s: 49604]-[Eff: 86%][I/S: 0%][Emp: 21%]       



The miner continues working...

+1 agreed

Oh I wasn't offended.  I just like giving people shit sometimes, and I totally knew what you meant.
You seem like you can take it better than most.