< iniana>
phantomcircuit, gmaxwell: Tried synching from scratch in a clean dir, but it is just as slow. I am wondering if it has something to do with the fact that I am running it in a Qubes AppVM. Funny thing is I was synching another (pruned) node from scratch in a whonix (tor-only) VM, and it went unexpectedly fast. Though that VM had the blockchain stored on an SSD.
< gmaxwell>
iniana: syncing from scratch with your dbcache increased?
< iniana>
gmaxwell: yes, lowered it from 4k to 2k when I realized I only had 4G of memory assigned to the VM
< iniana>
the tor VM had default dbcache
< gmaxwell>
with a dbcache of 2000 its unlikely that your slowness is related to disk io... but perhaps the vm is just doing something awful.
< iniana>
gmaxwell: yeah, will try the fedora-based VM instead of Debian and see if that makes a difference
< tbear>
If a bitcoin transaction is stuck from low payout fee like .0000012 how long should I wait before doing something plz? been 3 days thx
< tbear>
hi lowest payouts should be where transaction doesn't get stuck
< tbear>
If a bitcoin transaction is stuck from low payout fee like .0000012 how long should I wait before doing something plz? been 3 days thx
< instagibbs>
tbear, #bitcoin is a better venue for this question
< tbear>
thx nobody replied
< instagibbs>
well it's off-topic here sorry
< tbear>
lowest payouts should be where transaction doesn't get stuck
< GitHub3>
bitcoin/master 4d8993b Gregory Maxwell: Defer inserting into maprelay until just before relaying....
< GitHub3>
bitcoin/master 01d8359 Pieter Wuille: Merge #8082: Defer inserting into maprelay until just before relaying....
< GitHub19>
[bitcoin] sipa closed pull request #8082: Defer inserting into maprelay until just before relaying. (master...just_in_time_maprelay) https://github.com/bitcoin/bitcoin/pull/8082
< cfields_>
luke-jr: thanks, will take a look. Pretty sure I'm happy now though.
< sipa>
luke-jr: why are you excess flood'ing all the time? :)
< luke-jr>
sipa: TCP packet gets lost, waits for re-xmit, freenode reassembles that packet + the packets following it and decides it's too much "at once"
< luke-jr>
makes me wonder if I should just hack my router to send all TCP packets twice
< luke-jr>
looks like i have ~20% packet loss over IPv6 only at the moment :/