KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2437 blocks

[citronick]

Hash rate varies.

Look at your Workers->Shift Graph.

That varies up and down all the time.

If you are seeing some hash rate that seems low, then post a Workers->Shift Graph
And make sure it doesn't look like most of them, full of up and down blue lines

Any outage will of course affect the shift when you had the outage.
That will be obvious by a shift that's low and then it goes back up.

that's what happened to my rigs today - dropped for about an hour before I saw the email and phone alerts.
Failover did not kick in because the miners are still able to ping sg.kano but it seems the node is not sending the hashes back to kano@US

the traceroute as follows:

traceroute to sg.kano.is (139.162.5.112), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  0.889 ms  0.419 ms  0.603 ms
 2  bb116-15-160-254.singnet.com.sg (116.15.160.254)  3.125 ms  2.538 ms  1.730 ms
 3  202.166.126.218 (202.166.126.218)  4.167 ms  2.103 ms  2.051 ms
 4  202.166.126.217 (202.166.126.217)  1.963 ms  2.013 ms  1.930 ms
 5  ae8-0.qt-cr03.singnet.com.sg (202.166.121.101)  2.195 ms  2.011 ms  1.992 ms
 6  ae12-0.qt-er05.singnet.com.sg (202.166.120.221)  2.111 ms  2.237 ms  2.076 ms
 7  202.166.126.114 (202.166.126.114)  2.188 ms  2.228 ms  2.483 ms
 8  ge-8-2-0.cityhall.singnet.com.sg (165.21.12.79)  2.706 ms  2.593 ms  2.686 ms
 9  ip-202-147-32-126.asianetcom.net (202.147.32.126)  2.886 ms  2.817 ms  2.993 ms
10  te0-0-2-0.wr1.sin0.asianetcom.net (61.14.157.109)  6.540 ms  5.261 ms  3.562 ms
11  xe-0-1-1.gw1.sin2.pacnet.net (202.147.52.64)  3.911 ms  3.789 ms  3.623 ms
12  gw2.sin1.sg.linode.com (61.14.147.179)  4.161 ms  3.960 ms
    gw1.sin1.sg.linode.com (61.14.147.177)  37.366 ms
13  139.162.0.2 (139.162.0.2)  38.929 ms
    139.162.0.6 (139.162.0.6)  36.217 ms
    139.162.0.2 (139.162.0.2)  38.780 ms
14  sg.kano.is (139.162.5.112)  3.890 ms  3.706 ms  3.977 ms

**************

traceroute to stratum.kano.is (104.194.28.194), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  0.850 ms  0.462 ms  0.571 ms
 2  bb116-15-160-254.singnet.com.sg (116.15.160.254)  2.392 ms  3.199 ms  2.719 ms
 3  202.166.126.218 (202.166.126.218)  3.962 ms  2.249 ms  2.409 ms
 4  202.166.126.217 (202.166.126.217)  1.960 ms  1.771 ms  2.010 ms
 5  ae8-0.qt-cr03.singnet.com.sg (202.166.121.101)  2.301 ms  1.868 ms  1.760 ms
 6  ae6-0.singha.singnet.com.sg (202.166.120.186)  2.412 ms  2.643 ms  2.424 ms
 7  ae5-0.beck.singnet.com.sg (202.166.126.41)  2.631 ms  2.395 ms  2.320 ms
 8  203.208.174.57 (203.208.174.57)  2.257 ms  2.299 ms  2.322 ms
 9  203.208.171.242 (203.208.171.242)  37.038 ms
    203.208.151.234 (203.208.151.234)  2.503 ms
    203.208.152.106 (203.208.152.106)  2.711 ms
10  203.208.183.46 (203.208.183.46)  191.466 ms
    203.208.182.130 (203.208.182.130)  196.311 ms
    203.208.182.122 (203.208.182.122)  182.413 ms
11  203.208.172.242 (203.208.172.242)  183.375 ms
    203.208.172.246 (203.208.172.246)  185.579 ms
    203.208.172.242 (203.208.172.242)  186.567 ms
12  30gigabitethernet2-1.core1.pao1.he.net (198.32.176.20)  178.776 ms  182.436 ms  195.184 ms
13  10ge4-1.core1.sjc2.he.net (72.52.92.70)  177.419 ms  184.386 ms  192.777 ms
14  10ge13-3.core1.lax2.he.net (184.105.213.5)  223.580 ms  243.606 ms
    100ge13-2.core1.lax1.he.net (184.105.223.250)  193.237 ms
