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

[kano]

I noticed you guys talking about 1600W PSU's and I just happen to be selling brand new, sealed in the box EVGA SuperNOVA 1600 G2 80+ GOLD 1600 WATT PSU.

I've been running 3 of them at home since late June without problems and have an extra one.  I run Avalon 741 on each one and PSU's never gave me any issues.

If you're in the market for one you would be helping a fellow pool member in the process

... and of course keep the sales discussion to PM

[padrinogtr]

can anyone advise here or on PM
my latest S9 just lost a board in other words it was working fine for about 24 hours then i made a psu change and it just stoped hashing. two interesting details, one, the miner detects the board but no its not hashing at all GH/S(RT) shows 0000, two, if i connect that particular board by itself it does hash, but only by itself.

any input or advice will be greatly apreciated

i tried diferent psu
and i tried changing resetting all settings
same result

Which brand of psu's are you using?

\

i tried both bitmain psu and HP

I have been using the same LEPA PSUs for 2 years, first on AntMiner S7's then on S9's without any PSU problems at all.  I've had S9 hashboards fry, but not from the power supplies.  The hasboards that fried were always in the one S9 that I have which is Batch 1.  I am fairly certain that it is an overheating problem.  I have two hasboards out of it now, sent off to Bitmain Warranty in Colorado for repair.  When they come back, I am going to underclock that S9 to 600 rather than the default 650 and hope that fixes the problem.  In case anyone is interested in the model of PSU I use, they are LEPA G Series G1600-MA 1600W ATX12V / EPS12V SLI Ready CrossFire Ready 80 PLUS GOLD Certified Full Modular Power Supply.  I can't speak for all of them, but my anecdotal testimonial evidence is that I have had 3 of them running for 2 years solid, without a minute of downtime other than a couple brief power outages to my house for a couple hours or when I manually shut them down to remove the hashboards to send in for repair.  The PSUs themselves have never had any problem, even when running the S7s, which used more wattage than the S9s.  When I had the S7's I would have at least 2 industrial surge protectors burn out completely, frying the circuit breaker to toast, per month.  That was sheer agony.  I couldn't find a surge protector that was S7-proof.  I have never had one fry with my S9s.

my S9 are auto
how can i underclock it?

[tournamentdan]

can anyone advise here or on PM
my latest S9 just lost a board in other words it was working fine for about 24 hours then i made a psu change and it just stoped hashing. two interesting details, one, the miner detects the board but no its not hashing at all GH/S(RT) shows 0000, two, if i connect that particular board by itself it does hash, but only by itself.

any input or advice will be greatly apreciated

i tried diferent psu
and i tried changing resetting all settings
same result

Which brand of psu's are you using?

\

i tried both bitmain psu and HP

I have been using the same LEPA PSUs for 2 years, first on AntMiner S7's then on S9's without any PSU problems at all.  I've had S9 hashboards fry, but not from the power supplies.  The hasboards that fried were always in the one S9 that I have which is Batch 1.  I am fairly certain that it is an overheating problem.  I have two hasboards out of it now, sent off to Bitmain Warranty in Colorado for repair.  When they come back, I am going to underclock that S9 to 600 rather than the default 650 and hope that fixes the problem.  In case anyone is interested in the model of PSU I use, they are LEPA G Series G1600-MA 1600W ATX12V / EPS12V SLI Ready CrossFire Ready 80 PLUS GOLD Certified Full Modular Power Supply.  I can't speak for all of them, but my anecdotal testimonial evidence is that I have had 3 of them running for 2 years solid, without a minute of downtime other than a couple brief power outages to my house for a couple hours or when I manually shut them down to remove the hashboards to send in for repair.  The PSUs themselves have never had any problem, even when running the S7s, which used more wattage than the S9s.  When I had the S7's I would have at least 2 industrial surge protectors burn out completely, frying the circuit breaker to toast, per month.  That was sheer agony.  I couldn't find a surge protector that was S7-proof.  I have never had one fry with my S9s.

my S9 are auto
how can i underclock it?

Log into your miner. Click on Miner Configuration. Go up into the ip address. Delete the word "Configuration". Type the word "Advanced" with the capital "A". Hit enter. Choose the frequency you want.

[voodooman]

Nice hack!!

Much easier than changing the /config/bmminer.conf  over ssh 

Is there also a way to control the fanspeed manually??

[tournamentdan]

Nice hack!!

Much easier than changing the /config/bmminer.conf  over ssh  

Is there also a way to control the fanspeed manually??

I don't think you can change the fan speed. Although I will be looking into this soon since I am going to try immersion  cooling. Fingers crossed.

Edit: meant to type immersion instead of submerged 

[aessedai]

Nice hack!!

Much easier than changing the /config/bmminer.conf  over ssh  

Is there also a way to control the fanspeed manually??

I don't think you can change the fan speed. Although I will be looking into this soon since I am going to try immersion  cooling. Fingers crossed.

Edit: meant to type immersion instead of submerged 

Miner Configuration Tab. "Customize the fan speed percentage."

[tournamentdan]

Nice hack!!

Much easier than changing the /config/bmminer.conf  over ssh  

