24600+ entries in 0.048s
mod6: holy schnikies, it's still going: 134,865
mod6: ill give another update on it then.
mod6: @ block 1236XX i'll have to check back in on it in the am.
mod6: which is worth a look
mod6: so if the new block is not the genesis block, and the new blocks prev hash != best chain hash, run Reorganize
mod6: In later versions, they have a cap of 750 blocks max for the orphan map iirc.
mod6: Lastly, it recursively processes any orphan blocks that are depended on it, and deletes them from the map.
mod6: in v0.5.3, afaik, it looks for dups, then (with checkpoints) it checks to see if the block has a timestamp previous to the last checkpoint, then if it can't find a prev block it puts it in a holding area until one is found.
mod6: I don't have a good answer for that atm.
mod6: i'll hvae to take a look at your results.
mod6: i'll have to look back. i spent a bunch of time running gdb & valgrind earlier in the month.
mod6: mp: yeah, it definatly hits a slowdown from like 180k->270k
mod6: so, color me suprised
mod6: but, this is 10% of the memory i'm used to runing with
mod6: typically i see my first crash around 180k
mod6: basically; patches include so far, your patches, ben's rm UPNP & the bdb config update patches.
mod6: asciilifeform: irc stuff is still in there.
mod6: here's a script that will build everything without the rm_checkpoints patch, with exception to the version number update:
mod6: and so should you. I'll be tabling that, updating the "Patch guide" and pulling the tarball with that patch down from the website as soon as my other vm hits current block.
mod6: in my most recent regression tests ( this past week, i've been leaving out the rm_checkpoints patch )
mod6: cool. in this case, im running v0.5.3[base]+patches{1,rm_rf_upnp,2,3,4,6(db_config),unreleased-version-update-patch}
mod6: it would be neat-o to see this run on some sort of commercial router with a large flash-rom in there.
mod6: up to 68,xxx blocks....
mod6: ok running with 128mb ram
mod6: i'll put it on the list here...
mod6: awesome pics today :)
mod6: well, i could be wrong. i just saw a thing where they were telling some guy running a way forward version that he should add more swap or some such nonsense. but yeah... so it's been in there for a while.
mod6: yeah, i've read on place that they have this leakyness -- crashing problem all the way up to .9
mod6: a few days ago, I had been looking mapOrphanBlocks as a possible reason that it runs itself out of ram as this structure goes unchecked in size in v0.5.3 -- when I was at ~180,000 blocks, these are the stats that I had built up so far:
mod6: my aws vm has like 2gb of ram and it runs out between 24 - 48 hours
mod6: ive got a separate vm that has 1Gb of ram and it runs for about a 18-20 hours before it runs out of ram.
mod6: i've got a buddy running it on an aws micro with like 600Mb and it's working, but it runs itself out of ram like 1x per hour.
mod6 was on another tangent
mod6: well, i guess i can imagine.
mod6: every day is a great day! lol
mod6: now, there's a stress-free job. go around taking photos of those girls.
mod6: maybe they'll have lost your ban. win!
mod6: that hardware thingy looks like I should take a slapshot with it.
mod6: davout asked him to come here so he could 'chat' with mp
mod6: bailiff, bring the witness back to the witness stand
mod6: bitcoin in C is sexy
mod6: asciilifeform: werd
mod6: yeah, they're spenders, not savers.
mod6: yeah, there was a whole discussion surrounding this entire process. it's in the logs.
mod6: we wanted unified diffs we could sign
mod6: just need to change ``HOME'' to where you wanna build
mod6: but i'll publish it to the list with some refinements before the end of the month
mod6: i've got a script now...
mod6: it was selected because "reasons"
☟︎ mod6: i cant believe im going to do this
mod6: dude, that was published on the 1st of january.
mod6: there is not anything post v0.5.3 patched in at this point.
mod6: Well, that's what there is: the v0.5.3 base + patch files.