15  100ge11-1.core1.lax2.he.net (72.52.92.122)  201.643 ms  198.710 ms  188.158 ms
16  216.218.200.10 (216.218.200.10)  220.361 ms  222.776 ms  224.785 ms
17  192.228.109.50 (192.228.109.50)  209.702 ms
    64.62.249.90 (64.62.249.90)  210.546 ms  208.894 ms
18  192.228.109.50 (192.228.109.50)  204.860 ms  214.114 ms  200.690 ms
19  * * *
20  * * *
21  * * *
22  * * *

[wolfen]

11.5 th spike early this morning
Looking for that sequential 3 block hit

[citronick]

Hash rate varies.

Look at your Workers->Shift Graph.

That varies up and down all the time.

If you are seeing some hash rate that seems low, then post a Workers->Shift Graph
And make sure it doesn't look like most of them, full of up and down blue lines

Any outage will of course affect the shift when you had the outage.
That will be obvious by a shift that's low and then it goes back up.

The screen-grab as follows - hope it helps in your trouble shooting




X1 is a rental.

[ryen123]

@Kano I'm starting to get these issues again from SG node.

"Accepted untracked stratum share from pool 0"
"Lost x shares due to no stratum share response from pool 0"

Current traceroute snapshot.

Code:

traceroute to sg.kano.is (139.162.5.112), 30 hops max, 128 byte packets
 1  RT-N56U (192.168.1.1)  0.735 ms  0.472 ms  0.270 ms
 2  172.22.0.1 (172.22.0.1)  12.356 ms  5.642 ms  3.144 ms
 3  103-6-148-37.myrepublic.com.sg (103.6.148.37)  37.225 ms  2.462 ms  2.771 ms
 4  103-6-148-13.myrepublic.com.sg (103.6.148.13)  2.852 ms  5.009 ms  3.919 ms
 5  63949.sgw.equinix.com (202.79.197.235)  165.467 ms  166.278 ms  165.983 ms
 6  139.162.0.6 (139.162.0.6)  164.369 ms  162.777 ms  165.351 ms
 7  sg.kano.is (139.162.5.112)  168.665 ms  169.558 ms  168.497 ms

[nhando]

The Worker Shift Graph is awesome.  I wished I knew more about it before.  I'm glad I saw the example above before which shows that timeline exist not just the default of A-Z at the bottom.  I didn't even know Timeline was available so when I first saw this graph, I didn't think it was that helpful.  After I saw the example above with timeline, I started playing around with it and this helps give a much better view of my workers 5ND status and the dips and all that affects my 5ND status.  Definitely much easier to understand from a historic basis then just the normal Workers status.  If would be even more awesome if we can have a Giant DOT on the time where a BLOCK is found so we can match it to our reward status average for that point in time. 

[kano]