Is there also a way to control the fanspeed manually??

I don't think you can change the fan speed. Although I will be looking into this soon since I am going to try immersion  cooling. Fingers crossed.

Edit: meant to type immersion instead of submerged 

Miner Configuration Tab. "Customize the fan speed percentage."

Not on a S9.

[kano]

Had to do a quick restart of the main backend node.
There were lots of disconnects and reconnects occurring (that many would have most likely seen)
Everyone will have failed over and is in the process of failing back now.
Restart was at 23:55:32 UTC

[aessedai]

Miner Configuration Tab. "Customize the fan speed percentage."

Not on a S9.

I am looking at it on an S9.  Miner Configuration Tab, Under the General Settings sub tab, at the bottom.  It's on all of my S9's, regardless of batch & firmware version.

[tournamentdan]

Miner Configuration Tab. "Customize the fan speed percentage."

Not on a S9.

I am looking at it on an S9.  Miner Configuration Tab, Under the General Settings sub tab, at the bottom.  It's on all of my S9's, regardless of batch & firmware version.

You must have all s9v1. There are no other tabs under gereral settings. All my firmware is of April of this year though. Let me know if it has changed in newer fw.

[aessedai]

Miner Configuration Tab. "Customize the fan speed percentage."

Not on a S9.

I am looking at it on an S9.  Miner Configuration Tab, Under the General Settings sub tab, at the bottom.  It's on all of my S9's, regardless of batch & firmware version.

You must have all s9v1. There are no other tabs under gereral settings. All my firmware is of April of this year though. Let me know if it has changed in newer fw.

Ah! That could explain it.  I live by the creed, that "If it ain't broke, don't fix it."  I don't update firmware unless it fixes a problem I am having.  I've had far more disastrous results from performing upgrades of firmware, software, operating systems, etc. over time than I have had positive results if I just upgraded for the sole reason that an upgrade exists.  I find that I either lose functionality in some way or run into other problems more often than I see something "new and improved" come out of it.  So, I only upgrade if the upgrade or patch actually targets and fixes a problem I am having or is absolutely necessary for continued functionality.

[padrinogtr]

can anyone advise here or on PM
my latest S9 just lost a board in other words it was working fine for about 24 hours then i made a psu change and it just stoped hashing. two interesting details, one, the miner detects the board but no its not hashing at all GH/S(RT) shows 0000, two, if i connect that particular board by itself it does hash, but only by itself.

any input or advice will be greatly apreciated

i tried diferent psu
and i tried changing resetting all settings
same result

Which brand of psu's are you using?

\

i tried both bitmain psu and HP

I have been using the same LEPA PSUs for 2 years, first on AntMiner S7's then on S9's without any PSU problems at all.  I've had S9 hashboards fry, but not from the power supplies.  The hasboards that fried were always in the one S9 that I have which is Batch 1.  I am fairly certain that it is an overheating problem.  I have two hasboards out of it now, sent off to Bitmain Warranty in Colorado for repair.  When they come back, I am going to underclock that S9 to 600 rather than the default 650 and hope that fixes the problem.  In case anyone is interested in the model of PSU I use, they are LEPA G Series G1600-MA 1600W ATX12V / EPS12V SLI Ready CrossFire Ready 80 PLUS GOLD Certified Full Modular Power Supply.  I can't speak for all of them, but my anecdotal testimonial evidence is that I have had 3 of them running for 2 years solid, without a minute of downtime other than a couple brief power outages to my house for a couple hours or when I manually shut them down to remove the hashboards to send in for repair.  The PSUs themselves have never had any problem, even when running the S7s, which used more wattage than the S9s.  When I had the S7's I would have at least 2 industrial surge protectors burn out completely, frying the circuit breaker to toast, per month.  That was sheer agony.  I couldn't find a surge protector that was S7-proof.  I have never had one fry with my S9s.

my S9 are auto
how can i underclock it?

Log into your miner. Click on Miner Configuration. Go up into the ip address. Delete the word "Configuration". Type the word "Advanced" with the capital "A". Hit enter. Choose the frequency you want.

thanks

[kano]

Been stepping though, over the last half hour, each of the nodes and restarting them - not the main node this time.
Each time was to firstly update the node code, but doing them slowly one after the other so as not to failover the whole pool at once, since the update means a failover for each miner on the node.
All updated and working ok.
Mine on.

[kano]

Orphan ... analysing why - looks like it as a quick double block by BTC.COM to orphan our 'winning' block.
Will post later once I've worked out the details.

[miguelmorales85]

Orphan ... analysing why - looks like it as a quick double block by BTC.COM to orphan our 'winning' block.
Will post later once I've worked out the details.

We wait the explanation why it was an orphan block

Thank you Kano

[kano]

Orphan ... analysing why - looks like it as a quick double block by BTC.COM to orphan our 'winning' block.
Will post later once I've worked out the details.

Was actually a stale share.

The 'other' 492189 block arrived at the NL node at 10:56:12.957 UTC

Code:

