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

[Shermo]

16 blocks, about 3 hours left... potentially could beat the previous record of 18 blocks in a day

[1714261898]

1714261898

[1714261898]

1714261898

[1714261898]

1714261898

[WhitePhantom]

Strange.  I just decided to glance at my MiniRigs before going to bed and I found that they had not been mining for 3/4 of a shift.  The BitMinter client showed errors about having run out of work.  I normally have about 800-1200 work units queued, but it was only showing 200-ish.  After I closed BitMinter and relaunched it, they started mining as usual.

This has never happened before.  Doc, do you suppose a change in version 1.3 could be the culprit, or is it more likely an inexplicable fluke?

[DrHaribo]

Strange.  I just decided to glance at my MiniRigs before going to bed and I found that they had not been mining for 3/4 of a shift.  The BitMinter client showed errors about having run out of work.  I normally have about 800-1200 work units queued, but it was only showing 200-ish.  After I closed BitMinter and relaunched it, they started mining as usual.

This has never happened before.  Doc, do you suppose a change in version 1.3 could be the culprit, or is it more likely an inexplicable fluke?

With 200 work units queued they were mining, right? If there was a network problem for a while they should pick right up again after connectivity returns.

At the time they were idling, did you also get network errors, like messages about connections timing out?

[DrHaribo]

At height 199506 amazingrando hit bitcoin block no. 988 for BitMinter.

Quick competition: 5 BTC prize for the miner who creates the pool's 1000th block. Stale/orphan status ignored.

EDIT: Block no. 1000 compo thread: https://bitcointalk.org/index.php?topic=110579.0

[WhitePhantom]

Strange.  I just decided to glance at my MiniRigs before going to bed and I found that they had not been mining for 3/4 of a shift.  The BitMinter client showed errors about having run out of work.  I normally have about 800-1200 work units queued, but it was only showing 200-ish.  After I closed BitMinter and relaunched it, they started mining as usual.

This has never happened before.  Doc, do you suppose a change in version 1.3 could be the culprit, or is it more likely an inexplicable fluke?

With 200 work units queued they were mining, right? If there was a network problem for a while they should pick right up again after connectivity returns.

At the time they were idling, did you also get network errors, like messages about connections timing out?

The work units were fluctuating and I briefly saw the number 1.50 (GH/s I assume, didn't notice) before I closed BitMinter.  All the miners were started, but I didn't see anything but zeros next to them.  I guess at least one must have been running, but I had already closed it before I realized that I should have looked more closely.

The only errors that were visible were the ones about running out of work.  I wish I'd spent a minute looking into it more, but I went into fix-it ASAP mode before thinking.

The host computer was running three of my friend's Singles on a second instance of BitMinter under a different Windows user and that instance was running fine when I restarted mine.  Still, there appears to have been some sort of glitch that affected both instances.  I checked my friend's BitMinter account and he had a 30% reduction of shares in the same shift.  That's not as dramatic as the 75% reduction I experienced, but it's something.

I'm still not sure what this suggests, though.  Perhaps a network issue that one instance recovered from more gracefully than the other?  I'll be sure to take better notes of what's going on if it happens again.

[DrHaribo]

I'm still not sure what this suggests, though.  Perhaps a network issue that one instance recovered from more gracefully than the other?  I'll be sure to take better notes of what's going on if it happens again.

Yes, indeed it sounds like there was a network problem and afterwards your friend's instance was alright but yours didn't recover properly.

I'd be very interested in more info to be better able to hunt down any bugs that may be causing this. If you or someone else experiences this again, try if you can to get me a cut'n'paste of the log, a description of how the miner is behaving and anything you know about what lead up to it.

[hahahafr]

It's confirmed that ckolivas is (only?) gonna implement the Stratum protocol in CGMiner soon:

Anyway unfortunately for some (one?), I'm not dead and was not going to abandon cgminer, but family comes first. Things are still bad there but I'm finding my feet again.

I'll look at the stratum protocol at some stage soon.

https://bitcointalk.org/index.php?topic=28402.msg1205331#msg1205331

[AfricanHunter]

Great Pool. Can you explain what is the difference between the current beta vs prod?

Also was wondering why my shift scores were down and then saw we picked up a 282GH/s worker. Nice hash power. Gonna be nuts when people start hitting with multiple 1ths rigs!

[DrHaribo]

Great Pool. Can you explain what is the difference between the current beta vs prod?

Thank you, glad you like it.

Version 1.3.0 of the client was just released and there is no new beta yet. If you try to load the beta right now it will just be the normal 1.3.0 version.

[loshia]

Doc,
I am aware of the recent pool hardware issues which did cause a delay in software development. As you said before Roll-ntime was ready to go but there were some issues with different clients. Is it possible to enable it only for "good miners or per account/login" so we can test  it? I am using cgminer and i can PM my username if you need it

10X

[DrHaribo]

I am aware of the recent pool hardware issues which did cause a delay in software development.

Yep, but I have been working on it. I have made some improvements but I wasn't able to reproduce the slow response we sometimes saw, even when spamming my test server with requests. So I'm not sure if the issue is still there.

I have the new version up for testing on port 9000. Anyone running a setup with backup pools please help test this by putting http://mint.bitminter.com:9000 as first pool and keeping the regular 8332 on second place. In case there is a problem with the test version or I shut it down, your miner will move over to the regular one.

If running on port 9000 your hashrate in livestats will drop, but you can see on the workers page of the website that you are still getting accepted proofs of work and will be paid for the work. Just load that page, wait 10 seconds, then refresh. Numbers will have updated.

So if you have a working setup with backup pools please help test this. I'd like to have some confidence that it's stable before setting it up on port 8332.

[jamesg]

So if you have a working setup with backup pools please help test this. I'd like to have some confidence that it's stable before setting it up on port 8332.

Hi DrHaribo,

I'm running 52Gh to port 9000 with cgminer 2.5.0. The efficiency is hovering around 1400%5000%.  

Best,
gigavps

[Turbor]

Seems to work well... so far

[loshia]

Thanks Doc. I fired cgminer 2.7.5 latest git code a couple of mins ago
My Efficiency is constantly increasing >1000% now which means that it is working
However:

1. miner.php - stats all to false
Work Had Roll Time   Work Can Roll   Work Had Expire   Work Roll Time
false   false   false   0

[DrHaribo]

Thanks to all who are participating in the test. We even had a BTC block on the test port.

It seems mostly stable, but it did log one request taking 678ms. So there seems to be a problem, it's just very rare that it gets triggered. That's a difficult bug to find.

I'll leave the test running, perhaps just shutting it down momentarily to get it updated. Hopefully I can pinpoint the problem.

1. miner.php - stats all to false
Work Had Roll Time   Work Can Roll   Work Had Expire   Work Roll Time
false   false   false   0

I'm not sure what this is. Where is it grabbing data from?

[loshia]

Doc,
I do not know either:) Just for the reference.... Don't ask what does it mean. I guess it is something specific to the protocol and headers revived from the pool:

