Logs for #trilema-mod6

Go to: #trilema #pizarro #trilema-mod6 #trilema-trinque #chainstate #eulora

This is the log of #trilema-mod6 : Contained within are the daily on-goings of The Bitcoin Foundation's (http://thebitcoin.foundation) Reference Implementation (trb) development. Do not, under any circumstances, use any code/vpatch/logic/configurations/ideas or otherwise found in this forum. In fact, you should NOT read this at all. Failure to heed these warnings may result in death or dismemberment! ALL ANNOUNCEMENTS, BUSINESS, AND/OR QUESTIONS INVOLVING THE BITCOIN FOUNDATION AND/OR THE BITCOIN REFERENCE IMPLEMENTATION (TRB) WILL TAKE PLACE IN #TRILEMA: YOU HAVE BEEN WARNED.

2017-11-30 | 2018-1-1

mod6: ah, nice :]
TomServo: Greetings, happy to report my node is _finally_ in sync, after ~6 months.
shinohai: :D
mod6: hey hey!
shinohai: Well done Tom Servo
shinohai: post best block hash here?
asciilifeform: TomServo: i also recently had a 6mo sync end.
mod6: Yeah, very cool. I'm like... by my calculations ... 10 days away still :/
mod6: im about 1000 blocks behind.
mod6: 500593
mod6: TomServo: Let me know if you wanna be added to the list of nodes.
mod6: fwiw, 'aggression' hasn't helped my sync speed yet. but i don't think the getting the blocks is the bottleneck on my end... its the write speed.
asciilifeform: lemme guess, mechanical hdd ?
mod6: im not 100% positive. but i believe so, yes.
asciilifeform: mod6: do you have the db timer patch ?
mod6: yah
asciilifeform: it'll answer for certain
asciilifeform: where is the time spent ?
mod6: lemme see here...
mod6: SetBestChain: new best=0000000000000000008a height=500594 work=253388668009823047175074377
mod6: AcceptBlock() success : 364406ms
mod6: ProcessBlock: ACCEPTED
mod6: ProcessBlock (res == 1) took : 364424ms; db write wait: 202849ms
mod6: Tested candidate block in 364427ms
mod6: ResendWalletTransactions()
mod6: Slow Write: : 4327ms
mod6: Slow Write: : 9969ms
mod6: Slow Write: : 1206ms
mod6: Slow Write: : 2955ms
mod6: Slow Write: : 12568ms
mod6: etc.
asciilifeform: yea this is a hdd just short of unusably slow
asciilifeform: this machine will , i suspect, regularly fall behind
mod6: yeah, it's right on the cusp by my calc. if i was in like the 400000ms range or beyond, then i'd be fucked
asciilifeform: they are not worth the headache of keeping around. asciilifeform uses 100% ssd nao.
asciilifeform: it is worth the extra pennies.
asciilifeform: just dunforget to swap'em out every 2-3y.
mod6: i think i have achieved the goal of this environment for the most part. i'll probably end up finding a different box with ssd and copying over the blocks.
asciilifeform: also worx.
mod6: i had so much fun playing with the ffacalc lastnight
asciilifeform: pehbot is live again btw.
mod6: i saw that, pretty cool.
asciilifeform: i like to see the various stabs/fumbles/etc in the log, for folx to read.
mod6: yah
mod6: after reading through the chapter, and the code posted, it wasn't too bad to figure out what was going on there.
mod6: took me a bit to get a hang of it.
asciilifeform: ideally this should be the case for every ch
asciilifeform: the principal difficulty has been to keep'em reasonably short
mod6: yeah, i can see it getting much harder very soon, in regards to that.
asciilifeform: easier, oddly enuff
asciilifeform: moar algo, less i/o-furniture
TomServo: http://p.bvulpes.com/pastes/53Gbx/?raw=true << sha512sum blk0070.dat
asciilifeform: but there, different headache, it is instead to explain the algos properly
asciilifeform: today's ch5 may very well get pushed to saturday, like last time
mod6: nice TomServo
TomServo: I didn't notice a different after applying 'aggression'.. but I think was already within 500 blocks and sync was slowing already.
mod6: ah. well, im certainly behind on a bunch of things around here ... but yeah, proper explanation of subject beats time to news-stand imho
TomServo: difference*
mod6: TomServo: cool. hopefully you'll stay sync'd up. remember to back up your chain too.
asciilifeform: TomServo: possibly you have same issue as mod6 -- uselessly slow disk makes for agonizingly slow sync, regardless of whether you have ample supply of peers-willing-to-send-next-block
TomServo: I had been trying to monitor.. best average was about 12 blocks per 15 minutes... and it started decreasing as I got closer to being in sync.
asciilifeform: mechanical disk is lethal for post-2015 spamola-filled blox -- it's ~10k ~random-access~ reads/writes per block
TomServo: This is 5 mech disks in a zfs pool.
asciilifeform: still not comparable to ssd.
TomServo: I didn't think so.
asciilifeform: and yes the closer you get to being in sync, the more http://btcbase.org/log/2017-12-28#1759729 effect.
asciilifeform: the closer you get to 'tip of spear', the more ti
asciilifeform: time yer node wastes shoveling mempoolade
TomServo: speaking of monitoring, anyone care to give me a beating regarding this: http://wotpaste.cascadianhacker.com/pastes/r8zyu/?raw=true
TomServo: no idea what i'm doing, basically
asciilifeform: notbad actually
asciilifeform: similar to what i had hand-cranked
TomServo: Well that is about the last thing I expected.
asciilifeform: lolwhy
mod6: cool TomServo
TomServo: didn't think any script I made would be called anything like 'similiar' to something out of the Big Brain on Stan.
asciilifeform: lol
asciilifeform: i'm not a perlist, and typically dun have any fancy scripting.
asciilifeform: believe or not.
mod6: trinque: care if i ask some super-dumb questions just to get my mind wrapped around all the things?
trinque: don't mind at all; I'll be around for about 30min more before off into the night
mod6: ah, ok.
mod6: sec.
mod6: so it seems like i just need to grab that entire development musl overlay and add that to the extracted cuntoo project?
mod6: i guess that's even a lowerlevel thing from where I really wanted to start.
mod6: i was thinking that i want to make sure I understand the whole thing conceptually.
trinque: the build will grab it for you in the WIP version
trinque: in that "layman" call
mod6: but that may take longer than 30 mins.
mod6: ahh, ok, i didn't even see that yet.
mod6: ah the 'chroot . layman -a musl' part?
trinque: properly, there's no "gentoo portage" and "musl overlay" to speak of; they'll be merged
trinque: yep, that's it
mod6: ah, ok.
trinque: removing the layman step will remove several deps.
mod6: stan was saying that he's going to host all of the src packages in his racked box...
mod6: will we evenaully point at that instead? or how does that fit into the picture?
mod6: well, doesn't matter for this moment anyway.
mod6: here's another qq...
mod6: in your install.sh we have some definitions for PORTAGE and STAGE3 ; are we to freeze one of these? or make our own?
trinque: those are the frozen ones, present in the distfiles dir.
trinque: hosting is a fine thing, gotta get the originals from somewhere, but the point of this installer is to not rely on the network *at all* once you have 'em.
mod6: ah. ok. nice
trinque: I'm going to flesh out that piece I posted with some additional rationale when I get a moment.
mod6: <+trinque> those are the frozen ones, present in the distfiles dir. << aha, ok.
mod6: forgive my dumb questions here... just wanna make sure i get the context of the thing here :]
trinque: nah not at all
trinque: just saying I have more description to do, chastizing myself.
mod6: this is great tho.
trinque: but note that I have the binary package building turned on; you could easily build on an airgap box, take binpkgs and use 'em wherever you like
mod6: *nod*
mod6: anyway, enjoy your evening. we'll pick this up later. thanks again.
trinque: that shall be a knob though; sometimes you want to produce packages you'll use on a box that wont have/need toolchain (embedded device maybe), other times, will take the time to rebuild wholly, why not
trinque: will do, thanks!
mod6: o7

2017-11-30 | 2018-1-1