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
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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <grarpamp@gmail.com>) id 1StRBz-0006Yx-1V
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Jul 2012 22:33:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=grarpamp@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1StRBy-00037f-Cr
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Jul 2012 22:33:30 +0000
Received: by obcva7 with SMTP id va7so10844509obc.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Jul 2012 15:33:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.1.40 with SMTP id 8mr23060860oej.70.1343082804750; Mon, 23
Jul 2012 15:33:24 -0700 (PDT)
Received: by 10.76.81.10 with HTTP; Mon, 23 Jul 2012 15:33:24 -0700 (PDT)
In-Reply-To: <CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
References: <CAD2Ti29dqCYoOMcX0zcOQnpLGCxnCjYHHqMzyyq+hvcVQ2c7nQ@mail.gmail.com>
<CAAS2fgTHrWdXHbX8oiLgnrhdC+yxL4QyPd7S4iB8RMNip_sUGg@mail.gmail.com>
<A428177D-62AD-4712-9053-47B7ED5DBC84@mac.com>
<CAD2Ti2-3sR_qusfmiStb8pzaxaB8DsPaK8a2+LWm_uL+DwvzeA@mail.gmail.com>
<CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
Date: Mon, 23 Jul 2012 18:33:24 -0400
Message-ID: <CAD2Ti2_Pz9-SsHP49+6MKnM0er9zdAaFKDQaOgqDpju1_igd_g@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(grarpamp[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1StRBy-00037f-Cr
Subject: Re: [Bitcoin-development] Scalability issues
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: Mon, 23 Jul 2012 22:33:31 -0000
> You're seriously suggesting that I'm using a system
> which is 720x (one month vs one hour) faster than your
> P4 1.8GHz?
Don't know what you're using since you've not stated it.
> I find this doubtful, especially since bitcoin's sync is effectively
> single threaded.
Extra cores help with disk, crypto, net, etc...
> month
I've spent about two weeks crunching about the last month's
worth of new blocks.
> Your results are not expected and are not believed to be
> representative.
The config is reproducible, and not believed to be uncommon.
> try to isolate it
Mostly disk and crypto.
Shall everyone instead run in bitrot and no-privacy mode?
What do we do when we've got 10k trans a day coming in?
50k? 100k, 1M? When the chain gets 1M, 50M, 500M, 1B long?
Forget my swamped box, these numbers are coming to others.
> try to sync from a local node into tmpfs
I'd bet some people using 'tmpfs' probably have it unknowingly
[fall]backed to swap instead of core.
Bitcoin already takes up 3GiB of disk, how many have that much
free RAM? How many have 30GiB, 300GiB?
> If you're building against BDB later than the recommended 4.8
> be aware that there have been performance regressions with later
> versions
Yes, I left out that bit of platform so here are the remaining
bits... db4830, boost149, vm.kmem_size=650000000
I'm not bashing anything or anybody, just detailing a stock config
that is underwater. Anybody wishing to verify can get the hardware
from their junk pile and the software from freebsd.org. I'll certainly
be looking at both it and different setups too. If anyone's using
say Linux/BSD, BTRFS/ZFS, crypto, on i386/amd64, they could
chime in with their times too.
Disk is the cheapest, easiest thing for Joe to get. Think about
indexing and checkpointing into said disk. I don't know what
bitcoin's doing, but if it's verifying every transaction back to
the root, that would seem a bit ridiculous.
Joe probably won't be happy buying TiB's for bitcoind, so after that's
filled (assuming there's CPU to do it), the trust model has to change.
These scales are coming...
|
