📅 Original date posted:2017-04-08
📝 Original message:I would advise anyone worried about 'hard drive access' to order a
512GB NVME (pci-express interface) flash drive (or a laptop), and
I expect the performance will make you wonder why you ever bothered
with cloud.
My (very brief) analysis of the performance of a full chain download
on a new laptop was that there was more overhead in lock contention and
database writes and it barely loaded the machine. Now maybe this is
because the flash **write** speed is slow (but still several orders
of magnitude above spinning disk), but random reads are sure blazing
fast.
Flash storage sizes also appear to be growing at similiar rates as the
total blockchain size.
Which begs another question: In a distributed byzantine fault-tolerant
system, why do we even need to bother with persistant storage, except
for long-term archival and chain of custody issues, which we could
serialize the in-memory structures out as a stream to things like tape
drives or write-once optical media.
On Fri, Apr 07, 2017 at 11:39:18AM -0700, Bram Cohen via bitcoin-dev wrote:
> Expanding on this question a bit, it's optimized for parallel access, but
> hard drive access isn't parallel and memory accesses are very fast, so
> shouldn't the target of optimization be about cramming as much as possible
> in memory and minimizing disk accesses?
>
> On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements*
> >
> > I'm still lost on this-- AFAICT your proposals long term resource
> > requirements are directly proportional to the amount of unspent output
> > data, which grows over time at some fraction of the total transaction
> > volume (plus the rate of spending which is more or less a constant).
> >
> > Can you help out my understanding here?
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Troy Benjegerdes [ARCHIVE] /
npub1m6…rdjn5
2023-06-07 19:59:42
in reply to nevent1q…s0gq
Author Public Key
npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5Published at
2023-06-07 19:59:42Event JSON
{
"id": "32933114e97d483c0b33310203b786624b9c0ed016883414afcfdd0aa4a7e371",
"pubkey": "de834b230daa8e6d04c44e51929c52dfdc36dc2f4105a0b67060d9dfc30d6ccc",
"created_at": 1686160782,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"2056b90b6ffe94956fceacbea703c5eccb671fb1700b6d528337fdda649dfd31",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-04-08\n📝 Original message:I would advise anyone worried about 'hard drive access' to order a\n512GB NVME (pci-express interface) flash drive (or a laptop), and\nI expect the performance will make you wonder why you ever bothered\nwith cloud.\n\nMy (very brief) analysis of the performance of a full chain download\non a new laptop was that there was more overhead in lock contention and\ndatabase writes and it barely loaded the machine. Now maybe this is\nbecause the flash **write** speed is slow (but still several orders\nof magnitude above spinning disk), but random reads are sure blazing\nfast.\n\nFlash storage sizes also appear to be growing at similiar rates as the\ntotal blockchain size.\n\nWhich begs another question: In a distributed byzantine fault-tolerant\nsystem, why do we even need to bother with persistant storage, except\nfor long-term archival and chain of custody issues, which we could \nserialize the in-memory structures out as a stream to things like tape\ndrives or write-once optical media.\n\n\nOn Fri, Apr 07, 2017 at 11:39:18AM -0700, Bram Cohen via bitcoin-dev wrote:\n\u003e Expanding on this question a bit, it's optimized for parallel access, but\n\u003e hard drive access isn't parallel and memory accesses are very fast, so\n\u003e shouldn't the target of optimization be about cramming as much as possible\n\u003e in memory and minimizing disk accesses?\n\u003e \n\u003e On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \u003e On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003eAs this\n\u003e \u003e \u003e solution, reversing the costs of outputs and inputs, seems to have\n\u003e \u003e \u003e excellent performance characteristics (as shown in the test results),\n\u003e \u003e \u003e updates to the protocol addressing the UTXO growth, might not be worth\n\u003e \u003e \u003e considering *protocol improvements*\n\u003e \u003e\n\u003e \u003e I'm still lost on this-- AFAICT your proposals long term resource\n\u003e \u003e requirements are directly proportional to the amount of unspent output\n\u003e \u003e data, which grows over time at some fraction of the total transaction\n\u003e \u003e volume (plus the rate of spending which is more or less a constant).\n\u003e \u003e\n\u003e \u003e Can you help out my understanding here?\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "3b827a4cac8752b2a13342e9dd72a5fd7cd7a0bceec5471433ab340bdca414c5bd2f8eb4f6403013a7bb9bf7315a82e5275eb132caa00856f27ced66a0027c19"
}