Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 287. (Read 837101 times)

20h left before 3xxxxxx difficulty...

11 blocks today - and counting .....

In getblocktemplate, pretty much all the pool does is count shares - the miner must handle all the txn decisions, txn orphans, block changes (and orphans as well) i.e. pretty much implement a large portion of the txn handling that the pool (or bitcoind) does for you.
As a result of this, your bitcoin network connection will also affect your mining.
At the moment a pool's job is to ensure that it has enough connectivity and performance to handle the miners.
With getblocktemplate, it becomes the miner's problem.
(which is also why I've said that any implementation of getblocktemplate in a miner should also put a fee paid to the miner in the coinbase txn)

Stratum, on the other hand, restricts you to interacting with the pools in a similar manner to how you do already, but you have a somewhat unlimited amount of work per getwork from the pool.
You produce the coinbase transaction also thus you can change the coinbase and thus roll a 'secondary-nonce' and not have to roll the time.
Also, the rolling is of course unlimited since the coinbase field in the coinbase transaction can contain anything you like.
Thus it supports larger hashing power.
The aim is not to hash forever and never talk to the pool, but rather provide each miner work that they can use for a period of time independent of their hashing power.

As I keep saying in other threads, this is all caused by the fact that the block header nonce is only 32bits - the good old MSDOS problem where the design was too small - and to fix it properly requires a hard fork to increase it's size (that the bitcoin devs are afraid to do)

Good to hear that you are working to improve server software and you will implement at least on of them  Can you please explain a little bit differences between getblocktemplate and Stratum?

Could someone create a new worker, test it if it works on their side, then give me the user/pass of the worker?
So I can see if the problem comes from the server or from me.

I was going to implement getblocktemplate. I don't see the point in also having Stratum. But if some miners support one and some the other, maybe I will need to support both on the server. Same with the client (after adding support for backup pools) if some pools use getblocktemplate while others use stratum.

It's always fun to have two standards for the same thing.

Quick question: I just changed the name/pass of my workers (deleted and created new), how much time does the server need to actually recognize my new miners?
CGMiner 2.7.5 is saying:
My start cmd is the exact same as before.

tcping is not helping much:
Am I alone to have this problem?

Edit: There's definitely a problem. I just tried with -u Test -p Test, either with CGMiner 2.6.6 or 2.7.5 on port 80, it still doesn't work.
Edit2: With the Java BitMinter client there's no problem, but I lose 100 MH/s by mining with it ;(

Until I deleted and created the new workers this worked fine:
I don't get it.

Edit3: The port 8332 doesn't work either through Tor (Deepbit works).
Edit4: BFGMiner doesn't work either.

Fixed: _ is the login not just

DrHaribo, what's your plans about implementing Stratum protocol?

Thanks - much appreciated

You can just set 100% donation and leave the last one mining. Remember to change the setting when the Jalapenos arrive.  Alternatively the test account used by the test edition of the BitMinter client (http://bitminter.com/test) will donate everything to the pool. Username Test, workername Test, password Test (note the capital letter everywhere).


Happy to hear this works better for you. Fefox requested this feature because of the issue you describe. Not sure why it would be so messy starting all devices at the same time. But as long as this works better...

Also note that automatic rescanning for FPGAs is back in the options. This in combination with automatically starting devices when they connect (also in options) will help keep things running smoothly even if a device should drop off and come back.

(quoted from other thread)
Doc, this change is awesome.  Starting up BitMinter for my two mini-rigs is a single click now instead of spending 3-4 minutes manually re-adding FPGAs as they drop offline over and over during the startup.  Thanks!

ill be shutting my gpu's down sometime this week, after i get one more Jalapeno ordered.  it will be nice to get a small power bill again    i think ill leave one rig running and set the donation to 100% though or the good Dr could set up another worker and ill let it mine for him 

Awesome support DrHaribo

Every once in a while something weird happens with the new server version causing some requests to get processed very slowly. This was causing rejects above 1% for many users.

I have reverted back to the old server version to ensure trouble-free mining. I will work on fixing this and rollntime will be back soon.

Sorry for the inconvenience.

BitMinter client v1.3.0 just released: https://bitcointalksearch.org/topic/m.1196221

Also, some users are having more rejects after rollntime was switched on. If you are having problems, please let me know which miner you are running and how many rejects you get (over some time, like a long block). Then we can look into improving it.

Rejects on the namecoin side are ridiculously high now. I suspect this is because of a combination of rollntime plus some miners ignoring long polls with namecoin block changes. They will continue using rollable work that is stale on the namecoin side perhaps several minutes after a namecoin block change, which will result in many many rejects.

When using GPUmax this is exactly what happens with the namecoin rejects, as GPUmax only observes bitcoin block changes.

Not sure it's worth bothering with much, though, as namecoins are not worth much anymore.

Edit: Some rejects were caused some hours ago by restarting the mining backend to get the new version up and running. That's normal and nothing to worry about. Bad thing is if you are still getting a high reject percentage.

The efficiency on my system has gone from about 88% to 98%... I only have a ATI 6870 though, no FPGA here

[EDIT]
Now up to 172% efficiency

Thanks, squid, I always wanted to be a "boss".

Shermo, yes, something like that.

New server software is now running, with rollntime support for all miners as long as you have a bit of hashrate and stay above very low efficiency.

Kano explained earlier how you see this in cgminer: https://bitcointalksearch.org/topic/m.1175441

Also you should see reduced network traffic from mining.

This new version splits requests into two types. Miners with OK efficiency are served by 7 CPU cores as quickly as possible. Miners with very low efficiency are served by a single CPU core. This would be CPU miners, buggy miner programs and DoS attackers. Normally the slow queue will be fast enough, but if there are too many requests there then they will slow each other down. Unless it is very extreme it should not affect the rest of the pool.

The new version is running smoothly. GPUmax runs and other big miners are at high efficiency.

(5s):53075.6 (avg):52148.8 Mh/s | Q:192  A:15005  R:0  HW:0  E:7815%  U:715.7/m
 TQ: 0  ST: 37  SS: 0  DW: 71  NB: 1  LW: 22125  GF: 5  RF: 0  WU: 718.8



WooHoo  RollNTime working!

If its no joke, there is a Asic Miner in your pools list ;-)

   my graphic cards 

Could you set it up on an alternate subdomain perhaps? Such as test.bitminter.com ?

Pool is running as normal again.

I put the new version into production and it didn't run very well so I switched back. Have located an issue that I'm looking at now. Unfortunately it's very difficult to test parallel execution of code. Perhaps in the future I can set up a test server and get enough miners testing there to lure out race conditions and other nasty bugs that are difficult to test for.

Sorry for the momentary server hickup. Back to our usual mining.