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

[AfricanHunter]

Tried one of the faster streams a while back but was throttling bad, may try the others based on what you report. Also going to replace the fan and redo the thermal compound. If you have any ideas I'm all ears.

[1714136425]

1714136425

[1714136425]

1714136425

[1714136425]

1714136425

[DrHaribo]

Sorry, a technical issue made the pool unstable (many failed connection attempts if you didn't already have an active connection). Now fixed.

[juhakall]

Looks like it's down / unstable again.

[willphase]

Looks like it's down / unstable again.

indeed - it does appear to be down.

Will

[DrHaribo]

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.

[AfricanHunter]

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?

[DrHaribo]

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.

[Luke-Jr]

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.

[juhakall]

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]

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.

[juhakall]

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]

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".

[LazyOtto]

Its'a down.

[Equilux]

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]

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

[m3ta]

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

Down.

[DrHaribo]

Something wrong, working on it.

[DrHaribo]

Back up again... sorry for the downtime

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

[miter_myles]

thanks!

[Turbor]

Something strange going on...