Switch to DuckDuckGo Search
   March 26, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >

Toggle Join/Part | bottom
[00:03:51] *** ZOP_ <ZOP_!~ZOP@phobos.wgops.com> has joined #illumos
[00:06:37] *** ZOP <ZOP!~ZOP@phobos.wgops.com> has quit IRC (Ping timeout: 272 seconds)
[00:07:03] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[00:13:12] *** andy_js <andy_js!~andy@> has quit IRC (Quit: andy_js)
[00:16:34] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has quit IRC (Ping timeout: 240 seconds)
[00:21:05] *** jocthbr <jocthbr!~salci@> has joined #illumos
[00:27:34] *** jocthbr <jocthbr!~salci@> has quit IRC (Ping timeout: 240 seconds)
[00:31:24] <rmustacc> jollyd1: No worries. I finished up all the review from jlevon and fleshed out my internal testing. So I may try to put back the initial version, if you think that makes sense?
[00:33:30] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[00:33:42] *** jocthbr <jocthbr!~salci@> has joined #illumos
[00:39:45] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has joined #illumos
[00:44:13] <jollyd1> rmustacc: I think you should go ahead then
[00:49:42] <jollyd1> damn... I wonder what make HPCG's DDOT and WAXPBY nearly three times slower on illumos than Ubuntu... while the multigrid solver is consistenly 20% faster on illumos...
[00:50:54] <Mokou> ok, sorry for that but i'm going to ask some dumb question again
[00:51:13] <rmustacc> jollyd1: No idea there off hand. Maybe worth profiling?
[00:51:25] <Mokou> is there anybody willing to tell me what do we need for a proper SO_REUSEPORT implementation?
[00:51:40] <rmustacc> Are you interested in working on it?
[00:51:45] <Mokou> cause i just added a simple round-robin load balancing for tcp on my test machine
[00:51:50] <rmustacc> And how much do you understand about the semantics of it?
[00:52:14] <Mokou> but i'm sure i've broken lots of thing since this is the first time i touch any kernel code
[00:53:20] <rmustacc> So, pmooney probably has the most state here having worked on earlier incarnations I think there are a bunch of questions around semantics, etc.
[00:54:11] <jollyd1> rmustacc: that's why I started comparing runs initially, I will investigate further
[00:54:14] <Mokou> rmustacc: only the obvious? im not really sure what exactly its sematics is
[00:54:17] <danmcd> Don't BSD and Linux differ on REUSEPORT semantics? Oh no, that's REUSEADDR, where IIRC, Linux uses it slipshod as a synonym for REUSEPORT.
[00:54:33] <danmcd> And yes, pmooney has the most history/context there.
[00:54:39] <pmooney> Mokou: the edge cases are especially important
[00:54:59] <rmustacc> jollyd1: OK, I'll be curious as to what you find. One area I know I've been meaning to look at is in alligned allocs, which sometimes pop up with umem having problems.
[00:55:32] <rmustacc> So, I think one of the general gotchas is that all load balancing solutions have challenges whether random, least-loaded, etc.
[00:55:52] <pmooney> Mokou: today, the REUSEPORT impl that is exposed for LX is simply last one to open the ip/port "wins"
[00:56:06] <pmooney> so if three processes open the same ip/port, only the last one will ever receive new connections
[00:56:24] <pmooney> this is because it's very challenging in the network stack to "un-accept" a connection
[00:56:31] <LeftWing> Which helps for the narrow case of "starting a new nginx while the old one drains"
[00:56:35] <pmooney> which would be necessary if you were, say, round-robin-ing the connections to those open sockets
[00:56:49] <rmustacc> I believe the Linux strategy may be round robin, but questions are around what happens if one has a full socket backlog? Do you fall back to another?
[00:56:57] <pmooney> yeah, the usecase LeftWing describes is why it was added to LX
[00:57:27] *** amrfrsh <amrfrsh!~Thunderbi@> has joined #illumos
[00:57:36] <pmooney> some consumers of it on Linux, AFAIK, expect it to function in a sort of load-balancing manner
[00:57:56] *** razamatan <razamatan!~blah@unaffiliated/razamatan> has quit IRC (Ping timeout: 256 seconds)
[00:58:02] <pmooney> where several processes/threads could bind to the same socket via REUSEPORT and have incoming connections distributed evenly among them
[00:59:03] <Mokou> yeah, thats what i expect to achieve too (if i have the ability to)
[00:59:09] <pmooney> it's a pretty significant effort to implement that in a way that's robust
[00:59:19] <rmustacc> But, that's no reason not to give it a shot.
[00:59:30] <pmooney> sure, it's not an insurmountable task
[00:59:39] <pmooney> but do not mistake it for one that is simple or easy
[01:00:04] <rmustacc> Another thing to think about as you poke at is is it worth being able to change out that algorithm much like a pluggable congestion algorithm. e.g. swap from round-robin to random to least conns, etc.
[01:00:29] <rmustacc> As the actual picking part probably isn't so bad relative to the rest.
[01:00:32] <pmooney> rmustacc: honestly, the hardest part, IMO, is "giving back" packets if/when you close a socket that's in one of those REUSEPORT "groups"
[01:01:14] <rmustacc> Makes sense. Most of the challenge isn't in the actual load balancing, but the socket transfer mechanics.
[01:01:20] <pmooney> and without that, you'll end up dropping connections on the floor for the nginx graceful restart example
[01:01:38] <pmooney> which is the exact opposite of what one would want from SO_REUSEPORT
[01:01:52] <Mokou> iirc tho, i believe there's some rsts when listener number changes in earlier linux kernel at least?
[01:02:13] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[01:02:14] <pmooney> I've not spent much time at all looking at the linux implementation
[01:02:14] *** razamatan <razamatan!~blah@unaffiliated/razamatan> has joined #illumos
[01:02:30] <pmooney> I did spend some time exploring the different interface semantics between linux and freebsd
[01:02:40] <pmooney> those results are detailed in a smartos ticket somewhere, IIRC
[01:03:04] <Mokou> yeah i remember seeing them
[01:03:53] <Mokou> i'll try to confirm linux implementation on listener close
[01:04:32] <Mokou> if linux does drop connections on listener close, do you think its acceptable for us to do the same for now?
[01:05:42] <pmooney> I think REUSEPORT would be of dubious value if it drops connections like that
[01:06:03] <pmooney> certainly for the graceful restart case
[01:06:25] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Client Quit)
[01:07:46] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[01:08:28] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Remote host closed the connection)
[01:09:11] <Mokou> sure, but i think there's also lots of people wise to use it sorely for avoiding thundering herd
[01:09:26] <Mokou> anyway i'll look into linux and bsd implementation first
[01:11:12] <rmustacc> Well, the problem is that a lot of software, like nginx is already built for the graceful reset case. So we need to conisder that reality.
[01:12:27] <Mokou> that's why i'll only consider that option if linux also behaves like this
[01:12:43] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[01:13:11] <Mokou> if linux won't drop connection in that case, then we certainly shouldn't
[01:14:40] <Mokou> https://lwn.net/Articles/542629/ yeah linux used to do that
[01:14:52] <Mokou> but thats from 2013, probably fixed by now
[01:17:27] <Mokou> https://bugzilla.redhat.com/show_bug.cgi?id=1203000 and this is closed as WONTFIX
[01:17:34] <Mokou> emmm
[01:22:03] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[01:26:32] <Mokou> my quick search in commit history didn't find anything addressing this problem
[01:26:50] <Mokou> lemme try if i can test this
[01:41:32] *** jollyd1 <jollyd1!~alarcher@2a01:cb1d:611:bb00:8079:e197:1fb9:1e87> has quit IRC (Ping timeout: 246 seconds)
[01:41:32] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has quit IRC (Remote host closed the connection)
[01:41:59] *** jollyd1 <jollyd1!~alarcher@2a01:cb1d:611:bb00:ccdc:66a:bf33:2ffd> has joined #illumos
[01:42:00] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has joined #illumos
[01:44:01] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has quit IRC (Remote host closed the connection)
[01:44:34] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[01:47:21] <Mokou> okay
[01:48:14] <Mokou> on my arch box connections in backlog do seem to be rst-ed
[01:48:23] <Mokou> https://gist.github.com/AraragiHokuto/e2bf8fcc474b82ca936f6ecf0f8510b8 test server i used
[01:48:30] <Mokou> Linux abukuma 5.5.10-1-ck #1 SMP PREEMPT Sat, 21 Mar 2020 10:42:04 +0000 x86_64 GNU/Linux
[01:50:48] <Mokou> what do you think about it?
[01:51:19] <Mokou> (i might misunderstood the situation tho, so do point out if i got my test wrong)
[02:28:36] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has quit IRC (Ping timeout: 256 seconds)
[02:28:37] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has joined #illumos
[02:32:29] <rmustacc> jollyd1: Oh, is one build tuning for generic and another something else?
[02:41:18] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has joined #illumos
[02:42:28] *** jollyd_ <jollyd_!~jollyd@2a01:cb1d:611:bb00:3a78:62ff:fe48:66d6> has joined #illumos
[02:43:59] <jollyd_> rmustacc: about hpcg both builds are set to -march=native
[02:45:14] <jollyd_> rmustacc: it was about something else, I was wondering why illumos is built with -mtune=opteron
[02:46:40] <jollyd_> so I rebuilt with -march=x86-64 -mtune=generic to see how the binaries differ
[02:46:56] <jollyd_> it is just educational
[02:47:36] <rmustacc> Ah, that's a reasonable question. Probably tuning ot generic would be better, but I'd be curious what you see there.
[02:48:08] <rmustacc> Mokou: I think the more interesting test is what happens between different processes there.
[02:51:03] <jollyd_> rmustacc: I'll keep comparing tomorrow, time to sleep... at least the system boots, that's reassuring ;)
[03:10:25] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 264 seconds)
[03:10:45] *** jocthbr <jocthbr!~salci@> has quit IRC (Quit: No Ping reply in 180 seconds.)
[03:21:36] *** nbhauke_ <nbhauke_!~hauke@55d4ecaf.access.ecotel.net> has joined #illumos
[03:23:34] *** nbhauke <nbhauke!~hauke@55d42d24.access.ecotel.net> has quit IRC (Ping timeout: 256 seconds)
[03:23:35] *** nbhauke_ is now known as nbhauke
[03:31:08] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has joined #illumos
[03:46:47] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[03:56:48] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[03:58:54] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:b4b3:ef99:8ab9:366c:4195> has joined #illumos
[04:03:50] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:21:31] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[04:28:38] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[04:41:28] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:b4b3:ef99:8ab9:366c:4195> has quit IRC (Ping timeout: 256 seconds)
[06:10:14] *** Bryson <Bryson!~anonymous@ip68-104-0-41.lv.lv.cox.net> has quit IRC (Quit: Bryson)
[06:11:40] *** Bryson <Bryson!~anonymous@ip68-104-0-41.lv.lv.cox.net> has joined #illumos
[06:12:46] *** Bryson <Bryson!~anonymous@ip68-104-0-41.lv.lv.cox.net> has quit IRC (Client Quit)
[06:27:02] *** BOKALDO <BOKALDO!~BOKALDO@> has joined #illumos
[06:36:56] *** jollyd_ <jollyd_!~jollyd@2a01:cb1d:611:bb00:3a78:62ff:fe48:66d6> has quit IRC (Ping timeout: 246 seconds)
[06:40:19] *** jollyd_ <jollyd_!~jollyd@2a01:cb1d:611:bb00:3a78:62ff:fe48:66d6> has joined #illumos
[06:42:20] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[06:54:05] *** Asgaroth_ <Asgaroth_!~Asgaroth@> has joined #illumos
[06:57:05] *** Asgaroth <Asgaroth!~Asgaroth@> has quit IRC (Ping timeout: 240 seconds)
[07:32:59] *** razamatan <razamatan!~blah@unaffiliated/razamatan> has left #illumos ("this is a bad part message.")
[07:43:38] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:b4b3:ef99:8ab9:366c:4195> has joined #illumos
[07:57:44] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has joined #illumos
[08:27:18] *** pwinder <pwinder!~pwinder@> has joined #illumos
[08:29:17] <sensille> i have a linker problem. in my .so, an internal function call is resolved to a function of the host executable instead of the internal function
[08:29:58] <sensille> is that common behaviour?
[08:30:27] *** jollyd_ <jollyd_!~jollyd@2a01:cb1d:611:bb00:3a78:62ff:fe48:66d6> has quit IRC (Quit: IRC for Sailfish 0.9)
[08:51:01] <Agnar> moin
[08:53:35] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[08:57:07] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has quit IRC (Ping timeout: 250 seconds)
[09:02:42] *** neuroserve <neuroserve!~toens@ip-178-202-214-238.hsi09.unitymediagroup.de> has quit IRC (Ping timeout: 256 seconds)
[09:06:24] *** rzezeski <rzezeski!uid151901@gateway/web/irccloud.com/x-cnvmfcmxnkzgsecj> has quit IRC (*.net *.split)
[09:06:24] *** shuryanc[m] <shuryanc[m]!shuryancma@gateway/shell/matrix.org/x-nomdqjgpaxbxhxpr> has quit IRC (*.net *.split)
[09:06:25] *** ballew <ballew!sid244342@gateway/web/irccloud.com/x-luvldcllnqnpvksg> has quit IRC (*.net *.split)
[09:06:25] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has quit IRC (*.net *.split)
[09:06:25] *** morgib[m] <morgib[m]!morgibmatr@gateway/shell/matrix.org/x-bfeowszxgwxjepux> has quit IRC (*.net *.split)
[09:06:25] *** hawk <hawk!~hawk@d.qw.se> has quit IRC (*.net *.split)
[09:06:25] *** Teknix <Teknix!~pds@> has quit IRC (*.net *.split)
[09:06:25] *** kohju <kohju!~kohju@gw.justplayer.com> has quit IRC (*.net *.split)
[09:06:46] *** hawk <hawk!~hawk@d.qw.se> has joined #illumos
[09:06:47] *** kohju <kohju!~kohju@gw.justplayer.com> has joined #illumos
[09:06:52] *** ballew <ballew!sid244342@gateway/web/irccloud.com/x-dvvgvswxopewnkyh> has joined #illumos
[09:06:54] *** rzezeski <rzezeski!uid151901@gateway/web/irccloud.com/x-nxtahcfvtepubqbx> has joined #illumos
[09:07:05] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has joined #illumos
[09:08:37] *** Teknix <Teknix!~pds@> has joined #illumos
[09:09:12] *** shuryanc[m] <shuryanc[m]!shuryancma@gateway/shell/matrix.org/x-zjykksvpweynlmxr> has joined #illumos
[09:09:38] *** gmodena <gmodena!~gmodena@> has quit IRC (Ping timeout: 240 seconds)
[09:10:25] *** morgib[m] <morgib[m]!morgibmatr@gateway/shell/matrix.org/x-oicjvqigjjgounnh> has joined #illumos
[09:12:29] *** gmodena <gmodena!~gmodena@> has joined #illumos
[09:23:09] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[09:39:57] *** andy_js <andy_js!~andy@> has joined #illumos
[09:51:43] *** eki <eki!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has quit IRC (Quit: leaving)
[09:56:45] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[09:57:29] *** eki <eki!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has joined #illumos
[09:58:28] *** man_u_ <man_u_!~manu@fob.gandi.net> has joined #illumos
[10:01:25] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Ping timeout: 264 seconds)
[10:01:26] *** man_u_ is now known as man_u
[10:06:57] <richlowe> sensille: Yes, unless you use direct binding
[10:07:51] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[10:08:19] <sensille> richlowe: what is the general way to do it? i found "-z now", but that doesn't work (anymore)
[10:09:47] *** neuroserve <neuroserve!~toens@ip-94-114-237-187.unity-media.net> has joined #illumos
[10:09:54] *** man_u <man_u!~manu@fob.gandi.net> has quit IRC (Ping timeout: 240 seconds)
[10:09:59] *** man_u_ <man_u_!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[10:23:29] *** man_u <man_u!~manu@fob.gandi.net> has joined #illumos
[10:23:38] <sensille> oh, -B direct
[10:24:13] *** man_u_ <man_u_!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Ping timeout: 250 seconds)
[10:55:14] <Mokou> rmustacc: https://gist.github.com/AraragiHokuto/068dd21075d14c17f3709ce391ee22cf like this one?
[10:55:33] <Mokou> this one also get pending connections rst-ed on my box
[11:06:02] <sensille> work, thanks richlowe for the pointer
[11:33:51] *** man_u <man_u!~manu@fob.gandi.net> has quit IRC (Ping timeout: 265 seconds)
[11:34:30] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[11:47:01] *** man_u_ <man_u_!~manu@fob.gandi.net> has joined #illumos
[11:48:49] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Ping timeout: 264 seconds)
[11:48:49] *** man_u_ is now known as man_u
[12:01:34] *** pvs <pvs!sid19318@lopsa/member/pvs> has quit IRC (Quit: Connection closed for inactivity)
[12:01:40] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[12:04:21] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[12:04:21] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Read error: Connection reset by peer)
[12:04:54] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[12:11:05] *** basvdlei <basvdlei!~basvdlei@2001:980:a4c3:1:e6b9:7aff:fe9f:3993> has joined #illumos
[12:17:11] *** schily_ <schily_!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has quit IRC (Quit: BitchX-1.0c19 -- just do it.)
[12:30:33] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[12:32:40] <tsoome> had more robots near our office than people:)
[12:52:23] *** varna <varna!~varna@> has joined #illumos
[13:04:54] *** kerberizer <kerberizer!~luchesar@wikipedia/Iliev> has quit IRC (Ping timeout: 256 seconds)
[13:09:00] *** kerberizer <kerberizer!~luchesar@wikipedia/Iliev> has joined #illumos
[13:44:46] *** schily_ <schily_!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has joined #illumos
[13:46:09] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 250 seconds)
[13:47:49] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[13:53:05] <jollyd1> is there a native way to get statistics on cache misses in illumos for a given run?
[14:13:29] *** BOKALDO <BOKALDO!~BOKALDO@> has quit IRC (Quit: Leaving)
[14:17:26] *** man_u <man_u!~manu@fob.gandi.net> has quit IRC (Ping timeout: 256 seconds)
[14:23:20] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[14:28:45] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[14:54:30] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[15:26:28] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[15:27:07] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[15:27:44] *** jbk_ <jbk_!jbk@syzygy.io> has joined #illumos
[15:28:26] *** tg2 <tg2!~tg2@> has quit IRC (Ping timeout: 264 seconds)
[15:28:33] *** tg2_ <tg2_!~tg2@> has joined #illumos
[15:29:08] *** n_shp <n_shp!hi@my.domain.is.better.thanyours.com> has joined #illumos
[15:29:37] *** Bdragon <Bdragon!~bdragon@drupal.org/user/53081/view> has quit IRC (Ping timeout: 264 seconds)
[15:29:38] *** jbk <jbk!jbk@syzygy.io> has quit IRC (Ping timeout: 264 seconds)
[15:29:39] *** tru_tru <tru_tru!~tru@> has quit IRC (Ping timeout: 240 seconds)
[15:29:50] *** tru_tru <tru_tru!~tru@> has joined #illumos
[15:30:02] *** nshp <nshp!~hi@my.domain.is.better.thanyours.com> has quit IRC (Ping timeout: 240 seconds)
[15:30:52] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:b4b3:ef99:8ab9:366c:4195> has quit IRC (Ping timeout: 256 seconds)
[15:31:36] *** Bdragon <Bdragon!~bdragon@drupal.org/user/53081/view> has joined #illumos
[15:33:40] *** BOKALDO <BOKALDO!~BOKALDO@> has joined #illumos
[15:41:22] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 256 seconds)
[15:42:55] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[15:45:13] *** lblume <lblume!~lblume@greenviolet/laoyijiehe/lblume> has quit IRC (Quit: Leaving.)
[15:45:42] *** lblume <lblume!~lblume@greenviolet/laoyijiehe/lblume> has joined #illumos
[15:52:23] *** jbk_ is now known as jbk
[16:07:57] <rmustacc> jollyd1: You're looking for the CPU performance counters, right?
[16:08:37] <rmustacc> jollyd1: Take a look at cpustat(1M) and the Intel perfomon events. Thankfully we should be fairly pu to date on support for those on the intel side.
[16:17:50] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Read error: Connection reset by peer)
[16:20:12] *** n_shp is now known as nshp
[16:28:05] <jollyd1> rmustacc: thank you :)
[16:28:48] *** ZOP_ is now known as ZOP
[16:28:50] <rmustacc> jollyd1: The Intel perfmon site is a good overview of events. I autogenerated manual pages for each platform based on that.
[16:29:21] <rmustacc> Doing that has made it infinitely easier to deal with.
[16:35:13] *** Bryson <Bryson!~anonymous@ip68-104-0-41.lv.lv.cox.net> has joined #illumos
[17:07:55] <jollyd1> rmustacc: can all these events be called with Dtrace CPC probes ?
[17:09:09] <rmustacc> I think so, yes.
[17:09:22] <rmustacc> Though I'm not very familiar with the integration. But those should be the same event names.
[17:09:48] <rmustacc> IIRC, when Bryan was doing some rust benchmarking and comparing it to gcc he just ran cpustat or cputrack to collect it all while the app ran, but I don't really remember to be honest.
[17:37:15] <rmustacc> jbk: I notice that the sha crypto tests time out on slower CPUs beacuse they hit the default 60s timeout. Maybe it's worth bumping that up?
[17:37:55] <rmustacc> At least, my laptop doesn't run sha that fast.
[17:40:30] <jbk> can't hurt -- i run into that now and then.. when i've floated it before, the answer i got was 'doesn't time out for me'.. so i never really did more with it
[17:41:19] <jbk> i know some of those tests have quite a few test vectors
[17:41:33] <jbk> i just took all the NIST ones and put them in there
[17:42:01] *** jimklimov <jimklimov!~jimklimov@> has quit IRC (Quit: Leaving.)
[17:42:40] <rmustacc> sha384*, sha512*, md5_32, etc. all fail so far and that's in pkcs.
[17:43:12] <jbk> i think it'd be fine to do so, esp if someone more than just me is seeing it
[17:43:43] <jbk> i could look at multi-threading the tests to make things quicker, though that might be overkill
[17:49:15] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Read error: Connection reset by peer)
[17:54:30] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[17:54:36] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[18:02:18] <neirac> toasterson I'm sorry I think I asked this the last time, I'm trying to add flock to golang, I'm modifying x/sys/unix to add it to illumos, I'm on the right track ?
[18:04:51] <rmustacc> neirac: I feel like that's something maybe LeftWing did at some point or looked at?
[18:06:24] *** leoric_ <leoric_!~leoric@2a02:2698:602b:39d2:29ff:f844:5d05:be34> has joined #illumos
[18:10:52] <neirac> rmustacc thanks!, LeftWing could you give me some pointers on how to proceed with this ?
[18:11:28] <LeftWing> I think it needs to go into the syscall package
[18:11:58] <LeftWing> Which is frozen mostly but this API already exists so they said it'd be ok
[18:12:06] <LeftWing> There's a ticket about it
[18:12:34] *** pwinder <pwinder!~pwinder@> has quit IRC (Quit: This computer has gone to sleep)
[18:12:42] <rmustacc> Anyone want to review some kstat manaul page improvements: https://code.illumos.org/c/illumos-gate/+/454
[18:12:44] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Remote host closed the connection)
[18:12:53] <neirac> LeftWing ok, I'll read the ticket to try to understand what's needed.
[18:13:32] <LeftWing> I can find it soon. Just not at my desk yet
[18:14:11] <neirac> LeftWing no problem, thanks for the assistance.
[18:14:29] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[18:21:13] *** leoric_ <leoric_!~leoric@2a02:2698:602b:39d2:29ff:f844:5d05:be34> has quit IRC (Quit: Konversation terminated!)
[18:25:09] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[18:31:39] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[18:35:30] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has left #illumos ("Leaving")
[18:39:57] *** pwinder <pwinder!~pwinder@> has joined #illumos
[18:45:19] *** pwinder <pwinder!~pwinder@> has quit IRC (Quit: This computer has gone to sleep)
[18:46:44] <toasterson1> neirac (IRC): I can't remember if you asked before :) even so no worries about that. Yes x/sys/unix is the right place to add it.
[18:48:26] <toasterson1> x/sys/unix is the experimental version of syscall. everything in syscall is also in x/sys/unix but the latter is not frozen and thus has more. Are you also going to add fnctl functions like fattach and fdettach? I could use those.
[18:49:29] *** neuroserve <neuroserve!~toens@ip-94-114-237-187.unity-media.net> has quit IRC (Ping timeout: 250 seconds)
[19:08:43] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[19:19:17] <LeftWing> toasterson1: I believe the syscall package is right for flock(); see: https://github.com/golang/go/issues/35618
[19:19:20] <LeftWing> neirac: ^^
[19:19:29] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[19:19:51] <LeftWing> In particular, they have Flock() for other platforms so it makes sense for us to add support for our flock() in the same place
[19:19:55] <LeftWing> And they would then use it in the standard library
[19:20:16] <toasterson1> LeftWing (IRC): x/sys/unix is the upstream of the frozen syscall package. So if syscall has it x/sys/unix will automatically get it
[19:20:44] <toasterson1> Oh, if we can get it into the stndard library that would be good. we could not before with mmap
[19:21:21] <LeftWing> I think part of the challenge is that the standard library has a syscall() function, and accepts numeric arguments, which obviously only makes sense on Linux
[19:21:33] <LeftWing> But for Flock() they at least have a symbolic wrapper in there already
[19:22:07] *** jellydonut <jellydonut!~quassel@s91904423.blix.com> has quit IRC (Quit: jellydonut)
[19:22:28] <toasterson1> oh are the syscall functions in syscall and x/sys/unix different? I thought they were the same.
[19:22:46] <LeftWing> I am not sure, but I thought the external module had evolved a bunch
[19:23:43] *** jellydonut <jellydonut!~quassel@s91904423.blix.com> has joined #illumos
[19:25:09] <richlowe> I'm so happy to not understand this conversatin
[19:25:21] <LeftWing> What makes you think I understand :D
[19:25:35] * LeftWing just pushes buttons beep boop
[19:27:21] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[19:27:21] <Mokou> i have the impression that Flock() already exists in x/sys/unix?
[19:28:07] *** neuroserve <neuroserve!~toens@ip-84-118-128-132.unity-media.net> has joined #illumos
[19:28:09] <toasterson1> It exists but the underlying implementation does not support illumos
[19:28:10] <Mokou> cause i was adding readv/writev the other day, and remember seeing it in zsyscall_unix.go
[19:28:18] <LeftWing> At least for https://golang.org/pkg/syscall/#Flock we should push to be in syscall -- they've given us an opening after all.
[19:28:19] <Mokou> which does get compiled on illumos
[19:28:32] <LeftWing> And then one imagines we could make the case for Mmap() after that, if somebody wanted to do so.
[19:28:42] <toasterson1> oh? leet me have a look then
[19:28:45] <neirac> LeftWing so I still need to modify the syscall ?
[19:29:00] <LeftWing> neirac: I would try and do so under that issue I linked above, yes
[19:29:11] <Mokou> the syscall packages tho, is basically empty on illumos irrc
[19:29:14] <Mokou> iirc*
[19:29:15] <neirac> I checked and syscalls are created with a script that checks GOOS,
[19:29:37] <neirac> yes, there are only solaris. ok I'll take a look then and rebuild golang
[19:29:40] <LeftWing> I don't think they're created with a script anymore?
[19:29:54] <LeftWing> At least some of the generated code in there was generated just once, and they now maintain it by hand
[19:30:01] <Mokou> x/sys/unix still generate wrappers with scripts
[19:30:31] <LeftWing> Fair enough -- all the work I did was in the primary Go repository.
[19:30:51] <neirac> LeftWing yes, the README.md on x/sys/unix still explains that, I changed teh GOOS to illumos to generate them but failed, I'm missing some files
[19:31:21] <Mokou> btw is there some errno constants that present only on solaris 11+ but not on illumos?
[19:31:34] <neirac> should I create zsyscall_illumos_amd64.go ?
[19:31:40] <neirac> or just use hte solaris one
[19:32:01] <Mokou> if solaris have flock too then there's probably no need
[19:32:26] <Mokou> +build solaris also works on illumos
[19:32:52] <rmustacc> Solaris doesn't support flock.
[19:33:15] <LeftWing> Right, this would be new functionality under the illumos tag only
[19:33:29] <Mokou> if that's the case you probably should add a zsyscall_illumos_amd64
[19:33:45] <Mokou> https://go-review.googlesource.com/c/sys/+/224238 that's their suggestion on preadv/pwritev
[19:33:55] <neirac> ok, I'll work on that then
[19:33:59] <LeftWing> Mokou: They may well have added new error numbers -- it's been a decade. I haven't looked.
[19:34:13] <neirac> thanks a lot for the pointers
[19:34:25] <LeftWing> You're welcome!
[19:34:55] <Mokou> LeftWing: i noticed some error numbers does not get generated on illumos (compared with the version already in x/sys/unix)
[19:36:12] <Mokou> end up leaving _solaris_amd64.go untouched, but we probably need a new PR for zerrors_illumos_amd64?
[19:37:34] <LeftWing> I'm definitely not an authority here -- especially on x/sys/unix. If that seems right to you, I'd say give it a shot!
[19:37:56] <LeftWing> We have the illumos build tag now, so it should be easier to get changes like that to happen without worrying about Solaris testing or anything.
[19:38:03] <LeftWing> We can just do whatever is right for us.
[19:38:23] <Mokou> ok i'll create a issue later then
[19:38:24] <neirac> LeftWing yes, that's really nice easier to work
[19:38:41] <toasterson1> ou any change for fattach/fdettach?
[19:40:13] <rmustacc> Thanks for helping get the build tag there, LeftWing.
[19:40:22] <rmustacc> And to the folks who are doing the same for rust.
[19:40:40] <LeftWing> You're welcome. Thanks really go out to Brad Fitz who put up with me and helped me get it in!
[19:43:08] <Mokou> btw sorry if thats a dumb question, but is there anyway (other than running) to incremental build and install kernel quicker?
[19:43:21] <Mokou> nightly -i -n still need about half an hour on my vm
[19:44:18] <Mokou> (other than running nightly)*
[19:44:34] <rmustacc> I iterate with bldenv and dmake for individual bits, at least.
[19:45:01] <rmustacc> If you need packages, not sure. Maybe reduced nightly flags?
[19:45:40] <LeftWing> Mokou: Are you still running smatch and/or the GCC 4.4.4 shadow?
[19:45:57] <LeftWing> During your iterative work it can be faster just to use the one primary and turn off the shadows
[19:46:38] <LeftWing> The package creation part definitely takes time
[19:46:54] <LeftWing> Mokou: Are you working on a particular module, or the whole kernel?
[19:47:03] <Mokou> i didn't touch userland packages, only modified kernel
[19:47:09] *** mikess <mikess!~mikess@> has joined #illumos
[19:47:14] <Mokou> or be more specific common/inet part
[19:47:54] <Mokou> i know how to bldenv & dmake, but i'm not sure how to build and install kernel only
[19:53:13] *** mikess <mikess!~mikess@> has quit IRC (Quit: leaving)
[19:56:01] <Mokou> ok, lemme try -FniCDmt
[19:56:09] <Mokou> thx for helping
[20:01:41] *** ypankov <ypankov!058afcd3@> has joined #illumos
[20:03:58] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[20:04:45] <Mokou> btw about REUSEPORT
[20:05:45] <Mokou> from my tests and researches, i'm pretty sure linux doesn't do any kind of "un-accept"ing
[20:06:23] <Mokou> they just RST every pending connection in the backlog
[20:09:08] <Mokou> so what's your opinion on that? do you think adopting linux's behaviour is enough for us?
[20:09:27] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[20:10:50] <rmustacc> Mind running the same program on FreeBSD?
[20:11:17] <rmustacc> If that actually is everyone's behavior, it seems like that might be a more reasonable starting point then.
[20:11:25] <rmustacc> Maybe you have some other thoughts there pmooney?
[20:11:27] <Mokou> not at all, but lemme install FreeBSD first :P
[20:12:03] <Mokou> https://bugzilla.redhat.com/show_bug.cgi?id=1203000 from this bug report it seems some BSD does handle the edge case gracefully
[20:13:47] <pmooney> thoughts about exposing an implementation which drops connections on the floor?
[20:14:03] <pmooney> I'm against, unless that's what literally all of the other OSes do
[20:14:10] <pmooney> (and even then, hesitant)
[20:14:14] <rmustacc> pmooney: Yes, given that seems like it may be what others do.
[20:14:27] * pmooney is curious to see how the freebsd test case goes
[20:15:10] * Mokou downloading freebsd iso
[20:16:06] <rmustacc> Thanks for being willing to look at the behavior there.
[20:16:40] <pmooney> I thought I tested that on linux and it didn't drop the connections, but it's been a long time
[20:18:11] <rmustacc> pmooney: Mind looking over the test program that Mokou shared?
[20:18:13] <Mokou> my consideration here is hanlding the situation gracefully might require significant change in current tcp stack implementation
[20:18:47] <Mokou> and i'm not sure what's the performance impact
[20:19:08] <pmooney> performance aside, the modifications would be complicated
[20:19:30] <pmooney> rmustacc: where is the test program?
[20:20:39] <Mokou> https://gist.github.com/AraragiHokuto/068dd21075d14c17f3709ce391ee22cf here's my test server, not sure about correctness tho
[20:21:51] <Mokou> maybe its better to provide some interface, which allow user to notify OS "this socket is going to be closed, so stop dispatching more incoming connection here"?
[20:22:09] <Mokou> and then user can accept all the connection in the backlog, handle it, and close the listener
[20:22:33] <Mokou> i'm not sure adding yet another interface is a good idea tho
[20:22:36] <rmustacc> Well, if we want to create new APIs, then that makes sense. But the challenge we need to balance with it, is that most third-party software will be written without it.
[20:23:06] <rmustacc> When this is present tools like nginx and haproxy will automatically use it when they pick it up during ./configure.
[20:23:09] <Mokou> yes, but that's also true for the "no RST" guarantee
[20:23:25] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[20:24:34] <rmustacc> I think there are a number of different techniques that could make sense for graceful restart without an RST. I'd probably want to survey the existing field. Or see how shutdown(3C) would intersect with that.
[20:24:53] <rmustacc> Though usually it's not used for listen sockets, IIRC.
[20:25:01] <pmooney> yeah, we can't count on existing consumers to do anything extra
[20:25:46] <Mokou> yes, but if we care about only existing consumers, then there's no need for graceful handling
[20:25:55] <Mokou> they'll handle those RSTs on linux anyway
[20:26:02] <LeftWing> It feels like just not sending the RST would at least result in the connecting machine retransmitting its SYN?
[20:26:57] <Mokou> unless they are targeting specific illumos, which they probably won't mind a additional mechanics that doesn't exist on linux
[20:27:33] <Mokou> specifically* an*
[20:27:40] <Mokou> sorry for my english :P
[20:27:48] <pmooney> LeftWing: the sockets in the backlog are already established
[20:27:53] <pmooney> (right?)
[20:28:12] <LeftWing> Mokou: What is your native language?
[20:28:30] <Mokou> mandarin chinese
[20:28:36] <LeftWing> pmooney: I don't think that's true
[20:28:48] <LeftWing> I thought we only established the socket once you accept()ed it
[20:28:58] <LeftWing> Mokou: Your English is 100% better than my Mandarin Chinese!
[20:29:06] <Mokou> thx :P
[20:29:30] <pmooney> LeftWing: It's been a while since I looked at all of this
[20:30:47] <LeftWing> Yeah I could totally be wrong there
[20:31:16] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has quit IRC (Quit: Leaving)
[20:31:32] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has joined #illumos
[20:32:25] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has quit IRC (Remote host closed the connection)
[20:32:41] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has joined #illumos
[20:32:47] <pmooney> We definitely do some things eagerly, up to a point
[20:33:05] <pmooney> It's not just a matter of abstaining from a RST
[20:33:07] <LeftWing> I guess what I might be thinking of is the socket filter that puts us in a second queue
[20:33:12] <LeftWing> waiting for first byte
[20:33:16] <LeftWing> before giving the socket to accept()
[20:33:17] <pmooney> yeah
[20:33:39] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[20:34:40] *** Asgaroth <Asgaroth!~Asgaroth@> has joined #illumos
[20:36:57] *** Asgaroth_ <Asgaroth_!~Asgaroth@> has quit IRC (Ping timeout: 250 seconds)
[20:40:25] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[20:52:38] <Mokou> RST-ed on FreeBSD with my test server
[20:52:59] <Mokou> uname: FreeBSD bsd-vm 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64
[20:53:34] *** wacki <wacki!~wacki@i577B0FB2.versanet.de> has joined #illumos
[20:56:17] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Quit: man_u)
[20:56:35] <Mokou> and somehow FreeBSD is even doing worse than linux
[20:56:57] <Mokou> https://forum.nginx.org/read.php?2,264913,264929
[20:57:01] <Mokou> While SO_REUSEPORT socket option is available on FreeBSD, its
[20:57:01] <Mokou> behaviour is different from one nginx relies on: instead of
[20:57:01] <Mokou> balancing between all sockets as Linux and DragonFly do, it
[20:57:01] <Mokou> preserves historic behaviour for TCP and delivers all connections
[20:57:02] <Mokou> to one socket instead.
[20:57:15] <Mokou> this seems to be still true on my 12.1
[20:57:38] <LeftWing> I suspect they did the expedient thing and adopted an incomplete implementation in order to be source compatible
[20:57:54] <LeftWing> (I'm not really opposed to doing the same thing)
[21:07:11] <toasterson1> The balancing behaviour would be very neat tho :9
[21:07:13] <toasterson1> :)
[21:07:38] <rmustacc> When we have something there, it'd be neat in the future to go and make an option to plug that like the congestion algos.
[21:07:51] <Mokou> ok, so freebsd's attitude seems to be that they believe linux and dragonfly are misusing SO_REUSEPORT for something its not intended for
[21:07:55] <Mokou> https://lists.freebsd.org/pipermail/freebsd-current/2013-December/046931.html
[21:08:34] <Mokou> if i understand that correctly, they are offering a mechanic called PCBGROUP instead of making SO_REUSEPORT load balanced
[21:09:07] <LeftWing> I think they're probably right in that assessment
[21:09:20] <LeftWing> On the other hand, you can't hold back the tide
[21:11:11] <Mokou> i'm the newcomer here so i'll follow your decisions here
[21:16:36] <Mokou> https://reviews.freebsd.org/D11003 or maybe we could adopt this?
[21:16:43] <Mokou> SO_REUSEPORT and SO_REUSEPORT_LB
[21:16:59] <Mokou> seems to be freebsd's decision, later exists on my 12.1 box
[21:17:24] <Mokou> which load balances incoming connections, but still RST on listener close
[21:19:54] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 240 seconds)
[21:20:15] <Mokou> and former can be made to distribute connection only to the last binding, which will enable graceful restart
[21:22:36] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[21:24:44] <Mokou> https://github.com/nginx/nginx/blob/85b44b46fb851fc933e3c053ab2c45e5b92f85c9/src/core/ngx_connection.c#L283 SO_REUSEPORT_LB already utilized by nginx
[21:25:30] *** BOKALDO <BOKALDO!~BOKALDO@> has quit IRC (Quit: Leaving)
[21:29:06] *** wacki <wacki!~wacki@i577B0FB2.versanet.de> has quit IRC (Quit: Lingo: www.lingoirc.com)
[21:46:07] *** ypankov <ypankov!058afcd3@> has quit IRC (Remote host closed the connection)
[21:47:23] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[22:03:37] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 250 seconds)
[22:09:29] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[22:12:02] <gitomat> [illumos-gate] 12357 getc/putc_unlocked need to set orientation -- Robert Mustacchi <rm at fingolfin dot org>
[22:12:03] <gitomat> [illumos-gate] 12358 Need mbrtowc variant that indicates consumed zero bytes -- Robert Mustacchi <rm at fingolfin dot org>
[22:12:04] <gitomat> [illumos-gate] 12359 Want a means to set the umem mtbf at runtine -- Robert Mustacchi <rm at fingolfin dot org>
[22:12:05] <gitomat> [illumos-gate] 7092 Want support for stdio memory streams -- Robert Mustacchi <rm at fingolfin dot org>
[22:12:22] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 256 seconds)
[22:17:28] <tsoome> nice
[22:19:56] <jollyd1> rmustacc: thank you :)
[22:20:59] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[22:25:27] *** ypankov <ypankov!058afcd3@> has joined #illumos
[22:36:39] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[22:45:41] *** ypankov <ypankov!058afcd3@> has quit IRC (Remote host closed the connection)
[22:47:16] *** ypankov <ypankov!058afcd3@> has joined #illumos
[23:02:04] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[23:21:26] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[23:36:36] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Quit: Leaving)
[23:49:11] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos

   March 26, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >