1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1QWXC7-0001qv-J5
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jun 2011 17:14:27 +0000
X-ACL-Warn:
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QWXC6-0006b4-Nc
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jun 2011 17:14:27 +0000
Received: by iye7 with SMTP id 7so6824632iye.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 14 Jun 2011 10:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.161.196 with SMTP id u4mr7504316icx.11.1308071661214; Tue,
14 Jun 2011 10:14:21 -0700 (PDT)
Received: by 10.231.19.203 with HTTP; Tue, 14 Jun 2011 10:14:21 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
In-Reply-To: <BANLkTinuEayfr5S9NEcW+cTLpv2r8iwRgDXYniOAHgQ43zwGqQ@mail.gmail.com>
References: <BANLkTinuEayfr5S9NEcW+cTLpv2r8iwRgDXYniOAHgQ43zwGqQ@mail.gmail.com>
Date: Tue, 14 Jun 2011 13:14:21 -0400
Message-ID: <BANLkTik78Lokrm_09RW5EBkq2mJC3kMzxA@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QWXC6-0006b4-Nc
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bumping up against flood control limits
again?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 17:14:27 -0000
On Tue, Jun 14, 2011 at 12:44 PM, Mike Hearn <mike@plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
The main goal was not flood control but preventing an internal buffer
memory explosion. We already have the block chain on disk, so in
theory, if we can -eliminate- the outgoing network buffer and simply
use a pointer into the block chain file, we can send as much data as
we want.
HTTP servers certainly don't buffer huge amounts in memory; they would
keel over if so. HTTP servers have been working on the reverse, in
fact: moving the data-pushing over to sendfile(2) syscall and similar
optimizations.
This is an unfortunate relic of how bitcoin P2P code is written. If
the remote side has reduced their TCP window to zero, bitcoin will
still buffer so that it may continue processing other P2P traffic from
other nodes. That makes sense in the case of tiny, 31-byte address
messages -- one must handle the case of a half-sent message before
write(2) refuses additional data -- but not huge block chain download
messages.
The P2P code just wasn't written for huge amounts of streaming data,
and needs some serious thinking... I agree 100% that it is an issue
we will start bumping into, if we haven't already.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