OK, well it seems that a few (not all) people are having trouble with the SG server.
Again it's almost certainly some network issue in singapore since there's still 90TH of miners on there submitting shares
(and I'm always connected and submitting shares and not having drop outs either)

If you are having any trouble with the SG server, then for now I'll say you will need to point to the main node or DE.
Preferably the main node to see if the problems reappear or not.

I'm not gonna stop the SG node right now since, as I said, there's 90TH of miners, and they appear to be working OK.

Also the mtr needs to be run at the exact time you are having connections problems.

--

The DE server is currently 155TH and until I hear problems from anyone regarding that one, all seems OK with it.
(Same with DE, I'm always connected and a USB miner submitting shares)

I'm basically just letting the SG server go as it pleases and as long as the DE server is OK we can be pretty sure the SG problems aren't the node, but the network.

[kano]

...
If would be even more awesome if we can have a Giant DOT on the time where a BLOCK is found so we can match it to our reward status average for that point in time. 

It (currently) shows the last block, just no others.

The last block is, of course, the right hand edge of the red area.

[stonebone]

Confirmed, DE server works perfect. Changed all except 1 miner from the main to the DE server yesterday, no issues, same hashrate.

[gupik65]

The DE server is currently 155TH and until I hear problems from anyone regarding that one, all seems OK with it.
(Same with DE, I'm always connected and a USB miner submitting shares)

Many miners from Ukraine and Russia are experiencing the loss of a server,Off. , what is the reason?

[gupik65]

Confirmed, DE server works perfect. Changed all except 1 miner from the main to the DE server yesterday, no issues, same hashrate.

Test Now

[omega015]

Come on miners, this is our block  I feel sad when I see no blocks waiting to be matured 

[zahzin]

Will test a bit longer and report back when I have something more substantial

Hmm while testing as I wanted all things to be "equal" once I set the diff offered on Kano pool to 1000 (the same that solo pool is offering) the Ants2 is way more happy and hash rate has climbed back up  and not getting as many hw errors either.. So no problem with DE node or anything it seems as far as I am considered..

Weird though that ant s2s dont seem to like the 1042 default which is being offered if I left the worker diff setting to 0 and let it auto adjust.. (if anyone knows of a better setting than 1000 please do tell) but yeah, that seemed to do the trick to get it to perform the same as in solo pool..

[e46btc]

What is a reason for manual diff settings?  CKPool VarDiff works like a charm. Do not change anything and just mine. 1042 is start value and it will be automatically adjusted within 10-20 minutes.

[gnu123]

If/when de .DE server works fine and is an option for us living in Europe, please write somethimg on the homepage or something.
I have 45 kilometres to my miners in serverrom, so changing server is a "big deal" and need to know why and that it works before i do the trip.

I know many users read every post in this thread, I try to do but not always time so easily missing out info about new servers and how they work and what would be better.

[clgrissom3]

I was browsing the current workday on Blockchain.info and it seemed that there was an unusually low number of blocks for that large SPV pool that starts with an "A".  I looked at their stats page and they are officially under 100% on all categories now.  Wow.

24 Hours    3 Day    1 Week    2 Weeks    1 Month    3 Months    All
83.00%    99.00%    99.00%    96.00%    96.00%    97.00%    99.00%

EDIT:  I did see that someone hit a block on Solo CKPool overnight.  Way to go!

[zahzin]

What is a reason for manual diff settings?  CKPool VarDiff works like a charm. Do not change anything and just mine. 1042 is start value and it will be automatically adjusted within 10-20 minutes.

I am sure CKPool handles vardiff  very well, just seems Ant s2s does not, and tries to throw a fit with vardiff at some point, no idea why though..

[e46btc]

What is a reason for manual diff settings?  CKPool VarDiff works like a charm. Do not change anything and just mine. 1042 is start value and it will be automatically adjusted within 10-20 minutes.

I am sure CKPool handles vardiff  very well, just seems Ant s2s does not, and tries to throw a fit with vardiff at some point, no idea why though..

Oh ok I see. Lowest Ant I have is S3..  900-950-1000 is ok for 1 TH/s miner IMO.

[zahzin]

What is a reason for manual diff settings?  CKPool VarDiff works like a charm. Do not change anything and just mine. 1042 is start value and it will be automatically adjusted within 10-20 minutes.

I am sure CKPool handles vardiff  very well, just seems Ant s2s does not, and tries to throw a fit with vardiff at some point, no idea why though..

Oh ok I see. Lowest Ant I have is S3..  900-950-1000 is ok for 1 TH/s miner IMO.

Thanks for the tip, will give those lower values a try as well to see if performance can be even better than with 1000..

Appreciated !

[yslyung]

i see this when i ping sg.kano.is

C:\Users\User>ping sg.kano.is

Pinging sg.kano.is [2400:8901::f03c:91ff:fef1:5056] with 32 bytes of data:
Reply from 2400:8901::f03c:91ff:fef1:5056: time=12ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=13ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=14ms
Reply from 2400:8901::f03c:91ff:fef1:5056: time=13ms

Ping statistics for 2400:8901::f03c:91ff:fef1:5056:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 14ms, Average = 13ms

no ip address ?

main kano.is is ok

de is also ok

dash says it's dead & alive time to time but when it's back, miner hangs & does not failover.

happened about 3 & 1/2 hour ago from current post.

[jonnybravo0311]

That looks like an IPv6 address... here's what I get when I ping sg.kano.is:

Code:

ping sg.kano.is
PING sg.kano.is (139.162.5.112): 56 data bytes
64 bytes from 139.162.5.112: icmp_seq=0 ttl=49 time=303.637 ms
64 bytes from 139.162.5.112: icmp_seq=1 ttl=49 time=243.941 ms
64 bytes from 139.162.5.112: icmp_seq=2 ttl=49 time=380.693 ms
64 bytes from 139.162.5.112: icmp_seq=3 ttl=49 time=341.515 ms
64 bytes from 139.162.5.112: icmp_seq=4 ttl=49 time=260.073 ms
64 bytes from 139.162.5.112: icmp_seq=5 ttl=49 time=293.206 ms
64 bytes from 139.162.5.112: icmp_seq=6 ttl=49 time=248.775 ms
^C
--- sg.kano.is ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 243.941/295.977/380.693/47.120 ms

Yeah, I'm currently in Florida, so hence the ping time