00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:30:08  * wolfeidaujoined
00:30:15  * karupaneruraquit (Excess Flood)
00:32:24  * loladirojoined
00:34:00  * karupanerurajoined
01:05:52  * wolfeidauquit (Remote host closed the connection)
01:06:29  * wolfeidaujoined
01:19:06  * jmar777quit (Remote host closed the connection)
01:19:44  * jmar777joined
01:24:26  * jmar777quit (Ping timeout: 256 seconds)
01:31:29  * AvianFlu_joined
01:32:08  * AvianFluquit (Ping timeout: 252 seconds)
01:32:12  * AvianFlu_changed nick to AvianFlu
01:38:14  * abraxasjoined
01:42:55  * benoitcquit (Excess Flood)
01:43:05  <isaacs>ircretary: tell trevnorris Looking into 0a9930a tls stuff now
01:43:05  <ircretary>isaacs: I'll be sure to tell trevnorris
01:43:09  <isaacs>indutny: ^
01:44:47  <isaacs>indutny: are you seeing that failure as well?
01:46:48  * wolfeidauquit (Remote host closed the connection)
01:52:40  * benoitcjoined
02:03:31  * mikealquit (Quit: Leaving.)
02:05:28  * wolfeidaujoined
02:17:29  * pooyaquit (Quit: pooya)
02:20:32  <isaacs>oh, ok, i see.
02:20:46  <isaacs>the issue is that we're asserting that we get a specific number of ECONNRESETs, but in fact, that is timing-dependent.
02:20:58  <isaacs>no wonder trevnorris's bisect produced screwey results.
02:35:16  * brsonquit (Quit: leaving)
02:41:24  <isaacs>test/simple/test-tls-pause.js is a bit more complicated..
02:41:51  <isaacs>that seems to work fine on osx, but is broken oddly on linux, and only in the latest v0.8 merge, it seems
02:42:42  * pooyajoined
02:49:43  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:51:44  <isaacs>oh, no, it's much older bug than that
02:51:59  * isaacs</3 sometimes-passing tests.
03:21:39  * stagas_joined
03:24:21  * stagasquit (Ping timeout: 276 seconds)
03:24:34  * stagas_changed nick to stagas
04:21:36  * qmxchanged nick to qmx|away
04:25:02  * stagas_joined
04:26:36  * abraxasquit (Remote host closed the connection)
04:27:06  * stagasquit (Ping timeout: 252 seconds)
04:27:13  * stagas_changed nick to stagas
04:37:22  * trevnorrisjoined
04:40:12  * abraxasjoined
04:50:43  <trevnorris>isaacs: sup dude?
05:04:06  * trevnorrisquit (Quit: Leaving)
05:08:13  * Raynosquit (Ping timeout: 246 seconds)
05:09:37  * wavded_quit (Ping timeout: 245 seconds)
05:09:37  * dscapequit (Ping timeout: 245 seconds)
05:17:17  * Raynosjoined
05:21:41  * kazuponjoined
05:45:31  * mikealjoined
05:46:03  * TheJHjoined
05:51:47  * trevnorrisjoined
05:55:07  * TheJHquit (Ping timeout: 240 seconds)
05:55:46  * loladiroquit (Quit: loladiro)
05:56:27  * kazuponquit (Remote host closed the connection)
05:58:47  * kazuponjoined
06:02:06  * mikealquit (Quit: Leaving.)
06:03:47  * mikealjoined
06:07:27  * loladirojoined
06:09:23  * benoitcquit (Excess Flood)
06:11:12  * benoitcjoined
06:31:42  * csaohjoined
06:34:11  * mikealquit (Quit: Leaving.)
06:35:26  * csaohquit (Client Quit)
06:39:09  * loladiroquit (Quit: loladiro)
06:41:29  * benoitcquit (Excess Flood)
06:41:33  * mikealjoined
06:49:03  * wolfeidauquit (Remote host closed the connection)
06:49:12  * benoitcjoined
07:07:01  * wavded_joined
07:07:24  * dscapejoined
07:08:41  * loladirojoined
07:11:48  <indutny>morning
08:05:28  * wolfeidaujoined
08:13:41  * pooyaquit (Quit: pooya)
08:23:53  * `3rdEdenjoined
08:30:16  * csaohjoined
08:30:52  * mmalecki[fly]changed nick to mmalecki
08:59:53  * rendarjoined
09:07:18  * wolfeidauquit (Remote host closed the connection)
09:27:53  * trevnorrisquit (Quit: Leaving)
09:30:28  * loladiroquit (Quit: loladiro)
09:35:32  * kazuponquit (Remote host closed the connection)
09:52:03  * stagas_joined
09:56:33  * loladirojoined
09:58:04  * stagas_quit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
10:02:10  * stagas_joined
10:03:59  * stagasquit (Ping timeout: 260 seconds)
10:04:05  * stagas_changed nick to stagas
10:12:24  * csaohquit (Remote host closed the connection)
10:14:53  * stagas_joined
10:16:54  * stagasquit (Ping timeout: 252 seconds)
10:17:03  * stagas_changed nick to stagas
10:18:20  * hzjoined
10:22:29  <MI61>joyent/node: isaacs master * a77c29a : test: Fix tls tests which fail sporadically The count of ECONNRESETs is - http://git.io/wERD4A
10:32:47  * benoitcquit (Excess Flood)
10:41:46  * benoitcjoined
10:46:03  * kazuponjoined
10:50:56  * kazuponquit (Ping timeout: 255 seconds)
11:04:36  * AvianFluquit (Remote host closed the connection)
11:06:03  * loladiroquit (Quit: loladiro)
11:46:56  * benoitcquit (Excess Flood)
11:50:17  * benoitcjoined
12:07:59  * hzquit
12:40:54  * Raltquit (Ping timeout: 264 seconds)
12:42:02  * benoitcquit (Excess Flood)
12:44:46  * benoitcjoined
13:03:30  * abraxasquit (Remote host closed the connection)
13:05:55  * benoitcquit (Excess Flood)
13:06:16  * benoitcjoined
13:11:19  * qmx|awaychanged nick to qmx
13:18:43  * hzjoined
13:30:36  * stagas_joined
13:32:30  * stagasquit (Ping timeout: 264 seconds)
13:32:32  * stagas_changed nick to stagas
13:34:21  * Raltjoined
13:41:21  * stagas_joined
13:41:51  * stagasquit (Ping timeout: 252 seconds)
13:41:52  * stagas_changed nick to stagas
13:44:06  * stagas_joined
13:44:32  * jmar777joined
13:46:16  * stagasquit (Ping timeout: 245 seconds)
13:46:16  * stagas_changed nick to stagas
13:54:02  * stagas_joined
13:54:28  * hzquit
13:56:23  * stagasquit (Ping timeout: 260 seconds)
13:56:26  * piscisaureus_joined
13:56:28  * stagas_changed nick to stagas
13:59:47  * stagas_joined
14:02:30  * stagasquit (Ping timeout: 264 seconds)
14:02:42  * stagas_changed nick to stagas
14:29:00  * benoitcquit (Excess Flood)
14:32:46  * benoitcjoined
14:36:42  * c4milojoined
14:37:17  * stagas_joined
14:38:29  * benoitcquit (Excess Flood)
14:38:57  * stagasquit (Ping timeout: 248 seconds)
14:39:47  * benoitcjoined
14:40:10  * loladirojoined
14:41:44  * stagas_quit (Ping timeout: 244 seconds)
14:42:41  * TheJHjoined
15:03:21  <isaacs>indutny: good morning
15:03:31  <isaacs>indutny: any idea why tls isn't draining properly on linux?
15:05:36  <indutny>morning
15:05:40  <indutny>no ideas so far
15:05:43  <indutny>going to look into it soon
15:05:44  <indutny>but
15:05:48  <indutny>I'm confirming it :)
15:05:55  <indutny>and its pretty odd
15:06:22  * loladiroquit (Quit: loladiro)
15:09:13  <isaacs>indutny: one thing that occurred to me as i was pouring coffee is that maybe the underlying socket isn't emitting drain sometimes
15:09:23  <isaacs>or emitting it when we're not listening
15:09:56  <isaacs>there's this thing: socket.on('drain', function() {
15:09:56  <isaacs> pair.encrypted.read(0);
15:09:56  <isaacs> pair.cleartext.read(0);
15:09:56  <isaacs> });
15:10:03  <isaacs>i think maybe that's not properly kicking the data out
15:11:19  <indutny>hm...
15:11:23  <indutny>interesting
15:18:43  <isaacs>indutny: here are the states when it locks up: https://gist.github.com/4986783
15:18:53  <isaacs>indutny: sock = tcp socket (on server)
15:19:01  <isaacs>enc = pair.encrypted, clr = pair.cleartext
15:20:23  * benoitcquit (Excess Flood)
15:21:47  * benoitcjoined
15:22:19  <isaacs>indutny: it looks like the encrypted side thinks its writing still, but the data has shown up in the cleartext readable side already
15:23:11  <isaacs>this line also makes the test continue: https://gist.github.com/4986783
15:23:27  <isaacs>er, this line: socket.pair.cleartext.write(socket.pair.cleartext.read());
15:23:31  * isaacscopypaste fail
15:27:16  <indutny>heh
15:27:35  <indutny>ok, I need to visit groceries
15:27:39  <indutny>and then I'll return to you
15:27:43  <indutny>brb
15:29:30  * bradleymeckjoined
15:38:29  <isaacs>ok
15:39:07  * mikealquit (Quit: Leaving.)
16:04:12  * `3rdEdenchanged nick to `3E|AFK
16:04:32  <isaacs>indutny: aha! there are cases where we're calling read(0) on both parts of the pairs, but NOT calling _writePending, so the pending stuff just sits there waiting forever.
16:05:27  <indutny>back
16:05:34  <indutny>aha
16:05:39  <indutny>cool that we caught it early
16:05:41  <indutny>:)
16:06:21  * mikealjoined
16:08:30  <isaacs>indutny: https://github.com/isaacs/node/commit/8304625c15a59b8ea6236e08461a37c56f8320ee
16:08:42  <isaacs>oh, i guess that's on a branch that was already landed. silly me.
16:08:46  <isaacs>should open new PR, i suppose
16:08:56  <isaacs>but if it looks good to you, we can just land on master.
16:09:12  <isaacs>running tests now to make sure it's non-harmful
16:09:16  <indutny>lgtm
16:09:25  <indutny>I'll land it
16:09:42  <indutny>but let me run tests first
16:09:43  <indutny>and also
16:09:46  <indutny>ah nvm
16:09:49  <indutny>we have regression test
16:09:54  <indutny>it just doesn't always work
16:10:24  <isaacs>yeah
16:10:30  <indutny>running tests
16:11:24  <isaacs>ohh... shoot. found a bug in that "tls tests that fail sporadically" fix.
16:11:26  <isaacs>undefined reference.
16:11:27  <isaacs>oops
16:11:54  <isaacs>and this makes test/simple/test-tls-session-cache.js timeout
16:12:40  <indutny>aha
16:12:50  <isaacs>weird.
16:12:51  <isaacs>ok
16:12:59  <isaacs>i've gotta head into the office.
16:13:09  <isaacs>tjfontaine: poke
16:13:19  <indutny>before you'll be away
16:13:20  <isaacs>but we can tls some more later :)
16:13:24  <isaacs>ok
16:13:25  <indutny>haha :)
16:13:25  <indutny>yes
16:13:35  <indutny>isaacs: so I wanted to ask you one thing
16:13:39  <isaacs>k
16:13:41  <indutny>do you think we should upgrade openssl in node 0.8
16:13:46  <indutny>I mean
16:13:47  <isaacs>um... probably not
16:13:48  <indutny>I don't care much
16:13:53  <isaacs>in master, sure, go crazy
16:13:53  <indutny>:)
16:13:56  <indutny>yes
16:13:57  <indutny>ok
16:14:01  <indutny>thanks for greenlight
16:14:07  <isaacs>but that guy's patch doesn't land on master nicely
16:14:11  <indutny>considering that its hard to review
16:14:12  <isaacs>so it probably has to be fixed up a bit
16:14:15  <indutny>I'll just push it
16:14:22  <indutny>once everything will be working
16:14:28  <isaacs>on v0.8, no, don't upgrade any deps at this point.
16:14:35  <isaacs>except npm
16:14:37  <isaacs>:)
16:14:41  <indutny>yes, I'm pretty sure we can introduce more bugs
16:14:43  <indutny>by doing this
16:14:52  <indutny>btw
16:15:03  <indutny>test-http-full-response fails miserably on osx
16:15:08  <indutny>can we disable it?
16:15:16  <indutny>or make it platform-specifc
16:15:28  <indutny>(it fails because of borked `ab` in osx)
16:18:03  <isaacs>orly? we should just land benchmark-refactor-2, and use tools/wrk instead
16:18:10  <isaacs>since it runs on all unixes now, thanks to bnoordhuis
16:18:17  <indutny>yep
16:18:22  <indutny>huh?
16:18:27  <indutny>he implemented that select() thing?
16:18:41  <isaacs>i think he pulled in the eventports stuff from new redis.
16:18:50  * benoitcquit (Excess Flood)
16:19:35  <indutny>https://github.com/wg/wrk/commits/master ?
16:19:36  <indutny>where is it?
16:20:32  <indutny>ah, I see it in your branch
16:20:39  <indutny>https://github.com/isaacs/wrk/commit/b96e03c467870d2d27e7b2fa2753de1cb452c7c8
16:20:48  * benoitcjoined
16:22:00  * bradleymeckquit (Quit: bradleymeck)
16:23:02  * bradleymeckjoined
16:23:45  <isaacs>ok, heading out, bbiab
16:25:19  <isaacs>indutny: also, simple/test-net-connect-timeout should probably be in test/internet
16:25:30  <isaacs>since it fails with ENETUNREACH like eery damn time on linux
16:26:24  <indutny>heh
16:26:26  <indutny>ttyl
16:31:38  * mikealquit (Quit: Leaving.)
16:46:39  * jmar777quit (Remote host closed the connection)
16:47:14  * jmar777joined
16:47:24  * jmar777quit (Read error: Connection reset by peer)
16:47:36  * pooyajoined
16:47:56  * jmar777joined
16:56:02  * rendar_joined
16:56:14  * mikealjoined
16:56:31  * rendarquit (Ping timeout: 260 seconds)
16:57:18  * piscisaureus_quit (Ping timeout: 272 seconds)
17:00:19  * dapjoined
17:09:40  * brsonjoined
17:21:46  * mikealquit (Quit: Leaving.)
17:25:56  * TooTallNatejoined
17:27:47  * bradleymeckquit (Quit: bradleymeck)
17:30:28  * qmxchanged nick to qmx|lunch
17:34:48  * AvianFlujoined
17:37:22  * pooyaquit (Quit: pooya)
17:44:49  * piscisaureus_joined
17:46:07  <tjfontaine>isaacs: re-poke
17:51:27  * jmar777quit (Remote host closed the connection)
17:52:05  * jmar777joined
17:54:01  * perezdjoined
17:54:05  * jmar777quit (Read error: Connection reset by peer)
17:54:18  * jmar777joined
17:55:47  * TheJHquit (Ping timeout: 260 seconds)
17:58:10  * pooyajoined
18:02:37  * mikealjoined
18:03:50  * bnoordhuisjoined
18:04:47  * brsonquit (Ping timeout: 244 seconds)
18:06:05  * brsonjoined
18:24:01  * qmx|lunchchanged nick to qmx
18:32:59  <isaacs>indutny: back from groceries?
18:37:28  * CAPSLOCKBOTquit (Ping timeout: 256 seconds)
18:38:32  * indexzerojoined
18:39:11  <indutny>yes
18:39:29  <indutny>isaacs: so it seems like tests are failing after your commit
18:39:43  <isaacs>indutny: which commit?
18:39:49  <indutny>isaacs: tls.cycle
18:39:53  <isaacs>i have a lot of comits in node, many of them make tests fail
18:39:55  <isaacs>oh, right
18:39:57  <isaacs>yeah, it's not so great.
18:40:03  <isaacs>makes some stuf break
18:40:09  <indutny>:)
18:40:10  <isaacs>needs something more surgical, perhaps.
18:40:15  <indutny>I wonder why
18:40:28  <isaacs>for sure, i think when the socket ends, you need to write anything pending
18:40:31  <isaacs>er, when the socket drains
18:40:43  <isaacs>perhaps before doing read(0)
18:40:46  <isaacs>not after
18:41:27  * trevnorrisjoined
18:41:50  * bradleymeckjoined
18:42:35  * bradleymeckquit (Client Quit)
18:45:52  * joshthecoder_changed nick to joshthecoder
18:47:34  * Benviejoined
18:47:59  * qmxchanged nick to qmx|lunch|for|re
18:48:04  * qmx|lunch|for|rechanged nick to qmx|lunch
18:49:00  * pooyaquit (Quit: pooya)
18:51:45  * bnoordhuisquit (Ping timeout: 248 seconds)
18:54:30  * bradleymeckjoined
18:55:55  * bradleymeckquit (Client Quit)
18:56:03  * `3E|AFKchanged nick to `3rdEden
19:04:29  <trevnorris>isaacs: so that tls issue looks like it's been fun for you.
19:05:30  <trevnorris>isaacs: forgot if I mentioned it somewhere else, but currently on master test-http-get-pipeline-problem is failing with Abort (core dumped).
19:05:38  <trevnorris>is that related to a fix you're working on?
19:05:54  <tjfontaine>trevnorris: what does the core dump backtrace say?
19:06:20  <tjfontaine>gdb $(which node) core
19:06:32  <tjfontaine>and then `bt` or `bt full`
19:09:28  <trevnorris>tjfontaine: no idea what i'm looking at: https://gist.github.com/trevnorris/4988870
19:09:59  <tjfontaine>well Core was generated by `VidyoDesktop'. that doesn't seem right
19:10:15  <trevnorris>yeah. that's a program I have on my machine, but it's not running.
19:10:45  <tjfontaine>right, we want to make sure the binary you passed to gdb is right, and the core file is really the core that node generated
19:11:07  <tjfontaine>you might need to retry with `ulimit -c unlimited` incase the core wasn't actually written to disk
19:11:18  * brsonquit (Quit: leaving)
19:11:31  * brsonjoined
19:11:37  <tjfontaine>it's gdb /path/to/node/binary /path/to/core/file
19:11:49  <isaacs>trevnorris: i'm not seeing that core dump at all.
19:11:54  <isaacs>trevnorris: not on linux, smartos, or osx
19:12:08  <trevnorris>isaacs: it only happens to me ~1/3 times.
19:12:20  <trevnorris>where do those core dump files go?
19:13:16  <tjfontaine>depends, generally it's CWD but it could be beside the actual binary
19:13:38  <isaacs>trevnorris: this just worked for me: for i in `seq 10`; do ./node test/simple/test-http-get-pipeline-problem.js || break; done
19:13:48  <trevnorris>ugh. wtf
19:19:47  <trevnorris>tjfontaine: ah, got it: https://gist.github.com/trevnorris/4988870
19:19:50  <trevnorris>isaacs: ^
19:20:33  <tjfontaine>that's an interesting place to abort
19:20:49  <trevnorris>tjfontaine: it never aborts in the same spot.
19:21:00  <tjfontaine>what other spots?
19:21:03  <trevnorris>it's just a random location during script execution.
19:21:34  <trevnorris>ok, what I mean is that the test outputs a lot of lines, and it will abort during any one of those.
19:21:51  <tjfontaine>ok, but if it's always core dump'ing it's interesting to know if the stack is always the same
19:22:09  <trevnorris>tjfontaine: ok. i'll generate a few more. on sec.
19:22:45  <tjfontaine>also, it would be interesting to see the backtracks if you use a debug build
19:23:28  <isaacs>indutny: so, this fixes the failure, witout introducing more failures: https://gist.github.com/4988981
19:25:25  <trevnorris>tjfontaine: ok, so it looks like the stack is always the same: https://gist.github.com/trevnorris/4988870
19:25:29  <trevnorris>i'll do the debug build.
19:25:40  <indutny>isaacs: shit came real
19:25:54  <indutny>sorry, right now I'm filling declaration of my income for '12
19:25:59  <indutny>damn hard thing
19:26:01  <isaacs>indutny: yeah.
19:26:18  <isaacs>i'd be so happy if the IRS could set up a "we'll bill you automatically" type of thing.
19:26:24  <indutny>ahhaha
19:26:26  <isaacs>i don't mind paying my dues to the society.
19:26:26  <indutny>yes
19:26:27  <indutny>actually
19:26:29  <isaacs>i just hate working as a fucking biller.
19:26:33  <isaacs>jesus, it's so tedious.
19:26:34  <indutny>I would like to just pay money
19:26:42  <isaacs>like, even *raise* taxes ifyou have to!
19:26:45  <tjfontaine>trevnorris: have you looked to see what that line is?
19:26:47  <isaacs>just make me not have to deal with it!
19:27:25  <tjfontaine>trevnorris: https://github.com/joyent/node/blob/master/deps/uv/src/unix/linux/linux-core.c#L224
19:29:57  <trevnorris>tjfontaine: i'm not shitting you, just ran the test w/ the debug build 20 times. never failed.
19:30:11  <tjfontaine>trevnorris: ya I'm not surprised that it might be timing related in this context
19:30:55  <tjfontaine>trevnorris: what it seems like is we're trying to epoll() on a fd that is no longer valid, so it's racey to be sure
19:31:39  <tjfontaine>well I guess delete it, and it was already deleted
19:32:50  <trevnorris>tjfontaine: hm. so it's an issue w/ libuv?
19:33:34  <tjfontaine>difficult to say, in the gdb shell, `p errno`
19:35:40  <trevnorris>tjfontaine: "$1 = 1"
19:36:11  <tjfontaine>EPERM The target file fd does not support epoll.
19:37:59  <tjfontaine>assuming no thread issues
19:39:54  <trevnorris>tjfontaine: ok. anything else I can look at?
19:40:26  * `3rdEdenquit (Quit: brb due to reasons)
19:40:29  <tjfontaine>trevnorris: well we want to try and find out which fd it was looking at, and see if that was/is a valid fd or if it was corrupted
19:40:45  <tjfontaine>trevnorris: it's a little harder considering you can't reproduce with a debug build
19:43:07  * qmx|lunchchanged nick to qmx
19:44:54  <isaacs>indutny: can you take a moment from your busy accounting duties to review this? https://github.com/isaacs/node/compare/tls-MOAR-FIXES
19:45:05  <isaacs>indutny: passing tests on linux and darwin. runinng on smartos now
19:45:15  <indutny>lgtm
19:46:03  <isaacs>kewl.
19:46:11  <isaacs>once smartos agrees, i shall land, and then begin 0.9.10
19:46:19  <isaacs>trevnorris: we should chat today about benchmarks
19:46:27  <trevnorris>isaacs: sounds good.
19:46:35  <isaacs>trevnorris: i'm eager to learn what you found out in your stastical stuff
19:47:50  <trevnorris>tjfontaine: i've narrowed it down to happening during "var s = fs.createWriteStream(common.tmpDir + '/' + x + '.jpg');"
19:48:08  * `3rdEdenjoined
19:48:38  <trevnorris>isaacs: sounds great. just let me know when works for you.
19:51:56  <isaacs>trevnorris: would it be better to do a skype or something, or is it low bandwidth enough to do via text?
19:52:40  <isaacs>trevnorris: i'd like to get benchmark-refactor-2 landed, and then get tjfontaine started wiring up joyent's jenkins stuff so that we can have something tracking each commit/etc.
19:52:47  <isaacs>but key to all that is getting benchmarks that aren't completely insane.
19:53:33  <isaacs>alright, tls tests should be passing now.
19:53:36  <MI61>joyent/node: isaacs master * 60238cc : tls: Write pending data on socket drain Fixes #4800 (+1 more commits) - http://git.io/5JrJNg
19:56:51  <trevnorris>isaacs: text should be fine.
19:57:12  * benoitcquit (Excess Flood)
19:58:26  * bnoordhuisjoined
19:59:29  <isaacs>trevnorris: kewl, i just cancelled my 1:00, so after lunch?
19:59:41  <isaacs>trevnorris: seeing as how the lunch alarm is about to sound here in SF
19:59:53  <trevnorris>isaacs: yeah. sounds good
19:59:59  <trevnorris>lol, gotta love fire drills.
20:02:02  <isaacs>trevnorris: we do actually have a lunch alarm here in SF on tuesdays: https://twitter.com/rioter/status/303956023209771008
20:02:16  <isaacs>er, this one: https://twitter.com/sfsiren/status/303957137955123200
20:02:19  * benoitcjoined
20:02:21  <isaacs>rioter is someone else :)
20:02:35  <isaacs>the twitter.app's "copy link to tweet" is non-deterministic
20:02:45  <tjfontaine>heh
20:02:57  <trevnorris>wait. you mean all sf has one every tuesday?
20:03:21  <tjfontaine>I presume it's a test of the system, it just so happens to help identify lunch :)
20:03:22  <isaacs>it's a giant outdoor alarm that sounds every tuesday at noon
20:03:41  <isaacs>it says "This is a test. This is a test of the emergency outdoor warning system."
20:03:44  <isaacs>then it says something in Chinese
20:04:00  <tjfontaine>isaacs: it would be helpful to learn your future language
20:04:03  * TheJHjoined
20:05:14  <CoverSlide>you can't take the sky from me
20:05:46  <bnoordhuis>evening everyone
20:05:51  <bnoordhuis>how are we for v0.10?
20:06:29  <isaacs>bnoordhuis: closing the gap, slowly but surely
20:06:32  <isaacs>v0.9.10 today
20:06:47  <isaacs>bnoordhuis: lunchtime right now. bbiab
20:06:48  * isaacs&
20:06:49  <LOUDBOT>WAIT WHY DID THE BOT IGNORE ME?
20:25:58  * dap1joined
20:25:59  * dapquit (Read error: Connection reset by peer)
20:29:19  * bsnotejoined
20:33:29  <bsnote>Hi there
20:34:13  <bsnote>Can anyone help me? http://stackoverflow.com/questions/14962022/gcc-exact-location-of-type-declaration/14962364#14962364
20:35:54  * bradleymeckjoined
20:42:17  * mikealquit (Quit: Leaving.)
20:43:55  <indutny>huh?
20:44:22  <indutny>are we stackoverflow?
20:52:10  <bsnote>yes :)
20:52:16  <bsnote>if you want :)
20:53:02  <bsnote>actually nevermind, I think I have a clue
20:56:43  <bnoordhuis>was it the butler with a chandelier in the library?
20:59:21  <indutny>bnoordhuis: chaga-chaga
20:59:23  <indutny>hello
20:59:32  <indutny>how is SF?
21:00:12  * isaacsfg
21:02:18  <trevnorris>bnoordhuis: hey man. maybe you can help me with what I think is a strange race condition in test-http-get-pipeline-problem: https://gist.github.com/trevnorris/4988870
21:02:34  <trevnorris>(well, tjfontaine is the reason I know any of this)
21:02:55  <tjfontaine>I don't trust that tjfontaine guy
21:06:56  <trevnorris>tjfontaine: so i think it's happening when creating the write stream, but feeling around in the dark from there.
21:07:07  <trevnorris>isaacs: here or pm for bench stuff?
21:07:24  <isaacs>oh, here's fine
21:07:27  <isaacs>logs ftw :)
21:07:47  <trevnorris>isaacs: first take a glance: https://gist.github.com/trevnorris/4989440
21:09:32  <bnoordhuis>indutny: hey. i'm already back again
21:10:05  <bnoordhuis>trevnorris: what's the issue? (i'm looking at the gist)
21:10:22  <tjfontaine>trevnorris: I'm not quite sure of the flow that would mean creation of a write stream would remove an fd
21:10:27  <trevnorris>bnoordhuis: at random times it "Abort (core dump)"
21:11:12  <trevnorris>bnoordhuis: the gist shows three different occurrences to show that the call stack is the same.
21:11:38  <tjfontaine>bnoordhuis: it appears to be epoll_ctl on an fd that isn't supported by epoll
21:11:49  <tjfontaine>deleting anyway
21:12:12  <tjfontaine>but he wasn't able to reproduce with a debug build so it could be stepped through
21:12:31  * mikealjoined
21:12:36  <trevnorris>tjfontaine: thanks =)
21:13:20  <bnoordhuis>tjfontaine: ah, okay. any idea what the errno was?
21:13:23  <tjfontaine>heh, it's possible that our inspection of errno isn't entirely accurate, but it's errno was 1
21:13:44  <bnoordhuis>EPERM?
21:13:55  <tjfontaine>yes that's what I interpreted it as
21:14:08  * loladirojoined
21:14:47  <bnoordhuis>you don't happen to know what kind of fd it was?
21:14:59  <tjfontaine>I don't know, we didn't get that far in inspection
21:17:09  * mikealquit (Ping timeout: 276 seconds)
21:17:17  <bnoordhuis>okay. is the kernel version known?
21:17:29  <trevnorris>3.5.0-19
21:17:37  <tjfontaine>I knew it was 3.5~ish
21:18:02  <bnoordhuis>hm, okay
21:18:31  <bnoordhuis>one guy reported that he sometimes had trouble with unix sockets (i believe) with some recent-but-not-quite kernels
21:18:53  <bnoordhuis>may have been some kind of kernel regression because i haven't seen it with 3.7 or 3.8
21:19:15  <bnoordhuis>that reminds me...
21:19:18  <bnoordhuis>dap1: ping
21:19:23  <tjfontaine>I haven't tried on any of my linux installs yet, but isaacs said he wasn't able to reproduce
21:19:31  <trevnorris>bnoordhuis: does is matter that i can step back in time and find a commit where it began?
21:19:55  <bnoordhuis>trevnorris: you mean it doesn't happen with older versions but reliably with newer ones?
21:20:08  <trevnorris>bnoordhuis: yeah. let me bisect again real quick and get the commit for you.
21:23:54  <trevnorris>isaacs: while i'm waiting. the table is variants of the most important tests.
21:24:29  * sblomjoined
21:25:41  <isaacs>trevnorris: kewl
21:25:49  <isaacs>trevnorris: i'm showing off the node build process to tjfontaine
21:25:56  <isaacs>all part of my master plan to automate my entire job.
21:26:32  <trevnorris>hey, full automation is rockin.
21:26:32  <MI61>joyent/node: isaacs created branch v0.9.10-release - http://git.io/5mC7ZA
21:28:25  <trevnorris>and curse mraleph. that irhydra thing is sucking away my time.
21:31:06  <trevnorris>bnoordhuis: 8476ae causes the problem, and when I revert it on latest master don't get the issue.
21:33:29  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:33:45  <trevnorris>isaacs: the "% diff" column helps see how volatile the test is. for some reason cluster is insane.
21:34:00  <trevnorris>isaacs: and comparing similar tests helps us see how unstable they are. fs is very much that way.
21:35:52  <isaacs>trevnorris: where's that gist again? the chart?
21:36:00  <trevnorris>isaacs: https://gist.github.com/trevnorris/4989440
21:36:10  * jmar777quit (Remote host closed the connection)
21:36:48  * jmar777joined
21:36:50  <isaacs>trevnorris: yeah, culster is crazy
21:38:02  <trevnorris>isaacs: and for fs, even if the regression isn't going to linear, it should at least be uniform.
21:38:21  <trevnorris>notice that "fs-write-utf-4096-5" has the highest stdev, and "fs-write-utf-65535-5" has the lowest.
21:38:28  <isaacs>yeah
21:38:30  <isaacs>that's just luck
21:38:37  <isaacs>there's no other way to view that
21:38:48  <trevnorris>how do you mean, luck?
21:39:06  <bnoordhuis>trevnorris: wut? 8476ae
21:39:30  <trevnorris>bnoordhuis: that commit is causing the abort. if I revert it then the issue goes away.
21:39:47  * mikealjoined
21:40:22  <isaacs>trevnorris: i mean, i'd chalk that up to "the fs got busy or something"
21:40:30  <isaacs>trevnorris: what machine were these running on?
21:40:55  <trevnorris>isaacs: that's 49 runs of the same test in linear order on my machine, with all extranious services disabled and running headless.
21:41:04  <isaacs>k
21:41:13  <isaacs>do you have the test script somewhere handy?
21:41:21  <isaacs>once this build is done, we can run it on our build boxes.
21:41:24  <isaacs>see if there's any change.
21:41:30  * jmar777quit (Ping timeout: 264 seconds)
21:41:58  <bnoordhuis>trevnorris: can you check something for me?
21:42:30  <trevnorris>isaacs: just posted it to gist, but don't mock me please. ;)
21:42:37  <trevnorris>bnoordhuis: sure, anything to stop this from failing.
21:42:52  <isaacs>haha, no worries
21:42:54  <isaacs>if it runs, then that's great.
21:43:14  <bnoordhuis>trevnorris: run the test in gdb. when it hits the assert, check what fd is triggering it (`p fd`) and what kind of fd it is (`ls -l /proc/<pid>/fd/`)
21:43:19  <trevnorris>isaacs: it actually generates a .js file that uses a stats lib I have to generate the statistics.
21:43:28  <indutny>bnoordhuis: so I was thinking about thunder-effect
21:43:32  <indutny>of epoll/kqueue
21:43:42  <indutny>I don't think there's a real way to fix it in libuv
21:43:46  <indutny>but we can improve it in kernel
21:43:55  <indutny>though, I'm not sure about APIs that we should propose
21:44:12  <bnoordhuis>indutny: i'm reasonably sure linux somewhat "fixes" this
21:44:24  <bnoordhuis>by not reporting the event to all threads right away
21:46:31  <indutny>impossible
21:46:53  <trevnorris>bnoordhuis: ok. i've never actually used gdb before today so might take me a few... or more... to figure this out.
21:47:02  <bnoordhuis>trevnorris: i'll walk you through it
21:47:13  <trevnorris>thanks much
21:47:13  <bnoordhuis>gdb --start out/Release/node script.js
21:47:17  <bnoordhuis>r (for run)
21:47:21  <bnoordhuis>wait for the assert to trigger
21:47:24  <bnoordhuis>bt
21:47:34  <bnoordhuis>pick the uv__io_poll stack frame with `f <n>`
21:47:56  <bnoordhuis>then `l` (for list) will print the code around the abort() call site
21:48:26  <bnoordhuis>`p fd` should print the fileno, provided it's not optimized away
21:48:29  * qmxchanged nick to qmx|away
21:48:44  <bnoordhuis>but in that case you can still get it with `p pe->data`
21:48:54  <trevnorris>bnoordhuis: um... gdb doesn't recognize --start, using 7.5.
21:49:00  <bnoordhuis>ah sorry
21:49:01  <bnoordhuis>--args
21:49:16  <bnoordhuis>i was typing some code just now that had the word 'start' in it :)
21:50:20  <trevnorris>hey, no worries. thanks for saving me a lot of time finding all this stuff on my own.
21:54:26  <trevnorris>bnoordhuis: http://git.io/wzDB7w
21:55:47  <trevnorris>slightly more cleaned up version: http://git.io/_ugHpQ
21:56:47  * pooyajoined
21:57:39  <MI61>joyent/node: isaacs created tag v0.9.10 - http://git.io/KpVB9Q
21:58:02  <bnoordhuis>trevnorris: p pe->data ?
21:58:10  <trevnorris>ah, one sec
21:58:18  <bnoordhuis>also, p errno
21:58:27  * bradleymeckquit (Quit: bradleymeck)
21:58:31  <bnoordhuis>or if that doesn't work, p (int) __errno_location()
21:58:50  * piscisaureus_quit (Ping timeout: 244 seconds)
21:58:53  <MI61>joyent/node: isaacs master * 727151a : Now working on v0.9.11 (+3 more commits) - http://git.io/yZqRCA
22:00:37  <trevnorris>bnoordhuis: http://git.io/2L8uGA
22:01:03  * rendar_quit
22:01:11  <trevnorris>um. should I be doing this from a gcc build, or will clang work?
22:01:11  <bnoordhuis>trevnorris: oh sorry, p (int*) __errno_location()
22:01:14  <bnoordhuis>clang works
22:01:33  <bnoordhuis>kind of annoying that pe is also optimized away
22:01:37  * brsonquit (Ping timeout: 248 seconds)
22:01:37  <MI61>joyent/node: isaacs v0.8 * 3267464 : blog: v0.9.10 - http://git.io/NquO2A
22:02:06  <bnoordhuis>trevnorris: can you try this: p events[i]
22:02:51  <bnoordhuis>or p events[i].data
22:05:42  <isaacs>ok, v0.9.10 is out.
22:05:50  <isaacs>it's a little faster than 0.9.9, and a little better
22:06:07  <isaacs>trevnorris: so, this script, looks pretty ok. a few things i know are going to be ungood on smartos.
22:06:13  <bnoordhuis>isaacs: have you seen that tls benchmark someone posted?
22:06:14  <isaacs>trevnorris: killall is not what you think on sunos.
22:06:17  <dap1>bnoodrhuis: hi
22:06:23  <dap1>bnoordhuis: hi
22:06:23  <isaacs>bnoordhuis: which one? (no?)
22:06:30  * TooTallNatejoined
22:06:45  <trevnorris>bnoordhuis: both say "value has been optimized out"
22:07:01  <bnoordhuis>grr
22:07:25  <bnoordhuis>trevnorris: does it happen with debug builds? (please say yes)
22:07:27  <trevnorris>isaacs: i absolutely would not recommend that script. it was a complete hack i wrote at 2am.
22:07:36  <trevnorris>bnoordhuis: nope. well, haven't been able to reproduce.
22:07:49  <bnoordhuis>dap1: question about unix sockets and EINPROGRESS: when does that happen and why?
22:08:01  <bnoordhuis>i can't think of a plausible scenarion where a kernel would return that error
22:08:05  <bnoordhuis>*scenario
22:08:22  <bnoordhuis>isaacs: https://github.com/joyent/node/issues/4789
22:08:51  <dap1>bnoordhuis: Is your question why we do, or whether we do? DTrace showed that we do :)
22:08:59  <bnoordhuis>dap1: yes, why
22:09:23  <bnoordhuis>i mean, it's easy to fix in libuv but it doesn't make sense
22:11:28  <dap1>bnoordhuis: I didn't look that far into it. Memory allocation could be one case.
22:11:28  <dap1>But it's clearly allowed by the man page and standard, so I assuming you're just asking out of curiosity :)
22:11:31  <bnoordhuis>yeah, i am
22:11:42  <isaacs>bnoordhuis: i'll add some benchmarks.
22:12:03  <bnoordhuis>i was rather surprised. it's never returned on freebsd or linux
22:12:21  <bnoordhuis>in the sense that there's not even a code path for it in the kernel
22:12:22  <isaacs>bnoordhuis: this benchmark is idiotic, though.
22:12:31  <isaacs>bnoordhuis: it's doing completely different things, and littered with insane complaints.
22:12:34  * isaacssigh
22:12:46  <bnoordhuis>but she's pretty hot so we need to take it very seriously
22:12:52  <tjfontaine>haha
22:13:07  <tjfontaine>gravatar selection is how we will determine how willing we are to work on issues
22:13:08  <isaacs>bnoordhuis: also, npm.im/benchmark is untrustworthy, imo.
22:13:09  <trevnorris>bnoordhuis: i've helped her before on SO. want me to introduce you? ;-)
22:13:11  <isaacs>it does way too much stuff
22:13:14  <dap1>bnoordhuis: It's possible that those systems will block for what they expect to be short intervals where we return EINPROGRESS instead.
22:13:19  <dap1>e.g., memory allocation
22:14:16  <bnoordhuis>trevnorris: i'll take you up on that offer if i ever break up with my wife :)
22:14:45  <bnoordhuis>dap1: hm, okay. it's not anything to do with the connection backlog? (though that wouldn't make sense either)
22:14:47  <trevnorris>duly noted
22:15:03  <dap1>bnoordhuis: That's certainly possible, though I'd have expected ECONNREFUSED instead (and I've seen that one)
22:15:11  <isaacs>trevnorris: so: do you have any preliminary suggestions from this analysis, re: benchmark-refactor-2?
22:15:23  <dap1>it's possible that we issue EINPROGRESS when it's reached a high watermark or something. I'm just not sure.
22:15:29  <bnoordhuis>dap1: yeah, i think that's what freebsd returns. on linux, it's EAGAIN for some reason
22:16:09  <bnoordhuis>okay, interesting. i'll go and fix it in libuv then :)
22:16:24  <dap1>The code path you want is sotpi_connect(). You could also drill down empirically using DTrace by tracing all functions returning EINPROGRESS that were called from sotpi_connect(). I didn't bother going that far.
22:17:16  <trevnorris>isaacs: yeah. first for using the benchmarks for trending performance. users probably can't be trusted to make sure their systems won't affect fs, which will leave them very unstable.
22:18:17  <isaacs>trevnorris: right, but joyent can provide a relatively-stable vm
22:18:20  <trevnorris>isaacs: and we should take another look at cluster benchs. those are to volatile to be useful.
22:18:27  <isaacs>yeah
22:18:30  <isaacs>agreed
22:18:36  <isaacs>and that's an important once
22:18:37  <isaacs>*one
22:18:40  <dap1>bnoordhuis: https://github.com/joyent/illumos-joyent/blob/master/usr/src/uts/common/fs/sockfs/socktpi.c#L2164
22:18:45  <isaacs>for the time being, we can stick to http/simple and net
22:18:49  <isaacs>those look pretty ok
22:19:32  <trevnorris>isaacs: yeah, sorry. that's what I was getting at. so users should know that fs benchmarks will look like that, and we should run those PR's on the server. not just on our local machines (don't know if we were planning that anyways)
22:20:04  <trevnorris>isaacs: yeah. so for trending, net and http look good. now for the second part.
22:20:44  <isaacs>the goal of all of this is to run these in an automatic way for every commit that lands in master or a stable branch
22:21:04  <isaacs>being able to have it pull a PR and do an on-demand comparison is a plus, but not MVP
22:21:11  <trevnorris>if that's the only purpose then it's mostly there.
22:21:15  <isaacs>kewl
22:21:35  <isaacs>you mean, benchmark-refactor-2 is already suitable for this, barring the insanity in fs/cluster benchmarks?
22:21:37  <trevnorris>but using those tests for --trace-* or irhydra or valgrind, etc. won't be too useful. there's too much static.
22:21:45  * piscisaureus_joined
22:21:53  <isaacs>sure
22:21:53  <bnoordhuis>dap1: interesting, thanks
22:21:56  <isaacs>well, that's a separate thing
22:22:04  <trevnorris>yeah, figured. just wanted to bring it up.
22:22:40  <isaacs>kewl
22:23:07  <trevnorris>just going to verify something, sec.
22:23:48  <isaacs>also, i'd like to port this jsstat test to js and be able to run it on-demand. we should track not only our benchmark performance, but also our reliability.
22:23:53  <isaacs>maybe per-commit
22:24:19  <trevnorris>isaacs: not a problem. i created the api modular enough so each test can be plucked out when needed.
22:26:21  <isaacs>kewl
22:26:52  <isaacs>trevnorris: as you know, i'm hesitant to pull in new js libs to node-core. so i might do a little std-dev-ectomy just for this purpose :)
22:27:09  <isaacs>but meh. maybe it's worth pulling in jsStats just for this.
22:27:13  <isaacs>it's not a super huge lib
22:27:23  <trevnorris>isaacs: you mean jStat?
22:27:42  <trevnorris>isaacs: oh, screw jsstats.
22:27:56  <trevnorris>isaacs: https://github.com/jstat/jstat
22:28:38  <trevnorris>haven't needed to touch it in a while, but it's solid.
22:28:54  <trevnorris>and i can rip out each test you need.
22:29:01  <trevnorris>don't need to include an external lib.
22:32:14  <trevnorris>isaacs: it could be something like common.stat.stdev([arra]), or some such.
22:33:17  <isaacs>oh, jstat
22:33:19  <isaacs>whatever
22:33:26  <isaacs>JavaScriptStatisticometer
22:33:31  <trevnorris>lol
22:33:48  <trevnorris>just let me know which you want and I'll gist the minimal implementations you can stick in.
22:36:11  <trevnorris>isaacs: once we sign off a test then we can make very precise measurements. knowing the stdev within a +95% conf. int. will allow us to run many fewer tests and compensate for how we know it "should" look.
22:36:41  <trevnorris>then if something out of the ordinary shows up, then run a thicker test.
22:36:50  <trevnorris>but the day-to-day can be really light weight.
22:36:58  <isaacs>trevnorris: ok, so, for starters...
22:37:00  * bnoordhuisquit (Ping timeout: 260 seconds)
22:37:09  <isaacs>i'm going to run the net and http tests for 5s only
22:37:12  <isaacs>rather than 1 and also 3
22:37:35  <isaacs>and add a thing to run the tests N times and get the stdev
22:37:42  <isaacs>common.stat.blah() is probably good
22:37:57  <isaacs>but maybe it should just be a separate thing
22:38:06  <isaacs>since common is like, the runner, and the thing that actual benchmark scripts run
22:38:20  <isaacs>compare, analyze, etc, shoudl be external
22:38:24  <trevnorris>coolio.
22:39:07  <isaacs>maybe something like: ./node benchmark/validate.js [--bench=http,net,fs,tls]
22:39:26  <isaacs>then it'll run make bench-blah for each of those, 49 times, and print validity of each result.
22:39:53  <trevnorris>yeah. that sounds good.
22:39:53  <isaacs>hm. ./node benchmark/confidence.js
22:39:59  <isaacs>and it should report the confidence interval
22:40:05  <isaacs>from 0 to 100
22:40:26  <trevnorris>an by "validity" i'd say mean, stdev, med and quartiles.
22:40:37  <trevnorris>quartiles are important because they show the spread.
22:41:23  <isaacs>hm. true that
22:41:44  <isaacs>well... for the purposes of automation, the more we can keep things to a number that we try to push in a direction, the better.
22:41:49  <isaacs>qualitative results are ahrd.
22:41:51  <isaacs>require meat.
22:43:16  <trevnorris>the general idea would be to push the mean to Infinity.
22:43:27  <isaacs>right
22:43:28  <tjfontaine>and beyond
22:43:31  <trevnorris>lol
22:44:32  <trevnorris>by tracking stdev and quartiles we can quick check the output for fewer runs to see if they lay within the distribution.
22:44:54  <trevnorris>just so we can have more confidence that the tests are running correctly, w/o needing to run them 49 times every time.
22:45:13  <isaacs>right
22:45:22  <isaacs>well, i mean, we can adjust that number over time, i suppose
22:45:36  <isaacs>also, i can have the confidence.js script run until we get a specific confidence level.
22:45:54  <isaacs>which sucks, of course.
22:46:14  <tjfontaine>that's something that seems sane when preparing for a release, not necessarily on a per commit basis
22:46:15  <isaacs>but like, "run until 100 times, or until the confidence level is >90%" would be kinda rad to track over time
22:47:24  <trevnorris>> console.log('confidence interval: ', 1 - 1 / Math.sqrt(100));
22:47:32  <trevnorris>wait. how do you use that?
22:48:21  <isaacs>or, rather, until the stdev is below a certain amount
22:48:32  <trevnorris>isaacs: more tests your run, higher stdev will go.
22:48:36  <isaacs>sure
22:48:44  <isaacs>so you set a min, a max, and a min stdev
22:48:53  <isaacs>if we run it 10 times and the stdev is <0.5% of the mean, then we don't have to keep going
22:49:30  <trevnorris>isaacs: i think you're looking for standard error: http://en.wikipedia.org/wiki/Standard_error
22:49:46  <isaacs>basically, my goal is to work out an algorithm where we can have a single command that runs each benchmarks as many times as necessary to be reasonable sure that we are getting valid data.
22:50:20  <trevnorris>yeah. that's possible.
22:50:33  <isaacs>but, dno't run it more than N times, or fewer than M times
22:51:10  <trevnorris>yeah. so run minimum of M, and if it's required to run more than N then alert someone.
22:51:18  <trevnorris>because somethin ain't right
22:51:31  <isaacs>right
22:51:37  <isaacs>mark it in red in the graph
22:52:00  <isaacs>but, yeah, this has to be outside of `make bench`
22:52:20  <isaacs>it has to be a thing that calls each of the scripts that `make bench` calls
22:52:33  <trevnorris>oh, i didn't even expect this part to live in core. i mean, the data storage and stuff won't, right?
22:52:40  * c4miloquit (Remote host closed the connection)
22:52:52  <isaacs>trevnorris: nono, this script will live in core, but the data storage and graphics etc will be outside.
22:53:09  <isaacs>trevnorris: it'll be run by jenkins for every commit
22:53:15  <trevnorris>ah ok
22:54:26  <isaacs>trevnorris: so, here's the close: does this benchmark/run-until-good.js script sound like something you'd be interested in writing?
22:54:40  <isaacs>trevnorris: i'm pretty convinced that it's a good idea to land benchmark-refactor-2 mostly as-is
22:54:48  <isaacs>trevnorris: barring a few file name changes.
22:55:00  <isaacs>and the settings default changes mentioned above
22:57:04  <trevnorris>isaacs: sure. run-until-good and the benchmarks aren't even directly related. if i'm using the current output, then it's parse-able.
22:57:14  <isaacs>yep
22:57:47  <trevnorris>isaacs: so I can create a json of the results not a problem. but how will jenkins like me to poop it out?
22:58:15  * brsonjoined
22:58:20  <tjfontaine>depends on what we use in jenkins, that part isn't set in stone
22:59:07  <trevnorris>ok, well i'll just create a placeholder for it.
22:59:42  <trevnorris>isaacs: just let me know when you've updated refactor-2 and i'll create the script.
22:59:53  <isaacs>k, almost done
22:59:55  <trevnorris>isaacs: now, do you really want it called run-until-good?
23:04:11  <isaacs>trevnorris: no, i expect you to pick a better name than that :)
23:04:27  <isaacs>trevnorris: that name is intentionally bad so that we don't have to debate about it.
23:08:39  <indutny>ben you was wrong
23:09:09  <indutny>ircretary: tell bnoordhuis that he was wrong, thunderstorm is happening with epoll as it happens with kevent() and all other polling systems
23:09:09  <ircretary>indutny: I'll be sure to tell bnoordhuis
23:09:33  <trevnorris>indutny: that have to do with the abort issue i'm having?
23:09:44  <indutny>no
23:09:50  <indutny>its only about cluster performance
23:09:53  <indutny>actually
23:09:59  <indutny>rps distribution between forks
23:10:51  * EhevuTovjoined
23:11:33  <trevnorris>oh. well bummer. i want to know why that test is aborting.
23:11:47  <indutny>heh
23:11:50  <trevnorris>isaacs: and fwiw, the abort started to happen on my machine after your 8476aef commit.
23:12:03  <trevnorris>if I revert that then don't have the issue.
23:12:18  <indutny>ttyl
23:12:19  * indutny&
23:12:19  <LOUDBOT>NO FARTING ON COMPANY PROPERTY
23:12:23  <isaacs>trevnorris: that's kinda insane
23:12:26  <tjfontaine>trevnorris: what all can you tell me about your environment?
23:12:32  <isaacs>trevnorris: i mean, all that did was change the defaults
23:12:44  <trevnorris>yeah, that's why i'm so confused.
23:12:52  <isaacs>trevnorris: so that means it was there waiting to be hit, but just got dodged slightly because of some kind of alignment or tming or some shit.
23:13:18  <tjfontaine>well, it increased throughput at that point, so it's exacerbating the problem on his system anyway
23:13:19  <trevnorris>isaacs: yeah. this is completely some kind of race condition.
23:13:29  * isaacstopic: liberal utopian vacation ~ "Shit came real! --indutny" ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
23:13:41  * isaacstopic: liberal utopian vacation ~ "Shit came real!" --indutny ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
23:15:19  <trevnorris>tjfontaine: xubuntu 12.10, i7-2860QM, 8GB ram, 3.5.0-19, building w/ clang (about to try w/ gcc)
23:15:24  <trevnorris>what else you'd like?
23:15:49  <isaacs>trevnorris: so, to actually track this down, then, we'd need a test that runs with those stream defaults
23:15:51  <tjfontaine>that's pretty much what I wanted to know, I presume bare metal? and platter sata?
23:15:56  <isaacs>trevnorris: ie, setting them explicitly
23:16:10  <isaacs>trevnorris: then you can bisect that, and i bet it's not that commit where it started.
23:16:55  <MI61>joyent/node: isaacs created branch benchmark-refactor-2 - http://git.io/24SdpA
23:16:56  <isaacs>trevnorris: ^
23:17:04  <trevnorris>cool
23:17:17  <isaacs>now i'm gonna write a new one for https://gist.github.com/naomik/4967659
23:18:08  <trevnorris>tjfontaine: yeah, using a ST9500420AS
23:18:34  <trevnorris>isaacs: so you're saying reintroduce that change to every bisect and see where it really started?
23:18:38  * wolfeidaujoined
23:18:45  <tjfontaine>trevnorris: just for clarity no md or dm in the mix? (mdadm or lvm)
23:19:05  <tjfontaine>trevnorris: well since it's reproducing on your box you should try it :)
23:20:08  <trevnorris>tjfontaine: don't you use lvm w/ full disk encryption? if so, then yes.
23:20:50  <tjfontaine>hehe, well now I can't tell if you're being sarcastic or not :)
23:25:20  <trevnorris>tjfontaine: yeah, using crypt-luks
23:25:44  <tjfontaine>ok well, alright
23:26:36  <trevnorris>and i'm extremely sleep deprived. kids been sick last couple nights so i'm a little delusional.
23:26:38  <isaacs>trevnorris: or just make a test that sets the water marks explicitly
23:26:44  <isaacs>trevnorris: no worries :)
23:27:03  <isaacs>trevnorris: totally understandable
23:31:25  <trevnorris>isaacs: just want to confirm something you said. noticed that a bare implementation of tcp-raw tests run ~7% slower, but you're not worried about that, right?
23:39:05  <trevnorris>isaacs: yup. so far back to v0.9.6 and still happening.
23:42:00  * hzjoined
23:43:06  * bnoordhuisjoined
23:45:28  <mraleph>no-no, please don't curse me :-)
23:47:37  <trevnorris>mraleph: dude, seriously. now I have an obsession about making those graphs look neat and tidy.
23:47:50  * jmar777joined
23:48:06  * bnoordhuisquit (Ping timeout: 264 seconds)
23:52:41  <trevnorris>isaacs: the best I can do is f9caf70, before that and the test completely fails.
23:54:44  * `3rdEdenquit (Remote host closed the connection)