Bitcoin Forum
December 02, 2016, 06:13:31 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 [115] 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 ... 376 »
  Print  
Author Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]  (Read 774685 times)
AfricanHunter
Full Member
***
Offline Offline

Activity: 157


View Profile
December 16, 2012, 11:16:58 PM
 #2281

Apologies for downtime earlier today. I was away and had to use a cell phone to get things going again. Haven't really been able to investigate the issue much yet. But it seems to be running smoothly again after the restart. What I can say is that namecoind had crashed (as usual), but there must have been something more wrong.

Today's insight into networking magic for the techies:
One weird new thing I have learned about Linux/TCP lately. If namecoind is down and a process tries to connect to it, then Linux may pick the destination port to also be the source port for the connection. If this happens when connecting to localhost then the socket will connect to itself. Yes, even though you were connecting, not listening. After that the pool thinks it is talking to namecoind, but for every HTTP request it sends it doesn't get an HTTP response back, it gets its own HTTP request back. It is talking to itself. A real pain, and very odd behavior by the network stack in my opinion, whether it is by TCP specs or not.


Seems like we are having an unusual amount of downtime, or is it just my imagination? If not imagining it, any idea on wheat the cause is?

Thinking about doing business with johnniewalkerhttps://bitcointalk.org/index.php?action=profile;u=72227?
First read this thread https://bitcointalk.org/index.php?topic=131841.0

Also, Join the National Rifle Association to protect 2nd Amendment Rights http://membership.nrahq.org/default.asp?campaignid=XR020022
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480702411
Hero Member
*
Offline Offline

Posts: 1480702411

View Profile Personal Message (Offline)

Ignore
1480702411
Reply with quote  #2

1480702411
Report to moderator
1480702411
Hero Member
*
Offline Offline

Posts: 1480702411

View Profile Personal Message (Offline)

Ignore
1480702411
Reply with quote  #2

1480702411
Report to moderator
1480702411
Hero Member
*
Offline Offline

Posts: 1480702411

View Profile Personal Message (Offline)

Ignore
1480702411
Reply with quote  #2

1480702411
Report to moderator
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 16, 2012, 11:48:42 PM
 #2282

Seems like we are having an unusual amount of downtime, or is it just my imagination? If not imagining it, any idea on wheat the cause is?

The last downtime looks to be the issue with the socket connecting to itself after namecoind goes down. That's the second time this has happened.

namecoind is being monitored and will attempt to restart. But in the meantime the pool keeps retrying to establish contact with namecoind. If namecoind doesn't come back up soon enough it can happen that Linux picks the source port to be the same as the destination port, as I attempted to explain in the previous message. Then the pool connects to itself and gets a bit confused. Also namecoind is unable to start after that because the port is already in use.

I can work around this issue so it won't happen anymore. I will also make the pool service more robust (regarding crashing coin backends) and add a semi-intelligent automatic restart of the pool service if it ceases to function properly.

This should allow to keep merged mining of the unmaintained and constantly crashing namecoin, without the stability issues for the pool. I can hear some of you saying "just kill namecoin". But as long as they are a decent income boost it makes sense to keep them, right? That's assuming I can isolate the bugs in namecoin to just the namecoin side of mining and keep the pool itself stable.

I do fear namecoin is dying though, after all its developers abandoned it. To all developers making me-too coins: become a namecoin dev instead, it makes more sense.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
December 16, 2012, 11:56:39 PM
 #2283

I can hear some of you saying "just kill namecoin". But as long as they are a decent income boost it makes sense to keep them, right?
They are? I didn't notice...
If (or when) there's a merged-minable coin that makes sense to have, I plan to implement merged-mining in BFGMiner using GBT, so miners don't need to depend on their Bitcoin pool for it. Wink

philipma1957
Legendary
*
Offline Offline

Activity: 1568


I charge NOTHING for current signature.


View Profile
December 17, 2012, 12:38:33 AM
 #2284

I can hear some of you saying "just kill namecoin". But as long as they are a decent income boost it makes sense to keep them, right?
They are? I didn't notice...
If (or when) there's a merged-minable coin that makes sense to have, I plan to implement merged-mining in BFGMiner using GBT, so miners don't need to depend on their Bitcoin pool for it. Wink


 so you think  namecoins are not worthwhile? maybe you are correct.

