474900+ entries in 1.751s

decimation: but if
the levels are high enough and you use some kind of clipping algorithm it wouldn't be an issue
decimation: I would worry about potential noise in
the sound card
decimation: asciilifeform: looks like one of
those ebay usb/3.3v serial dongles
ben_vulpes: twiddles kitchen lead
time for operators of
trinque's webmachine
decimation: ben_vulpes: I have one of
those usb knobs
assbot: Logged on 17-05-2015 00:08:31; jurov: i suspect
turning electrons in sharp curves needs a strong mag field -> high current
decimation: it occurs
to me
that one use of deedbot would be
timestamping potential evidence, like camera/video captures
decimation: asciilifeform: adlai interesting 'application specific'
tube logic links
mircea_popescu: web experts derp about how MP doesn't know shit.
then mp makes something
that owns anything
they've ever seen in penetration.
then
they don't knowtice, because one can't be stupid and perceptive at
the same
time.
mircea_popescu: "man, i hadnt seen an ad on
the interne in years.
thought it was a banner for awhile" << bwahahaha.
mircea_popescu:
http://v8chan.com/thread/3744246/what-is-this-ad.html << "As much I don't want
to bring in /pol/ into every discussion, /leftypol/ is a hundred
times worse. You're fucking cancer." / "its fags like you who make
these
threads
the worst" / "No, it's fags like you who get
triggered if anything remotely /pol/-like is mentioned, and I don't even like /pol/. Get
the fuck out." / "Youre mentally disabled if you dont
thi
ben_vulpes: how can one ever
tell with
these internet gifs
mircea_popescu: hey,
that looks like a bunch of dudes slapping
the shit out of some chick
mircea_popescu: and it is now
time for a review of
teh various butthurt!
jurov: was
that
the question?
jurov: ben_vulpes: it's source package
that portage downloads automatically(with some exceptions)
to /usr/portage/distfiles
jurov: i suspect
turning electrons in sharp curves needs a strong mag field -> high current
☟︎ assbot: Logged on 16-05-2015 22:45:49; asciilifeform: jurov: if going
to
tubes, one ought
to stop
thinking in
terms of gates and start considering how much computation can be carried out by one flying electron...
assbot: Logged on 16-05-2015 21:54:31; asciilifeform: (assembling
these into a circuit with 'weakest link' still permitting
these speeds, is 'an exercise for
the alert reader')
jurov: so you
think about one SHA2 iteration feeding itself?
jurov: ah
that. so,
thinking about ECL, one basically needs
to put
together 2x80 identical circuits for
two rouds of SHA1, and pipeline
them, no?
jurov: rly? last
time someone dig out "vacuum" microelectronics, you said academic wankery
jurov: heh had same
thought
jurov: pediwiki says "300 MHz flip-flop
toggle rates".. and guess it would need flipflops if
the SHA computaiton is pipelined
mod6: lol, it was hard not
to comment on
that
assbot: Logged on 16-05-2015 18:54:57; mod6: <+danielpbarron>
the node
to which i'm referring runs 0.7.2
though, so might not be
the same issue << as ascii said,
this is apples
to oranges, but I'm curious anyway; where abouts are you at in
the sync process on
this particular device? (what block height range? 250`000 - 290`000) ?
mod6: ok, it's in
that same directory: 'nmon_bitcoin-v0_5_3_1-RELEASE_plus_OrphanageThermonukePatch.txt'
mod6: im
throwing
that raw nmon file up
there for you now, incase you wanna see it.
mod6: ah, ok. i'll
try
to figure out how
to capture
that.
mod6: it should be /fairly/ accurate as
there isn't anything else running on
this box. just
the usual: sshd/syslog/screen/cron ..
mod6: yeah, i'll have
to figure out how
to use either nmon or another
tool
to capture /just/
the bitcoind process.
mod6: well, actually, i'd post
the orphanage-thermonuke patch
test data now, but it's 113 mb of raw nmon captures.
mod6: make sense? i'll post all
the data with a posting about
the findings.
mod6: Now, currently, I'm running a very similar
test with v0.5.3.1-RELEASE (as a baseline) without your OrphanageThermonuke patch included... it did oomkill once, yesterday.
mod6: so yes,
the first performance
test was me running v0.5.3.1-RELEASE with Orphanage_Thermonuke patched in. Performance
test conducted with `vmstat 1` & `nmon -f s3 -c1000000`. During
this
test
the entire sync process completed without any oomkill.
mod6: <+danielpbarron>
the node
to which i'm referring runs 0.7.2
though, so might not be
the same issue << as ascii said,
this is apples
to oranges, but I'm curious anyway; where abouts are you at in
the sync process on
this particular device? (what block height range? 250`000 - 290`000) ?
☟︎ mod6: now, it'll be interesting
to see
the numbers i.e. network usage (among other utilization metrics) between full sync of v0.5.3.1-RELEASE+{Orphanage_Thermonuke} & v0.5.3.1-RELEASE (currently running -- which also, as i was saying lastnight, already oom killed once)
mod6: <+asciilifeform> ;;later
tell mod6 so orphanage-thermonuke has never oom-crashed in your
tests ? << nope! it was pretty exciting
to see it get all
the way
through full sync without oomkill.
trinque: danielpbarron: I noticed deedbot's btcd node crashed
the other day
danielpbarron: i
thought maybe
the live network was getting spammed
the other day or something; why all of a sudden my node keeps crashing?