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

When you implement the Stratum protocol, please don't let the port 80 down. I'm quite sure that with three simple iptables rules you can support all three mining protocols (getwork, Stratum, and GBT). I could provide my help if needed.

I have some other things I must do first, and soon ASICs will arrive. Do those FPGAs still make sense in an ASIC world?

are there any plans on getting products from http://fpgamining.com/products to be compatible with your java miner on windows? I'll be picking up a few to mine with and would like to use that miner.

Yeah, it's on my list, but there's quite a few more important things above it.


Two huge blocks on the same day isn't fun

Really bad luck today on the block front... looking like we may only have 4 blocks done today!

Great job with implementing RollNtime on port 9000! My cgminer seems to be quite content with it. It is a little unnerving not seeing mining statistics appear in the website in certain places, but I suppose that's a symptom of a beta implementation.

I don't really have much of a preference with increasing the N in PPLNS. Eventually the increase in hash rate will bring the time/shift down anyway.

Also, how difficult would it be to implement a time zone selection for users? It is probably just me, but I like looking at the timestamps for shifts and when blocks were created and converting time zones kind of drives me nuts.

Thanks again Dr!

I got a suggestion from PsychoticBoy to change the N in PPLNS from 2x difficulty to 4x difficulty. That would be to double the size of the shifts. Please speak up if you have an opinion on it.

Currently 10 shifts take about 5 hours. Doubling shift size would mean 10 shifts take 10 hours at the current pool hashrate. This would mean it takes longer before a proof of work is fully paid, but also that the variance for a proof of work goes down. 24/7 miners shouldn't notice much, but those who don't mine 24/7 should experience reduced variance.

In other news the testing on port 9000 helped uncover a bottleneck that has now been fixed. A big thanks to all who are mining there to help with testing. The test is still running. I'll try and finish up what will hopefully be the next production version of the mining backend, let it run on the test port for a bit, then bring it over on the regular port.

cgminer API stats will tell you all the 'roll' information received for the last submitted share.
Check that as often as you like to see what the last share was.

I am quite sure you are getting rollable work or you would not have efficiency over 1000%.

I believe Eligius sets expire to 120 seconds on roll-ntime? The BitMinter server uses longer expiration times. Try keeping the tcpdump running until you hit a block change (long poll) and your client grabs new work from the server.

Doc,
I did check the RollN header with eligus mining pool. What i can tell you that my tcpdump is OK and i am geting it and I can see it from eligus. Miner.php shows it also. I am quite sure that your poll does not send it for some reason. Can i do something more to help you out to trace that issue?
I have restarted cgminer to be able to zero the rejects and test eligus pool. Now i am back to bitminter:9000 i will keep you noted about their count
Best.

PS: Can you put a hook in your code where RollN header has been sent and count it? So you can see if it is working and that header is sent to all of us

10X

I restarted once to add more logging to find out what's going wrong. There would be some stales then, but 593 seems very high.I think this was about 14:38 UTC. Are you still getting many rejects now?

Hmm, it may be that I fumbled a bit and took a moment to get the new version running. And with rollntime the clients may just keep working. When finally the server comes back they send in lots of work that will be rejected. I'll make sure if I restart again I do it very quickly.


Cool

What you are probably not noticing is that every once in a while a request or two is taking way too long to process, sometimes more than a second. It appears the same bug is still there, it just happens very seldom because the hashrate on the test port is much lower.

I'll look at what it might be, and perhaps add more diagnostics. May have to restart again to get a new version up. Sadly that will cause some rejected work. But no, it shouldn't be 500+ rejects, it should just be a couple.

Port 9000 is working great, efficiency is through the roof  

Thanks Dr Haribo

OK Doc.
I trust you:)
But i have so many rejects which was not happening when mining withoot roll-ntime enabled port 8332. Rejects Where < 0.03 % Now i see Rejected    593 (14.37%) at port 9000. Could be caused because you are restarting service now and then or there is other issue involved?
Anyway i will continue to mine with roolntime enabled tonight and will wait for your feedback on rejects
10X

Try case insensitive grep. There's no way you'd get over 1000% efficiency if it wasn't rolling ntime.


Cool, thanks very much for your support of the pool. Looking forward to your comeback.

winded down my gpu mining, i have the test miner set your way Dr.  Hopefully ill be back real soon

Ok..I thought so. But as you can see from the tcpdump  The server never includes an X-Roll-NTime header to give rollable work.

sudo tcpdump -tqunvXei eth1 | grep Roll
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes


Nothing happens no X-Roll-NTime Header

What about doing same simple tcpdump check on your server and you will see if it sends X-Roll-NTime or not?

Here is cgminer request from tcpdump

.45510 > 176.9.104.178.9000: tcp 322
        0x0000:  4500 016a aed6 4000 4006 1148 5f6f 0145  E..j..@[email protected]_o.E
        0x0010:  b009 68b2 b1c6 2328 f73a 8c37 9ba9 cdde  ..h...#(.:.7....
        0x0020:  5018 0294 7acc 0000 504f 5354 202f 2048  P...z...POST./.H
        0x0030:  5454 502f 312e 310d 0a41 7574 686f 7269  TTP/1.1..Authori
        0x0040:  7a61 7469 6f6e 3a20 4261 7369 6320 5a6e  zation:.Basic.x=..
        0x0070:  486f 7374 3a20 6d69 6e74 2e62 6974 6d69  Host:.mint.bitmi
        0x0080:  6e74 6572 2e63 6f6d 3a39 3030 300d 0a41  nter.com:9000..A
        0x0090:  6363 6570 743a 202a 2f2a 0d0a 4163 6365  ccept:.*/*..Acce
        0x00a0:  7074 2d45 6e63 6f64 696e 673a 2064 6566  pt-Encoding:.def
        0x00b0:  6c61 7465 2c20 677a 6970 0d0a 436f 6e74  late,.gzip..Cont
        0x00c0:  656e 742d 7479 7065 3a20 6170 706c 6963  ent-type:.applic
        0x00d0:  6174 696f 6e2f 6a73 6f6e 0d0a 582d 4d69  ation/json..X-Mi
        0x00e0:  6e69 6e67 2d45 7874 656e 7369 6f6e 733a  ning-Extensions:
        0x00f0:  206c 6f6e 6770 6f6c 6c20 6d69 6473 7461  .longpoll.midsta
        0x0100:  7465 2072 6f6c 6c6e 7469 6d65 2073 7562  te.rollntime.sub
        0x0110:  6d69 746f 6c64 0d0a 582d 4d69 6e69 6e67  mitold..X-Mining
        0x0120:  2d48 6173 6872 6174 653a 2031 3038 3539  -Hashrate:.10859
        0x0130:  3030 3030 3030 0d0a 436f 6e74 656e 742d  000000..Content-
        0x0140:  4c65 6e67 7468 3a20 3330 350d 0a55 7365  Length:.305..Use
        0x0150:  722d 4167 656e 743a 2063 676d 696e 6572  r-Agent:.cgminer
        0x0160:  2032 2e37 2e35 0d0a 0d0a                 .2.7.5....

The client includes "rollntime" in its X-Mining-Extensions header to signal that it has rollntime support.

The server then includes an X-Roll-NTime header to give rollable work.

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

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?

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