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

Something wrong, working on it.

Down.

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

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?

Its'a down.

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

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?

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.


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.


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


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.

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

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.

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.

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?

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.

indeed - it does appear to be down.

Will

Looks like it's down / unstable again.

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

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.

Can't remember - probably not.

However, I contacted them when I first got the BFL coz it took 8 hours to 'burn in' but after that was OK until the problem much later.
The first day problems were most likely the heat sink since it rattled when I first got it - and running hot for 8 hours probably helped reseat it properly

The later problem went something like this:
damn it having problems, spent a week (or 2 or ?) messing with the cgminer code sometimes mining full speeds, sometimes half speed (power cycles sometimes helped) then finally decided, stuff this I'll put in a fast bitstream and see how long it takes to kill it
880 didn't kill it I'm still using the 880.

I also found that with the 880 bitstream it worked at a much higher reported temperature without throttling.
At the moment it says 61.5C (when I first got the BFL it throttled around 50C with the 832 bitstream)

Last time it throttled/had a comm error was ... 8-Nov ... had 8 that day coz it was very hot here (it's now summer)
Previous was 16-Oct - 3 times - was a hot early evening and that's the time it throttled also.

Weird but seems to have gone away after reflash. I contacted bfl as now my fan is noisy and temp up by 2 degrees (still within normal range) so they are sending me a new fan and some thermal paste to refit the sink. Dont think the two issues are related but odd none the less.

Did you contact bfl about it and if so what was their response?

Yep quite a while back one of the two FPGAs in my BFL became randomly unreliable using the 832 bitstream.
Sometimes completely stopped mining in half the device.
Flashed it up to 880 (after messing with cgminer code and the device over a few weeks)
After reflash it was OK for a while then failed again.
2nd reflash and no problems since.
So ... yep that can cause a drop to half