2017-10-29 10:56:12.956881 ProcessNewBlock
2017-10-29 10:56:13.167517 UpdateTip: new best=0000000000000000008d4bff4bc5796f98bee7e75d9c93c4d0303a7f10d5fdc8 height=492189 version=0x20000000 log2_work=87.372267 tx=266530212 date='2017-10-29 10:56:05' progress=1.000000 cache=129.8MiB(55037tx) warning='3 of last 100 blocks have unexpected version'

The share for our block arrived at 10:56:16.414, so it was a stale share.
When we get a stale share, we switch our work to it to attempt to confirm our block, however the rest of bitcoin will be mining the 'other' 492189 block.
So it becomes a race between us and the rest of the world so either we get a double block, or someone elsewhere finds a block and we get orphaned.

The expected result is based on our hash rate of course, so if we are about 1% of bitcoin, we should expect to win this double block 1% of the time a stale happens
Normally it would just be a stale block and be completely ignored, so this is a little better for us than that.

Alas, we didn't confirm it, so it was orphaned by the 'other' pool finding the next network block.
It's a stale, not an orphan, so I've updated it as such.

[miguelmorales85]

Orphan ... analysing why - looks like it as a quick double block by BTC.COM to orphan our 'winning' block.
Will post later once I've worked out the details.

Was actually a stale share.

The 'other' 492189 block arrived at the NL node at 10:56:12.957 UTC

Code:

2017-10-29 10:56:12.956881 ProcessNewBlock
2017-10-29 10:56:13.167517 UpdateTip: new best=0000000000000000008d4bff4bc5796f98bee7e75d9c93c4d0303a7f10d5fdc8 height=492189 version=0x20000000 log2_work=87.372267 tx=266530212 date='2017-10-29 10:56:05' progress=1.000000 cache=129.8MiB(55037tx) warning='3 of last 100 blocks have unexpected version'

The share for our block arrived at 10:56:16.414, so it was a stale share.
When we get a stale share, we switch our work to it to attempt to confirm our block, however the rest of bitcoin will be mining the 'other' 492189 block.
So it becomes a race between us and the rest of the world so either we get a double block, or someone elsewhere finds a block.

The expected result is based on our hash rate of course, so if we are about 1% of bitcoin, we should expect to win this double block 1% of the time a stale happens
Normally it would just be a stale block and be completely ignored, so this is a little better for us than that.

Alas, we didn't confirm it, so it was orphaned by the 'other' pool finding the next network block.
It's a stale, not an orphan, so I've updated it as such.

don't you think this wont happen if more nodes where connected to the mining nodes?

Maybe I'm writing a technical stupidity but what if everyone of us set our node to the Kano nodes? whitelist  them or something

[kano]

Orphan ... analysing why - looks like it as a quick double block by BTC.COM to orphan our 'winning' block.
Will post later once I've worked out the details.

Was actually a stale share.

The 'other' 492189 block arrived at the NL node at 10:56:12.957 UTC

Code:

2017-10-29 10:56:12.956881 ProcessNewBlock
2017-10-29 10:56:13.167517 UpdateTip: new best=0000000000000000008d4bff4bc5796f98bee7e75d9c93c4d0303a7f10d5fdc8 height=492189 version=0x20000000 log2_work=87.372267 tx=266530212 date='2017-10-29 10:56:05' progress=1.000000 cache=129.8MiB(55037tx) warning='3 of last 100 blocks have unexpected version'

The share for our block arrived at 10:56:16.414, so it was a stale share.
When we get a stale share, we switch our work to it to attempt to confirm our block, however the rest of bitcoin will be mining the 'other' 492189 block.
So it becomes a race between us and the rest of the world so either we get a double block, or someone elsewhere finds a block.

The expected result is based on our hash rate of course, so if we are about 1% of bitcoin, we should expect to win this double block 1% of the time a stale happens
Normally it would just be a stale block and be completely ignored, so this is a little better for us than that.

Alas, we didn't confirm it, so it was orphaned by the 'other' pool finding the next network block.
It's a stale, not an orphan, so I've updated it as such.

don't you think this wont happen if more nodes where connected to the mining nodes?

Maybe I'm writing a technical stupidity but what if everyone of us set our node to the Kano nodes? whitelist  them or something

Nope, it has nothing to do with that.
It's simply a stale share, that in normal circumstances would be treated as if it didn't exist at all.

However, I 'harassed' core about the ability to switch blocks about 2 years ago:
 https://github.com/bitcoin/bitcoin/issues/6995
One core programmer actually implemented it to be able to switch with less rigorous requirements:
 https://github.com/bitcoin/bitcoin/pull/6996
Then it was committed into core about a year later.
Then ckpool was updated to use it some time after that.

Thus when we get a stale share submitted to the pool that is a block, the pool will switch to work on that instead.
As stated, this gives a chance of getting a double block instead of ignoring the stale one.
Seems like a good idea

[os2sam]

don't you think this wont happen if more nodes where connected to the mining nodes?

Maybe I'm writing a technical stupidity but what if everyone of us set our node to the Kano nodes? whitelist  them or something

This block would have still been 4 seconds after the other's block.

[NomadGroup]

A stale???  The situation just got fuck....d up even more than it was! Just because of this block I think we will get another 10ph or so jumping the ship!