Bitcoin Forum
June 22, 2024, 09:34:03 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 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 ... 155 »
1961  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 20, 2012, 11:58:08 PM
bitcoind and namecoind both slowed down at the same time. There's some sort of issue there. Pool recovered after a couple of minutes though.

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?
1962  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 20, 2012, 11:53:54 AM
Stratum port 5050 seems to be down. Port 3333 working OK.

It's working for me. It's just a redirect, so 5050 and 3333 should be up/down at the same time.
1963  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 19, 2012, 04:32:28 PM
Need to restart bitcoind and namecoind. They take a while to get up and running again, sorry for the delay..
1964  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 19, 2012, 02:05:23 PM
Hall of fame is on my list. Smiley

I had eight shifts with zero or near zero scores.

Could be because your miner stayed at a backup pool or that it crashed when it was disconnected by the server. Some miner programs have been having those issues lately.
1965  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 18, 2012, 12:30:07 PM
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.
1966  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 18, 2012, 03:19:10 AM
Back up again... sorry for the downtime Sad

Not namecoin this time. Something strange going on, will need to investigate further.
1967  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 18, 2012, 03:03:18 AM
Something wrong, working on it.
1968  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 17, 2012, 09:58:56 AM
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
1969  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 17, 2012, 07:20:56 AM
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.
1970  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 16, 2012, 11:48:42 PM
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.
1971  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 16, 2012, 09:50:12 PM
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.
1972  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 16, 2012, 05:28:52 AM
Sorry, a technical issue made the pool unstable (many failed connection attempts if you didn't already have an active connection). Now fixed.
1973  Bitcoin / Mining software (miners) / Re: Decentralized mining protocol standard: getblocktemplate (ASIC ready!) on: December 12, 2012, 11:37:06 PM
...and i really thought i could get more information on GBT here.. found myself in a flamewar though. Honestly guys.. noone here is giving a good example.

Sorry that I added to the spam. But there is a reason these forums are so unfriendly. kano has a habit of trolling, name calling, religious harassment, etc. etc. I don't know why he hasn't been banned yet. But if noone says anything, things won't get any better.
1974  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: December 12, 2012, 10:34:26 AM
What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.

Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily).  However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.

Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
1975  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: December 12, 2012, 07:27:52 AM
Maybe I misunderstood you, kano.

So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?

Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?

There's always the third option. You know that I'm right, you just like to write a lot of words.
1976  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: December 12, 2012, 06:49:05 AM
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.
That requires actually storing them all somewhere.

You have to store the merkleroot and the extranonce2 bytes at least until you submit all proofs of work based on them. After that you could free them, but you will need to reallocate that memory to create new work in less than 1 second. It's better to keep those few bytes of memory sitting there until the server gives you new work, rather than constantly free and reallocate those tiny memory fragments.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
... I wonder where I said that Tongue

In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.

Riddle me this: How can a clock never change and yet be accurate?
1977  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 11, 2012, 11:20:06 PM
Sorry for the short downtime. There was an issue with bitcoind which had to be restarted.
1978  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: December 11, 2012, 11:06:24 PM
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
1979  Economy / Securities / Re: [BitFunder] Asset Exchange Marketplace - Official Launch on: December 11, 2012, 02:31:16 PM
Cool to see this going public.

Good luck BitFunder! Smiley
1980  Bitcoin / Pools / Re: [2000 GH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rolllntime] on: December 10, 2012, 12:00:47 PM
So assuming ASICS ship first half of January, do I need to get cgminer setup or will the GUI support it by then? Or do you think Getwork with rollntime will be sufficient for a few Single SC's?

My goal is for BitMinter client to work with BFL SCs from the day you receive them. If I don't have time for everything then that will be with getwork with rollntime. That's good enough for running ASICs. It doesn't allow you to inspect blocks like GBT or give you the low bandwidth usage of Stratum, but it certainly works.

When it comes to bASIC it looks like I won't have remote access to any units until miners have them. It also looks like it will be more complex to add support for them than the BFL units. That means if you ordered bASIC you will want to find a miner that will support them from day 1 so your bASIC doesn't sit idle.

Avalon, from what I understand, comes with a (tiny) computer with preinstalled software. You just plug it in and it runs.

If I will need to use a miner other than the Bitminter app, what do you recommend for BFL equipment? Before bitminter I was using GUIMiner but was getting some strange bugs.

I don't think I want to go there. The GBT versus Stratum discussions are bad enough. If you ordered bASIC then you will probably want to check the bASIC forums to see which miner authors they are working with to get support from day 1.
Pages: « 1 ... 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 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 ... 155 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!