in cgminer util.c
 if (!strcasecmp("X-Roll-Ntime", key)) {
                hi->hadrolltime = true;
                if (!strncasecmp("N", val, 1))
                        applog(LOG_DEBUG, "X-Roll-Ntime: N found");
                else {
                        hi->canroll = true;

                        /* Check to see if expire= is supported and if not, set
                         * the rolltime to the default scantime */
                        if (strlen(val) > 7 && !strncasecmp("expire=", val, 7)) {
                                sscanf(val + 7, "%d", &hi->rolltime);
                                hi->hadexpire = true;
                        } else
                                hi->rolltime = opt_scantime;
                        applog(LOG_DEBUG, "X-Roll-Ntime expiry set to %d", hi->rolltime);
                }
        }


https://en.bitcoin.it/wiki/Getwork

Iff the getwork response includes a "X-Roll-NTime" header with any value other than "N" or the null string, the miner may (within reason) change the ntime field in addition to the nonce. The server may send a value of "expire=<N>", where <N> is an integer number of seconds it is willing to accept the other headers for. Note that if the "X-Roll-NTime" header is NOT present in a work response, that work may NOT be rolled, even if earlier work from the same server allowed it. Also note that the headers of a share submission should not influence the behaviour of work-- specifically, if a share submit does not have the header, it should not disable rollntime for the current work (which did).

[DrHaribo]

I do not know either:) Just for the reference.... Don't ask what does it mean. I guess it is something specific to the protocol and headers revived from the pool:

Ah, you didn't get rollable work? It can happen if your hashrate is low or your efficiency is very low.

[loshia]

I do not think so....
My hash rate is about 11442.0 Mh/s (compared to top guy's it is low for sure) and current efficiency was (copy pasting just killed my screen:))

 cgminer version 2.7.5 - Started: [2012-09-22 14:51:00]
--------------------------------------------------------------------------------
 ALL (5s):10262.4 (avg):11442.0 Mh/s | Q:1781  A:21187  R:3  HW:43  E:1190%  U:1
 TQ: 0  ST: 33  SS: 0  DW: 700  NB: 17  LW: 54457  GF: 28  RF: 0  WU: 159.8
 Connected to http://mint.bitminter.com:9000 with LP as user
 Block: 0000050e21b47eaef0f818b858cce18a...  Started: [16:58:38]

PS: can someone who is testing with cgminer confirm if he is getting some stats on miner.php about this. Doing this we will know if there is a problem or not

miner.php - Stats next to the pool
Work Had Roll Time   Work Can Roll   Work Had Expire   Work Roll Time

10X

[DrHaribo]

ALL (5s):10262.4 (avg):11442.0 Mh/s | Q:1781  A:21187  R:3  HW:43  E:1190%  U:1

Efficiency 1190%, so you do get rollable work or it wouldn't be that high.

Someone who knows miner.php can perhaps help with why it doesn't show any data?

[loshia]

Thanks Doc!
I will dig it out and see what is going on...
Great work! As i said in my first post when efficiency > 100% It is working..
PS: i did a tcpudump and i am not able to see such a header - X-Roll-Ntime. It shall be provided buy the pool or requested from the miner?

sudo tcpdump -tqunvXei eth1 | grep time
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
        0x0100:  6174 6520 726f 6c6c 6e74 696d 6520 7375  ate.rollntime.su
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub
        0x0070:  3a20 7469 6d65 6f75 743d 3839 352c 206d  :.timeout=895,.m
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub
        0x0070:  3a20 7469 6d65 6f75 743d 3839 352c 206d  :.timeout=895,.m
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub
        0x0070:  3a20 7469 6d65 6f75 743d 3839 352c 206d  :.timeout=895,.m
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub


An so on X-Roll is missing