[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[Fefox]

(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!

[DrHaribo]

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://bitcointalk.org/index.php?topic=27062.msg1175441#msg1175441

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.

[Shermo]

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

[DrHaribo]

BitMinter client v1.3.0 just released: https://bitcointalk.org/index.php?topic=31163.msg1196221#msg1196221

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.

[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.

[hahahafr]

Awesome support DrHaribo

[SgtMoth]

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 

[WhitePhantom]

• Staggered start of devices when multiple devices are started with the button on the status line or the "total" display's start button. Should give a smoother start up of (multiple) BFL minirigs.

(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!

[DrHaribo]

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 

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).

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!

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.

[lenny_]

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

[hahahafr]

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:

Pool 0 slow/down or URL or credentials invalid
Unable to get work from pool 0 http://mint.bitminter.com:80

My start cmd is the exact same as before.

tcping is not helping much:

Probing 176.9.104.178:80/tcp - Port is open - time=13.651ms
Probing 176.9.104.178:80/tcp - Port is open - time=9.556ms
Probing 176.9.104.178:80/tcp - Port is open - time=9.392ms
Probing 176.9.104.178:80/tcp - Port is open - time=9.465ms

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:

Code:

cgminer -o mint.bitminter.com:80 -u hahahafr_gpu0 -p x -o mmrpc.bitparking.com:80 -u hahahafr -p x -I 9 -d 0 --gpu-vddc 1.163 --gpu-engine 890,900 --gpu-memclock 300
cgminer -o mint.bitminter.com:80 -u hahahafr_gpu1 -p x -o mmrpc.bitparking.com:80 -u hahahafr -p x -I 9 -d 1 --gpu-vddc 1.163 --gpu-engine 890,900 --gpu-memclock 300

I don't get it.

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

Fixed: <username>_<workername> is the login not just <workername>

[DrHaribo]

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

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.

[hahahafr]

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.

[lenny_]

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

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.

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?

[kano]

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

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.

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?

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)

[thph]

11 blocks today - and counting .....

[hahahafr]

20h left before 3xxxxxx difficulty...

[kano]

20h left before 3xxxxxx difficulty...

No.
You have at least another difficulty change (~2 weeks) to wait for that ...
This time it will only be around 2.62Million

Edit: Yeah mistake 2.9 not 2.6
I multiplied by the old difficulty - lulz

[cmg5461]

20h left before 3xxxxxx difficulty...

Next Difficulty
in 188 blocks
2,913,501

give or take

[WhitePhantom]

11 blocks today - and counting .....

Yeah, it's nice when we hit a good stretch of luck.  I'm feeling sick over my own performance, though.  I haven't generated a block in six days!  If it all averages out, maybe I'll generate 3-4 blocks for the pool in a day...Hoping!