slush (OP)
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
May 10, 2011, 08:05:41 AM |
|
thanks for getting things back up and running and really smooth so quickly since getting back from holiday.
In fact, I started with repair immediately when I came home; I still had jacket and shoes when pool started to work again
|
|
|
|
dbitcoin
|
|
May 10, 2011, 08:08:53 AM |
|
What happen?On Saturday's evening (UTC), bitcoin daemons on two independent pool servers ate all available memory (RAM & swap) and fall to massive I/O operations, which make servers extremely slow. Central server switched traffic to the last machine, but this machine was unable to handle all traffic and some RPC calls started to timeout. Then those miners getting RPC timeouts probably started to ask server even more frequently (miners don't implement any "polite waiting" in the code and send new RPC call immediately after error/timeout). Those thousands of requests per second were the last piece to shut down last working machine . Time for implement this (polite waiting) in miners?
|
|
|
|
slush (OP)
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
May 10, 2011, 09:19:05 AM |
|
Time for implement this (polite waiting) in miners?
Yes, it would be very nice from miner developers...
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
|
May 10, 2011, 09:57:42 AM |
|
Is it a known bug in the bitcoin daemon that initiated the failure cascade?
Or is it untraceable? Would be good to get some development work done on that too, no?
|
|
|
|
slush (OP)
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
May 10, 2011, 10:53:51 AM |
|
Is it a known bug in the bitcoin daemon that initiated the failure cascade? Or is it untraceable? Would be good to get some development work done on that too, no?
Initial problem was that bitcoind ate few GB of memory. It was first time I've seen that and cannot tell if it is bug or some kind of P2P attack as mentioned in my previous post.
|
|
|
|
Cdecker
|
|
May 10, 2011, 01:15:18 PM |
|
cdhowie started implementing a nice proxy that would switch pools should it become unreachable: http://bitcointalk.org/index.php?topic=5506.0;allWe are also working on exponential backoff, so that the pools wouldn't get hammered all the time, until miners start implementing these features themselves this might be an option for serious miners
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
May 10, 2011, 01:20:56 PM |
|
Lesson learna) Don't take holiday b) If I'll take holiday, don't tell it anybody . c) Try to setup watchdog restarting bitcoind when it started to use too much memory. Man, option a) Is fucking sad! Don't do that.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
sniper_sniperson
|
|
May 10, 2011, 01:42:41 PM |
|
Maybe a small business partner or other worker to watch over pool when you are off-line?
A nice script that sends you SMS with current memory usage will do the job. Hard one is to find a working connection in some mountain regions
|
|
|
|
warweed
|
|
May 10, 2011, 03:04:04 PM |
|
I'm certainly not complaining but what's happening here I haven't seen payouts like this since difficulty was in the 72k range
4292 2011-05-09 08:01:35 1:36:01 172239 1.47401750 122845 confirmed 4291 2011-05-09 06:25:34 1:15:57 131205 1.46427140 122834 confirmed 4290 2011-05-09 05:09:38 2:53:08 286294 1.57936660 122818 confirmed 4289 2011-05-09 02:16:30 0:47:36 73450 1.48812870 122789 confirmed 4288 2011-05-09 01:28:55 11:39:09 749522 1.41574380 122779 confirmed 4287 2011-05-08 13:50:02 16:05:01 526237 2.06949460 - invalid 4286 2011-05-07 21:45:01 1:29:59 229074 0.98312942 - invalid 4285 2011-05-07 20:15:03 0:02:10 6894 0.86713079 122515 confirmed 4284 2011-05-07 20:12:53 0:31:04 109518 0.79117583 122513 confirmed 4283 2011-05-07 19:41:49 0:43:54 161832 0.82696945 122511 confirmed 4282 2011-05-07 18:57:55 0:03:51 14381 0.72379974 122503 confirmed
|
|
|
|
unxetas
Newbie
Offline
Activity: 14
Merit: 0
|
|
May 10, 2011, 03:22:55 PM |
|
The pool's size is down considerably, so you're taking a much larger share of each block.. It's also taking longer to solve a block, obviously, but that looks pretty good to me
|
|
|
|
|
warweed
|
|
May 10, 2011, 04:45:11 PM |
|
Wow yeah I didn't even notice the round tim :s lame
|
|
|
|
dishwara
Legendary
Offline
Activity: 1855
Merit: 1016
|
|
May 10, 2011, 08:17:10 PM |
|
4 hours still can't? Current round duration: 3:50:42
|
|
|
|
d0ct0r
Newbie
Offline
Activity: 12
Merit: 0
|
|
May 10, 2011, 08:27:52 PM |
|
no block in 610k shares... wow
|
|
|
|
warweed
|
|
May 10, 2011, 08:47:49 PM Last edit: May 10, 2011, 09:09:44 PM by warweed |
|
Sorry slush when things get better I may come back but for now Time for tyco to collect a percent althou the image thing isn't overly accurate lol it jumps like 300 mhash/s
|
|
|
|
|
Dayofswords
Member
Offline
Activity: 138
Merit: 11
Exchange BTC in Telegram https://bit.ly/2MEfiw8
|
|
May 10, 2011, 08:53:24 PM |
|
no block in 610k shares... wow
difficulty is a jerk.
|
|
|
|
dishwara
Legendary
Offline
Activity: 1855
Merit: 1016
|
|
May 10, 2011, 09:10:52 PM |
|
But if all are mining for current block only means then how can other pools solving blocks? I think a bug is there, which instead of current block also counting the shares of all the blocks which got solved for the past 4 hours. Seems locked somewhere which is still trying to solve one particular block while other pools solves blocks. In deepbit many blocks solved.
|
|
|
|
xenon481
|
|
May 10, 2011, 09:14:00 PM |
|
But if all are mining for current block only means then how can other pools solving blocks? I think a bug is there, which instead of current block also counting the shares of all the blocks which got solved for the past 4 hours. Seems locked somewhere which is still trying to solve one particular block while other pools solves blocks.
In deepbit many blocks solved.
The "bug" is called Variance.
|
Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
|
|
|
BitterTea
|
|
May 10, 2011, 09:29:23 PM |
|
Well, deepbit is stating >500Ghash/s, whereas slush's pool is at around 180Ghash/s. They should be finding 3x as many blocks as we are. Combine that with an unlucky round, and you've got a five hour round. Can a well timed DDOS kill a pool?
|
|
|
|
|