right now I am earning quite a few quite quickly.

I figure about 8 to 9 nmc for each btc.  

I earn 1 btc a day and lets say 9 nmc a day. so every 22 days = 200nmc or a bitcoin/

 so in a year 17 btc. or about 225 usd or half of one of my 16 gpus.

 also lets me sit on them and hope for a rate shift with little risk.


 the question is what are they costing me in down time.

██     Please support sidehack with his new miner project Send to :

1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr

 
 ██
juhakall
Sr. Member
****
Offline Offline

Activity: 422



View Profile
December 17, 2012, 04:02:37 AM
 #2285

Today's insight into networking magic for the techies:
One weird new thing I have learned about Linux/TCP lately. If namecoind is down and a process tries to connect to it, then Linux may pick the destination port to also be the source port for the connection. If this happens when connecting to localhost then the socket will connect to itself. Yes, even though you were connecting, not listening. After that the pool thinks it is talking to namecoind, but for every HTTP request it sends it doesn't get an HTTP response back, it gets its own HTTP request back. It is talking to itself. A real pain, and very odd behavior by the network stack in my opinion, whether it is by TCP specs or not.

That sounds indeed strange, but I can easily replicate it with netcat. nc -p 1234 localhost 1234. I can connect using whatever port, and netstat shows only a single socket, not two like localhost connections usually require. Interesting!

Can't you work around that by detecting this condition in the pool code? Perhaps by checking if there is a corresponding receiving end socket, using netstat or whatever syscalls netstat itself uses. Obviously I don't know what it looks like or even how customizable it is for you, just thinking aloud.

Or you could limit the source port range that you're using, so that the destination port doesn't get picked up.

EDIT: I found a conversation with a good fix for this problem: http://stackoverflow.com/questions/5139808/tcp-simultaneous-open-and-self-connect-prevention. Here's the relevant part: "Bind the client socket to port 0 (system assigns), check the system assigned port, if it matches the local server port you already know the server is down and and can skip connect()."
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 17, 2012, 07:20:56 AM
 #2286

Some instability this morning due to an insane spam of getwork requests from some miners. This has happened a couple times lately. I may have to work further on protecting against this. Perhaps block the IP address in the firewall for 5 minutes if you request too much work too quickly.

I can hear some of you saying "just kill namecoin". But as long as they are a decent income boost it makes sense to keep them, right?
They are? I didn't notice...

Bitcoin difficulty is 3.5 times higher than namecoin, and after the reward halving bitcoin makes roughly (not considering tx fees) half the coins per block. So namecoins are produced 7 times as fast as bitcoins. Right now I see namecoins sold 216 for 1 bitcoin. 7/216=0.0324... So namecoins give a 3.2% extra income.

3.2% extra income is a major feature for my pool, so I'll keep it if I can.

That sounds indeed strange, but I can easily replicate it with netcat. nc -p 1234 localhost 1234. I can connect using whatever port, and netstat shows only a single socket, not two like localhost connections usually require. Interesting!

Yeah, and anything you type gets echoed back to you, as the socket is connected to itself. A really annoying "feature".

Can't you work around that by detecting this condition in the pool code? Perhaps by checking if there is a corresponding receiving end socket, using netstat or whatever syscalls netstat itself uses. Obviously I don't know what it looks like or even how customizable it is for you, just thinking aloud.

Or you could limit the source port range that you're using, so that the destination port doesn't get picked up.

I'm going to do the second, as it is the quickest. But maybe I'll do the first as well. If source and destination ports are the same and you are connected to localhost, immediately disconnect and consider it the same as a failure to connect.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
juhakall
Sr. Member
****
Offline Offline

Activity: 422



View Profile
December 17, 2012, 07:48:39 AM
 #2287

Can't you work around that by detecting this condition in the pool code? Perhaps by checking if there is a corresponding receiving end socket, using netstat or whatever syscalls netstat itself uses. Obviously I don't know what it looks like or even how customizable it is for you, just thinking aloud.

Or you could limit the source port range that you're using, so that the destination port doesn't get picked up.

I'm going to do the second, as it is the quickest. But maybe I'll do the first as well. If source and destination ports are the same and you are connected to localhost, immediately disconnect and consider it the same as a failure to connect.


