If you watch transactions as they hit the mempool (e.g. txstreet.com) , you'll notice that they tend to come in large batches, with several minutes elapsing in between batches. I've had scale.cash running and generating transactions during this interval, and noticed that the transactions I generate usually take several minutes before they're visible on block explores or on my local node's mempool. For example, this transaction was generated by my scale.cash webpage about 14 minutes earlier, but when I queried Bitcoin ABC, I see it's not there yet:
bch@feather:~$ abccli getrawtransaction b639cf06646a01a93f29cbc9b773755158bb712e2e5f3c10978f745e89341a39 error code: -5 error message: No such mempool transaction. ...
Ten minutes later, I tried again, and this time it's there:
bch@feather:~$ abccli getrawtransaction b639cf06646a01a93f29cbc9b773755158bb712e2e5f3c10978f745e89341a39 0200000001c0486ca96c7a8d4f5b1ea68f419ca2c76c1ec3d0613ed11746ead1b4d1addc64000000006a473044022009f68f4c84dd7d94758c49dffb6e4ae28bf74588475352803177cbbe0e0e765c022036f01d76c176a82c645987929cf73cc80d6a3b500f1a79321be4095564431b2141210340a65a40cb472752045abf1a5990d6d85a1d6f71da7dde40dd8b15c179961b1dffffffff02460b0000000000001976a9147a1402392a64f64894296d2528cf907e4b76432488ac0000000000000000186a1673747265737374657374626974636f696e2e6361736800000000
So something is bottlenecking transactions in between their generation in javascript in my web browser and the full node network.
This could just be an issue with scale.cash's webservers. We don't know anything about how those servers work.
But it could also be the AcceptToMemoryPool bottleneck. Perhaps what is happening is that a large batch of transactions comes in and fills a node's network buffers. Eventually, AcceptToMemoryPool() gets run, locks cs_main and cs_mempool, and runs through all of the transactions. The locking of cs_mempool prevents the networking threads from reading mempool and uploading the transactions to the next peer until this batch of transactions is finished processing. Once that happens, the networking code locks cs_mempool and prevents AcceptToMemoryPool from running, causing the socket reading code to fill its buffers while waiting for ATMP to run again. The process then repeats indefinitely, causing batched broadcasts of transactions instead of smooth trickles.
Note: I'm not 100% sure that this is how the ATMP code and locks work. I haven't read that section for a while. But it seems likely that the ATMP bottleneck could result in transaction batching. We're getting about 60 tx/sec average, so seems like we're getting close to the expected ATMP bottleneck level of 100 tx/sec average (20 MB/block) that was seen in the Gigablock Testnet Initiative. It's possible that their servers were more consistently powerful than what we have on mainnet, resulting in the ATMP bottleneck being lower.
[link] [comments]
source https://www.reddit.com/r/btc/comments/9c8tv2/either_atmp_or_scalecash_is_bottlenecking_the/
No comments:
Post a Comment