📅 Original date posted:2012-07-23
📝 Original message:> 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...
grarpamp [ARCHIVE] /
npub1rj…vs23t
2023-06-07 10:25:11
in reply to nevent1q…srax
Author Public Key
npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23tSeen on
wss://relay.nostr.bandPublished at
2023-06-07 10:25:11Event JSON
{
"id": "73dd39c6fcc685c32a675a96062d568c30a7f7bdee5460f96c0e141b6c6c2b87",
"pubkey": "1c840f1e75d7845e20cc48358219b63ce235ccf72a89298d799e6bda2907af87",
"created_at": 1686133511,
"kind": 1,
"tags": [
[
"e",
"63aed588f060c9675f9ddd34399756623e96cc693cda2679b108affeaacc7675",
"",
"root"
],
[
"e",
"924dcf50859c79f7551173cb2abed6bc22a6561fca863032cd5307f966907cb4",
"",
"reply"
],
[
"p",
"38fb9fcb632ad32c4bd3c3008b319ead7b53af5f0d8af3095417d8587fba132a"
]
],
"content": "📅 Original date posted:2012-07-23\n📝 Original message:\u003e You're seriously suggesting that I'm using a system\n\u003e which is 720x (one month vs one hour) faster than your\n\u003e P4 1.8GHz?\n\nDon't know what you're using since you've not stated it.\n\n\u003e I find this doubtful, especially since bitcoin's sync is effectively\n\u003e single threaded.\n\nExtra cores help with disk, crypto, net, etc...\n\n\u003e month\n\nI've spent about two weeks crunching about the last month's\nworth of new blocks.\n\n\u003e Your results are not expected and are not believed to be\n\u003e representative.\n\nThe config is reproducible, and not believed to be uncommon.\n\n\u003e try to isolate it\n\nMostly disk and crypto.\nShall everyone instead run in bitrot and no-privacy mode?\nWhat do we do when we've got 10k trans a day coming in?\n50k? 100k, 1M? When the chain gets 1M, 50M, 500M, 1B long?\n\nForget my swamped box, these numbers are coming to others.\n\n\u003e try to sync from a local node into tmpfs\n\nI'd bet some people using 'tmpfs' probably have it unknowingly\n[fall]backed to swap instead of core.\n\nBitcoin already takes up 3GiB of disk, how many have that much\nfree RAM? How many have 30GiB, 300GiB?\n\n\u003e If you're building against BDB later than the recommended 4.8\n\u003e be aware that there have been performance regressions with later\n\u003e versions\n\nYes, I left out that bit of platform so here are the remaining\nbits... db4830, boost149, vm.kmem_size=650000000\n\n\nI'm not bashing anything or anybody, just detailing a stock config\nthat is underwater. Anybody wishing to verify can get the hardware\nfrom their junk pile and the software from freebsd.org. I'll certainly\nbe looking at both it and different setups too. If anyone's using\nsay Linux/BSD, BTRFS/ZFS, crypto, on i386/amd64, they could\nchime in with their times too.\n\nDisk is the cheapest, easiest thing for Joe to get. Think about\nindexing and checkpointing into said disk. I don't know what\nbitcoin's doing, but if it's verifying every transaction back to\nthe root, that would seem a bit ridiculous.\n\nJoe probably won't be happy buying TiB's for bitcoind, so after that's\nfilled (assuming there's CPU to do it), the trust model has to change.\nThese scales are coming...",
"sig": "b9652fc5cab75850400526d5b76a981fca06d3be7593f679cf9f5a6f96565f30bf859db0f579f9a43eecaad325a48cf10b1b08ac78d6407de8a39e4f863272cc"
}