22200+ entries in 0.046s
mod6: <+ascii_modem> nonono not leaks << ok i see, so with -mp in the MEM_LIVE output we're just seeing a live heap. not leaks as the other doc page said.
mod6 goes back to reading
mod6: haha. was just typing that out ^^
mod6: so the docs say, "MEM_LIVE records the ``live'' memory -- memory that hasn't been freed. If the profile statistics file you are processing came from the end
mod6: <+decimation> I see what ascii means about the flat graph (memory.png on the orphanage thermonuke) << ahh
mod6: and now, maybe learn the ropes on igprof.
mod6: in addition to the valgrind tests that ascii did earlier this month, i was going to dig into some of that myself in june.
mod6: yeah, im not sure. i need to read more there.
mod6: but as far as the nmon tests, I wanted to system level profile the entire sync process -- get some visuals, see what we're looking at as far as overall system usage, etc.
mod6: i was just getting started reading and got pulled away for a minute.
mod6: yeah, im not even sure what i'm looking at anymore with that igprof stuff yet.
mod6: is that directed at me with my perf tests? or at asciilifeform?
mod6: and yea, just for db.
mod6: ah, ok, couldn't remember the amt.
mod6: aight, me goes back to it.
mod6: 26'370'420 / 26'370'612 346'503 / 346'506 CBlock::AddToBlockIndex(unsigned int, unsigned int) [10]
mod6: 26'370'420 / 26'370'420 346'503 / 346'503 CBlock::AcceptBlock() [11]
mod6: decimation: i see now
mod6: asciilifeform: oh nm, 115500, didn't see that in the URL
mod6: asciilifeform: how long (how many blocks) was bitcoind sync'ing while you took this sample?
mod6: lolol that's horrendus. ProcessBlock leaked 26`847`114 bytes over 346`507 calls?!
☟︎ mod6: wait, these are not just bytes allocated during calls, these are LEAKED BYTES?!
mod6: have you looked at ThreadMessageHandler2 ?
mod6: asciilifeform: in the igprof_mem_live output, is the "Total" column in aggregate bytes - a sum of all bytes from the call's of said function?
mod6 reminds himself to setup that pogo
mod6: What's the memory cap that you wanna use on a pogo? 256Mb?
mod6: asciilifeform: full sync of bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation } underway
mod6: well, maybe after this sync is done with these 2 patches anyway. gotta still write this SoBA yet.
mod6: i'll work on building this tool here this weekend.
mod6: ok i'll come back to that, it's like a whole process to build that thing.
mod6: yeah, thats where i am, i just wasnt on the DL page, nm.
mod6: oh, just looking for a version of IgProf to grab... maybe im looking at the wrong thing.
mod6: do you reccommend "Scientific Linux 5" or "Scientific Linux 6"?
mod6: i've never used it. im guessing i can just compile/install via 3rd party package?
mod6: well, was going to launch this for a full sync test.
mod6: think I should stop and compile that in as well?
mod6: oh, darn. ok im compiling right now with : bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation }
mod6: I can't remember if we discussed that or not, outside of the context of your OrphanageBurner
mod6: yw. glad to hear the good news.
mod6: ben_vulpes: congrats!!
mod6: gabriel_laddel: also, it'll get discussed in the Monthly Address.
mod6: I should be able to get a box for this sometime after the 1st.
mod6: <+gabriel_laddel> mod6: Idk what exactly your goals are on your gentoo quest, but have you reached the conclusion that portage is insane and must go? << this project had to take a pause; I need to get some cash together to buy a physical box to put together steps for configuration on real hardware as opposed to aws or other cloud infrastructure. no, for now, I'm trying to stick with a Gentoo-amd64-uclibc-hardened. That's the goal anyway.
mod6: <+ascii_field> whole thing is, quite arguably, written 'in' boost rather than cpp proper << i saw some power-ranger derping in -dev about how it only use boost for "FOREACH" loops. was thinking "have you actually even read the code?!?"
mod6: my full sync's (non-pogo) with v0.5.3.1 are about the same 44-45Gb
mod6: ah, well, at first there was only 2 in Moduli Remaining, but that number has been climbing.
mod6: i should have waited on my key-retest. lol, got 119764 infront of it in the queue now.
mod6: with are preferred, ofc.
mod6: i only accept 2d powerpoints
mod6: alright, have the v0.5.3 Original nmon results up -- I'm moving all of these results in to a more organized dir structure.. (the originals will remain for now since it seems people are still looking at them); one can navigate all of these charts by release & by date tested here:
http://thebitcoin.foundation/test/perf/ mod6: <@assbot> Key 9974C0B2 / "Grubles <wdanny863@gmail.com>" successfully imported << apparently, only one 'b'.
mod6: Welcome to #b-a, you'll probably wanna get in the WoT if not alreday.
mod6: shinohai: yeah, you should be able to just pull down v0.5.3.1-RELEASE, extract the archive and all the details you need should be in the README.txt file.
mod6: shinohai: no, runs on mainnet
mod6: I still like them in channel, but if it must go because of "noise" i propose the construction of: log.trades.bitcoin-assets.com so people can follow the trades via
http if they wish.
mod6: they're two different people
mod6: <+kakobrekla> anyway, let me know if anyone else cares for trades being in this chan. << i like it, but maybe im just old school
mod6: jurov: ok added link to that under "Links". That ok with you?
mod6: asciilifeform: haha, yeha, mine is now queued with 5419 in front of it. haha, oh well. :]
mod6: think i'll just add a "links" section
mod6: ok cool. i'll add a link up there in just a bit.
mod6: heheh, redirect works fine with lynx, seems to not work well with FF.
☟︎ mod6: oh maybe i didn't wait long enough re redirect
mod6: nothing seems to come up at that link?
mod6: oh, now... no we don't have a link to that thing. what is it anyway, i can't recall.