04:24:54 <tokineko[m]> Why does full node synchronization become really slow after 60%?
04:26:12 <tokineko[m]> CPU is not really sweating much. But, there's a lot of HDD activity and network activity while my monerod node is not really synchronizing.
04:30:23 <tokineko[m]>  * CPU is not really sweating much. But, there are some network activity and a lot of HDD activity while my monerod node is not really synchronizing.
04:31:08 <tokineko[m]>  * CPU is not really doing much. But, there are some network activity and a lot of HDD activity while my monerod node is not really synchronizing.
04:39:48 <tokineko[m]> What does this mean?
04:39:48 <tokineko[m]> WARNING net.p2p.tx      src/cryptonote_protocol/levin_notify.cpp:680    Unable to send transaction(s) to tor - no suitable outbound connections at height 1433360
04:44:20 <nioc> an HDD will be much much slower than an SSD
04:45:25 <nioc> at some point RingCt was introduced which slows down the syncing
04:46:18 <nioc> also as time goes on there are more txs per unit of time so .......
05:03:19 <tokineko[m]> Why does it put a lot of burden on HDD instead of CPU?
05:03:39 <tokineko[m]> HDD can surely read and write much faster.
05:09:57 <nioc> I can't properly explain it but it is true.  When using an SSD the read and writes will no longer be the bottle neck but the cpu will still not be working very hard
05:10:51 <nioc> SSD = ~12hrs.  HDD will take several days
07:21:25 <xmrscott[m]1> <tokineko[m] "Why does it put a lot of burden "> HDD's typically have a write speed of around 100-120 megabytes per sec. SATA interface is designed for 600, *and* typically your board is going to have multiple SATA ports.
07:22:13 <xmrscott[m]1> In short, a single HDD doesn't really push the capacity of a CPU
07:22:44 <xmrscott[m]1> > <@tokigami.kineko:matrix.org> Why does it put a lot of burden on HDD instead of CPU?
07:22:44 <xmrscott[m]1>  * HDD's typically have a write speed of around 100-120 megabytes per sec. The SATA interface they used is designed for 600, _and_ typically your board is going to have multiple SATA ports.
07:23:08 <xmrscott[m]1>  * In short, a single HDD doesn't really push the capacity of a CPU's specs
07:23:17 <tokineko[m]> Still, I don't understand why monerod pushes HDD so hard for very slow synchronization.
07:28:30 <xmrscott[m]1> HDD's are simply quite slow for reads and writes. Have you ever tried I don't know a good point of reference, downloading DLC back in the Xbox 360 (which had HDD back then). Or downloading a Steam game on a HDD? The expectation is that HDD's are slow
07:28:42 <xmrscott[m]1>  * HDD's are simply quite slow for reads and writes. Have you ever tried... I don't know a good point of reference, downloading DLC back in the Xbox 360 (which had HDD back then). Or downloading a Steam game on a HDD? The expectation is that HDD's are slow
07:28:52 <xmrscott[m]1>  * HDD's are simply quite slow for reads and writes. Have you ever tried... I don't know a good point of reference, downloading DLC back in the Xbox 360 days (which had HDD back then). Or downloading a Steam game on a HDD? The expectation is that HDD's are slow
07:30:32 <xmrscott[m]1>  * HDD's are simply quite slow for reads and writes. Have you ever tried... I don't know a good point of reference, downloading DLC back in the Xbox 360 days (which had HDD back then). Or booting a computer on HDD vs SSD? The expectation is that HDD's are slow
09:27:26 <midipoet> anybody here use TrezorOne?
09:27:35 <midipoet> as their hardware wallet?
09:32:45 <tokineko[m]> Still, monerod is synchronizing too slow.
09:33:18 <tokineko[m]>  * Still, monerod is synchronizing too slowly. HDD may not be the real bottleneck....
09:34:03 <tokineko[m]> HDD should be capable of far more than 20 blocks per minute.
09:34:10 <tokineko[m]>  * HDD should be capable of processing far more than 20 blocks per minute.
09:34:37 <tokineko[m]> It's not like HDD is responsible for verifying blocks.
09:42:46 <Mumuks[m]> <tokineko[m] "It's not like HDD is responsible"> It is responsible of storing them
09:48:45 <tokineko[m]> HDD can write far more blocks than 20 blocks per minute.
09:49:04 <SerHack> pigeons: could you please send me a pm?
12:18:08 <sethsimmons> <tokineko[m] "HDD can write far more blocks th"> Hey tokineko -- the issue here is not the amount if data, its the amount of random reads and writes (also known as IOPS) that are necessary for verifying block chain data. This is not exclusive to Monero, but Monero transactions are slightly more complex than, say, Bitcoin, and so take more of those random read and wrote operations.
12:19:33 <sethsimmons> Remember that verifying a block or transaction can require pulling data from any previous transaction or block from genesis, so your sync requires your computer to find and validate that data multiple times per transaction you verify, and multiple transactions per block you verify.
12:20:17 <sethsimmons> Verifying 20 blocks could mean verifying 2000 transactions across the entire history of Monero, which each have 11 ring members to verify among other data.
12:21:09 <sethsimmons> Each of those verification steps is extremely costly on a hard drive which had to physically spin and seek across the platters for each of those ops, and could have to go to completely different physical locations on the disk for transactions in the same block.
12:21:50 <sethsimmons> On an SSD your computer merely requests the locations from the SSD controller and it quickly and easily returns the data with only electrical (not physical) movement.
12:24:55 <sethsimmons> Storing the blocks and transactions is trivial, which is why the portion before RingCT (and then before the latest checkpoint) is vastly quicker.
12:24:55 <sethsimmons> Verification became much more expensive when RingCT was introduced, but has gotten 90% more efficient over time since that point.
12:25:37 <sethsimmons> Verification is the portion that is very, very hard on traditional hard drives and older CPUs.
12:26:12 <sethsimmons> Hopefully that helps clarify some of what you're experiencing 🙂
12:48:53 <cankerwort[m]> I wonder if triptych 100+ ringsizes will cause the read/write bottleneck to become unscalable over time
12:49:14 <cankerwort[m]> Maybe something like ringsize ~40 is better for this reason, because increasing ringsize gives diminishing returns on plausible deniability anyway
12:52:54 <tokineko[m]> Multi-terabyte SSD is still expensive. That's why I dedicate a 6TB HDD to monero blockchain.
12:53:58 <cankerwort[m]> But the Monero block chain isn't even 100GB
12:56:38 <sech1> it is 100GB already
12:57:02 <sech1> well, it depends on how you count "GB"
12:57:31 <sech1> 97.5 proper GBs and 104 normie GBs
13:07:30 <tokineko[m]> In decades, it may need more than 6 terabytes.
13:09:40 <tokineko[m]> Do you expect to use another coin in decades? Maybe.
13:10:05 <cankerwort[m]> In decades, your HDD will probably be broken
13:11:53 <oceanus[m]> In decades we'll have petabyte drives
13:13:41 <cankerwort[m]> In decades, we'll be using Monero 3.0 with quantum resistant sharting
13:25:33 <tokineko[m]> Monero 3.0?
13:25:43 <tokineko[m]> I doubt that a petabyte drive is going to exist or be affordable in a few decades.
13:26:07 <tokineko[m]> What is `sharting`?
13:57:31 <sethsimmons> <cankerwort[m] "I wonder if triptych 100+ ringsi"> The big improvement with Triptych/Arcturus is that ring sizes scale *logarithmically* (no idea how to spell that lol) instead of *linearly*. So ~128 ring size is around the same verification time and size as current ring size 11.
13:58:05 <sethsimmons> It's a bit more complex than that and depends on the transaction itself, but that's a reasonable comparison.
13:58:15 <dEBRUYNE> <cankerwort[m]> Maybe something like ringsize ~40 is better for this reason, because increasing ringsize gives diminishing returns on plausible deniability anyway
13:58:24 <dEBRUYNE> I'd keep the verification performance similar and go off of that
13:58:32 <dEBRUYNE> So increase to a ring size that has similar verification performance as the current 'scheme'
13:58:49 <sethsimmons> Yeah, which IIRC is ~128
14:02:39 <tokineko[m]> It seems my btrfs mount options are not optimized for monero.
14:04:03 <tokineko[m]> https://www.reddit.com/r/Monero/comments/gbchd8/full_node_on_btrfs_vs_ext4/ says ext4 is faster than btrfs for synchronizing.
14:04:04 <monerobux> [REDDIT] Full node on btrfs vs ext4 (self.Monero) | 14 points (89.0%) | 11 comments | Posted by topseykrats | Created at 2020-05-01 - 05:41:24
14:05:13 <tokineko[m]> copy on write may decrease write performance of monero blockchain on HDD?
14:07:26 <sethsimmons> Wouldn't it decrease all write performance? You're asking the disks to perform extra operations for each real actual operation.
14:08:23 <sethsimmons> So you're taking an already slow medium (HDD) and slowing it down even further. Just get a 1TB SSD and call it a day for a decade or two
14:09:40 <tokineko[m]> I guess I may settle with ext4.
14:13:50 <tokineko[m]> According to https://www.reddit.com/r/Monero/comments/gbchd8/full_node_on_btrfs_vs_ext4/ , it is 15 times as fast to synchronize on ext4 than on btrfs.
14:13:51 <monerobux> [REDDIT] Full node on btrfs vs ext4 (self.Monero) | 13 points (88.0%) | 11 comments | Posted by topseykrats | Created at 2020-05-01 - 05:41:24
14:19:46 <tokineko[m]> http://www.lmdb.tech/bench/microbench/july/#sec11
14:20:42 <tokineko[m]> Is it possible to write lmdb on raw disk?
14:24:21 <sethsimmons> Lets take this to #monero:matrix.org
14:24:43 <tokineko[m]> Does anyone know file system and mount options best for blockchain synchronization on HDD?
16:17:29 <hautdryep> 'Oddly, no one who was directly involved with the SIR-C missions and currently still working the Lab, remembers the name Howard Chu, except for one who vaguely recalls Eugene Chu as having a brother names Howard'
16:17:29 <hautdryep> Ed Caro, NASA Chief Engineer. cryptogazette.com/wp-content/uploads/2019/12/1-768x1445.png
23:03:15 <sgp_[m]1> This channel is now relayed to the Monero Social Matrix server