Limiting the source port range is a really good idea, so that namecoind won't fail to start. Even if you fix the pool connecting to itself problem, some other program might randomly get namecoind's port. Doesn't namecoind have an option to change the listening port to something more sensible?
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 17, 2012, 09:58:56 AM
 #2288

Limiting the source port range is a really good idea, so that namecoind won't fail to start. Even if you fix the pool connecting to itself problem, some other program might randomly get namecoind's port. Doesn't namecoind have an option to change the listening port to something more sensible?

Sure, that's what I was going to do.

And yes, namecoind has configurable ports just like bitcoind. In fact the config file is named bitcoin.conf. I think in the latest namecoin versions you are allowed to rename the file to namecoin.conf. But I always thought it was silly they didn't even bother to change the name "bitcoin" everywhere.

It always gave me the impression: "Dude, you should totally invest in my coin. I spent like 10 minutes renaming bitcoin. Oh, I may have missed a couple places, but it's an awesome coin!" Actually I get that impression from all the "alt coins". Cheesy

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
December 17, 2012, 11:22:37 PM
 #2289

Its'a down.
Equilux
Sr. Member
****
Offline Offline

Activity: 308


View Profile
December 17, 2012, 11:50:32 PM
 #2290

Its'a down.

Yeah, and it's been a bit unstable for me aswell, but I just read the last few post and that seems to be solved now?

WhitePhantom
Sr. Member
****
Offline Offline

Activity: 349



View Profile
December 18, 2012, 02:22:16 AM
 #2291

Is it still down for everybody else or is it just me?
m3ta
Sr. Member
****
Offline Offline

Activity: 427



View Profile WWW
December 18, 2012, 02:24:54 AM
 #2292

Is it still down for everybody else or is it just me?

Down.

Why the frell so many retards spell "ect" as an abbreviation of "Et Cetera"? "ETC", DAMMIT! http://en.wikipedia.org/wiki/Et_cetera

Host:/# rm -rf /var/forum/trolls
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 18, 2012, 03:03:18 AM
 #2293

Something wrong, working on it.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 18, 2012, 03:19:10 AM
 #2294

Back up again... sorry for the downtime Sad

Not namecoin this time. Something strange going on, will need to investigate further.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
miter_myles
Hero Member
*****
Offline Offline

Activity: 742



View Profile
December 18, 2012, 03:22:20 AM
 #2295

thanks!

BTC - 1D7g5395bs7idApTx1KTXrfDW7JUgzx6Z5
LTC - LVFukQnCWUimBxZuXKqTVKy1L2Jb8kZasL
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
December 18, 2012, 05:40:05 AM
 #2296

Something strange going on...

Cheesy


DrHaribo
Legendary
*
Offline Offline

Activity: 1960


Bitminter.com Operator


View Profile WWW
December 18, 2012, 12:30:07 PM
 #2297

Turbor, your explanation is as good as any I can come up with.

Looks like all I/O got slower and slower. After a while some getwork requests took 5 minutes. The database connections terminated with "end of file" and it was impossible to establish new ones. syslog tells me the web server got stuck for over 120 seconds waiting for a page from disk. But there is nothing wrong with the disks. The pool server had several hundred thousand closed connections that somehow the kernel stopped clearing away. The load was 25-30 with almost no cpu usage. Apparently all these processes were waiting on IO. I could still send a request to bitcoind or namecoind and it would register in their logs but no response would come out. After restarting each process everything is fine. It's like the kernel just wouldn't honor IO requests from the "old" processes. I've never seen anything like it.

So yes, maybe it was the ghost in the machine.

I'll be working on robustness and automatic recovery, although I hope not to see this type of behavior again.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
December 18, 2012, 06:48:29 PM
 #2298

DrHaribo, what you think about implementing Hall of Fame (users who found most amount of blocks) like in Slush pool?

http://mining.bitcoin.cz/stats/hall-of-fame/
loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
December 18, 2012, 11:18:35 PM
 #2299

Turbor, your explanation is as good as any I can come up with.

Any recent kernel upgrade of the pool? If yes just go back to old one Wink

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
December 18, 2012, 11:40:19 PM
 #2300

.... although I hope not to see this type of behavior again.

Everyone says this about their child at some point Wink

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Pages: « 1 ... 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 [115] 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 ... 376 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!