[02:06] This is the nginx config I was goofing around with earlier, if anybody is curious. https://gist.github.com/brycied00d/627ec6c4235405838247 as demonstrated with http://speedtest.brycec.ninja/ and http://speedtest.cobryce.com/ [02:06] Gist: "Abusing Nginx Configuration To Serve And Redirect Multiple Subdomains Under a Variable Domain" [02:07] Wow, 8 hits from IrssiUrlLog [02:07] 4 of them from ipv6 - kudos [02:23] that sounds nifty [02:26] thx [02:27] I'm currently replacing speedtest.net's 5 lines of PHP with another nginx block. Going to optimize the dickens out of this. [02:31] hahaha [02:31] their upload test sucks [02:31] i really wish could easily do a speedtest not using flash [02:31] but i suspect upload may be hard [02:32] actually maybe you can do POST request with javascript created data or something? [02:33] there is an html5 speed test out there [02:34] speedof.me [02:34] (google says there are others too, but that's the one I've used in the past) [02:34] is it any good? [02:34] it's not open soruce is it? [02:34] Seemed good, yeah. Don't think it's open-source or available for self-running [02:35] yeah this seems nice. [02:35] although it seems to be overestimating my upload speed [02:35] uload speed says 10.86 megabit, max upload 22.64 [02:36] but my connection has 10 megabit vdsl sync, so can't do 10 megabit even after overhead. [02:36] I like their graphs and that it downloads larger and larger files until it's "happy" it has a good average. [02:36] yeah it also hilights nicely small vs large files [02:36] Really? Mine's pretty close to spot-on for the upload @ 13mbps [02:36] and ramp up speed etc [02:36] what i don't like is it's testing to sydney which is too close [02:36] (I have 10-15 up, don't remember) [02:36] i like to test more distant locations to measure speed. [02:37] it might be because i usue a local proxy [02:37] so it leaves the computer pretty quick [02:37] I can see how that would skew things :p [02:38] if it's client that says the speed rather than server [02:38] buut yeajh, something like this but open soruce would be great :) [02:38] definitely the right path. [02:38] the last stuff i saw that was html was crap [06:25] mercutio, IPv4/48 are sub-addressable IPs - the smaller they appear to be, the larger they actually are [06:25] grody: what [06:25] seem to have /something/ working here now.. have US and UK working into the backed server [06:25] 23:42 < mercutio> what would a v4 /48 even be [06:26] what's a sub addressab IP? [06:26] sorry. unsubtle physics moment [06:26] like a sub atomic particle [06:26] ahh ok i don't know that stufuf [06:27] i've been wanting to do multiple location stuff since i was a kid [06:27] with accelerating from closer to the user [06:27] i wanted to do it before i had the internet with bbs's :) [06:27] hehe neat [06:28] haven't done much though heh :/ [06:28] i was thinking that things ilke input fields and stuff should be accelerated. [06:28] and done locally [06:28] i doubt this is accelerating per-se [06:28] yeah but you could :) [06:28] it's more redundancy.. albeit there is still a SPOF [06:29] even just using redir command and doing layer 7 redirection accelerates performance [06:29] yaeh [06:29] are you doing ospf or something within your vpn's? [06:29] atm no.. it's all static (which I need to fix) [06:29] the problem with a network over a network is failover times can still suck [06:29] so you need to do bfd or such [06:30] well if you want to create a "more reliable network" [06:30] hm [06:32] i have the servers in a VLAN, which are interconnected via a L2TP LNS (via their respective LACs) and using HAProxy on the internet facing [06:33] i suppose that could work [06:33] did try simple forwards, but had the issue of the server replying out of the wrong route [06:33] the thing is most outages these days are really short [06:33] it's usually ddos with rapid mitigation [06:33] so frequent short outages to some of the net is the common issue [06:34] i have to be grateful for one thing so far.. and touching wood here, i have yet never been dDoSsed massively [06:34] so you need a really frequent heart beat to do better than it [06:34] yea, L2TP isn't the best VPN type to use due to it being a session [06:34] i have but it was a very long time ago [06:34] will be an IPSEC/GRE eventually [06:34] it's cos i logged into efnet [06:34] L2TPv3 would be nice mind [06:34] and someone wanted my nick [06:35] hah [06:35] yeh efnet is a jungle [06:35] i can see why some providers used to say that efnet irc wasn't allowed in particular :) [06:35] they really need bots. [06:35] i used to get "attacked" a lot from Quakenet [06:35] i dunno if efnet is even still going. [06:35] port scans, ping o death attempts, IGMP frag attacks etc [06:36] back when the internet was new you used to be able to ctcp ping +++ATH0 sequence or just put it in a normal icmp ping [06:36] and it'd disconnect users that received it. [06:36] hahaha yea i remember that [06:36] it didn't work with people with usr etc modem. [06:36] but it worked on cheap dynalinks etc. [06:36] was mitigatable using relevent S0=0 (and similar) AT commands modem init [06:36] because they didn't want to pay the fee for the delay [06:37] ahh ok i didn't know that. [06:37] i thought it was amusing [06:37] i don't think all these high bandwidth ddos's these days are though [06:37] i used to get it a lot, then bought a rockwell modem that appeared to specifically address it [06:37] with windows 95 you used to be able to arp flood local machines and lock them up too. [06:38] win98 used to send IGMP fragments and it'd BSOD [06:38] i assume it operated at a high precedence and wasn't very efficient. [06:38] sounds like wifi of today.. push some multicast packets over the air and boom [06:39] it slows to a crawl [06:39] even just using wifi normally can slow it to a crawl. [06:39] there's no protection from one user stealing all the bandwidth normally [06:39] think i only use wifi now on things that have no choice for it [06:40] there's a bit of protectio on the ubiquity etc gear i think. [06:40] i do have a lot of RTP flowing through my net and that reaps havock too [06:40] aye, ubi are epic [06:40] they'd doing fq_codel [06:40] it's good that's starting to catch on. [06:41] ooh [06:41] unifi uap-ac sucks btw. [06:42] i have a couple of the bullets, a 2.4 and a 5 [06:42] for the most part, i seem to get full wifi performance (until my own wireless G joins) [06:42] that thing kills most wifis [06:43] would upgrade that device, but it is the most reliable VoIP phone i have [06:44] aight, i managed to not break anything in that round of mods - i bet you by the time i get to my next destination, something barfs [10:15] *** Alex82 has joined #arpnetworks [10:16] hi [10:22] hi [10:49] hi [10:50] hi [12:42] *** Alex82 has quit IRC (Quit: Leaving) [13:26] nk [13:26] d'oh [13:27] typing in the dark again and i have no idea why i havent turned my lamp on [13:28] "how did you setup pfsense on a VPS with only an internet facing network adaptor" [13:28] ur, well, thats easy.. i remove default route via the VNC access, static route to my trusted IP.. set it up via web browser [13:29] shit some people amaze me [16:01] @weather -v yyz [16:01] Toronto-Pearson International, Ontario: Mostly Cloudy ☁ 73°F (23°C), Humidity: 53%, Wind: From the ESE at 9 MPH, Pressure: 30.09inHg (1019mb) and falling, Dewpoint: 55°F (13°C), Visibility: 15Mi (24km), UV index: 2, Sunrise 05:41, Sunset: 20:50, Lunar phase: Waxing gibbous [16:01] Friday: Partly Cloudy 77°F/65°F (25°C/18°C) | Saturday: Thunderstorm 82°F/49°F (28°C/9°C) | Sunday: Chance of Rain 60°F/46°F (16°C/8°C) | Monday: Chance of Rain 67°F/49°F (19°C/9°C) [16:01] The average high for this date is 65°F (18°C), and the record of 93°F (33°C) was set in 2006. The average low is 48°F (8°C), and the record of 39°F (3°C) was set in 2004 [18:10] hi [18:11] hi [18:11] hi [18:18] hi [18:19] hi [18:20] hi [18:20] hi [18:20] I wish I had a bot right about now who could greet the channel [18:21] hi [18:21] damn you BryceBot [18:22] hi [18:22] hi [18:25] YES [18:25] i started it [18:28] Didn't Alex82 start it 8 hours ago? [18:28] (before grody messed it up) [18:33] haha [19:13] heya [19:42] ... http://www.slate.com/blogs/the_slatest/2015/05/29/california_s_snowpack_now_zero_percent_of_normal_a_worst_case_scenario_for.html [19:43] still waiting for the day when the hotel tells me I can shower only every other day [19:53] heh [19:53] CA lived in denial for a loooong time wrt water and stuff [19:54] From what I understand a lot if people in CA water their gardens too much - but that pales in comparison to agricultural use of water. [19:54] right [19:54] And a lot of the agricultural water use should just be moved to better suited locations. [19:54] and it's all early 20th century style open channel irrigation [19:54] totally irresponsible and stupid [19:54] they're also trying to water a desert [19:54] and they let it go on forever, and now it's like "oh shit, we don't have water" [19:55] RandalSchwartz: right [19:55] i live in the desert, but the water use in my city is roughly 1/3 of the per capita use in LA area [19:55] per-capita is the wrong way to look at things. [19:55] it's to the point that people here conserve enough water that the utility authority has trouble paying for stuff because their revenue is down year after year [19:55] my SSD-based freebsd 10 box on DigitalOcean reboots *so* fast. [19:56] SSD's do seem to help reboot performance a bit. [19:56] ping fail time about 10 seconds. :) [19:56] But IME it's not actually as much difference as you'd think it would be. There are a lot of contributing factors. [19:56] ARP has an in built delay in the BIOS so people can hit with VNC easier. [19:56] true [19:57] I'd like that toggleable myself :) [19:57] but at the end of the day i hardly ever reboot. [19:58] And it definitely is annoying catching console with VNC.. [19:58] It'd be a lot easier if VNC would let you connect before it started booting. [19:58] But if you do a force restart you have to wait until mid way through, then connect. [20:01] heh, yeah... If ARP could start kvm suspended and wait for you to attach to the monitor to resume... [20:02] But in the end, extending the boot delay is probably easier for most users. [20:05] did you see alternative bios for kvm? [20:05] it's meant to speed up boot time a lot, but can only boot linux afaik [20:05] Heard about it, yeah [20:06] it has no vga console even i think [20:07] Yeah I think the kernel parameters are hardcoded. [20:07] but i suspect it should be possible to get down to < 200 msec boot times if you did magic with initialisation [20:07] and basically did copy on write from a pre loaded kernel [20:08] it should be possible doesn't mean easy [20:08] you still have things like disk, startup scripts etc. [20:09] i suspect that some minor things should be able to be taken out of seabios, like floppy support, .. [20:09] and to get some improvement without all the complications [20:10] there were heaps of ideas going around to improve linux boot times before ssd's became common [20:10] with doing things like figuring out what disk blocks would be needed etc. [20:11] changing init handlers of device drivers, doing async init etc. [20:11] but somewhere along the line, it now seems things haven't really got any faster recently [20:56] *** qbit has quit IRC (Ping timeout: 276 seconds) [20:57] *** qbit has joined #arpnetworks [20:57] *** qbit is now known as Guest95138