[00:24] well as an end user it wasn't much work :) [00:25] with windows i'd rather use l2tp/ipsec, but with linux openvpn is easy [00:31] i'm glad it was easy to set up for you :) [01:51] as request some weeks ago: http://support.arpnetworks.com/kb/main/is-there-a-firewall-filter-rate-limit-or-similar-device-applied-to-my-traffic [01:51] *requested [01:51] let me know if anything isn't clear [02:04] I guess I can remove that rule from my rule set. [05:21] *** jpalmer has joined #arpnetworks [05:21] *** jpalmer has quit IRC (Changing host) [05:21] *** jpalmer has joined #arpnetworks [07:49] *** tburke has quit IRC (Read error: Connection reset by peer) [11:08] up_the_irons: your openbsd 5.4 iso on http://mirrors.arpnetworks.com/ISO_Library/ is timestamped before openbsd 5.4 came out? [11:08] by like 4 months [11:09] actually 5.3 is early too. i imagine something has a grossly wrong time somehwere :) [12:38] if the iso timestamp is early, it is because there is a creation of the iso prior to the actual release; media gits burned, factories generate the cd's and stickers, then finally release day arrives. [12:38] the official timestamp of 5.4 is: -rw-r--r-- 1 root wheel 243050496 Jul 30 15:38 5.4/amd64/install54.iso [12:39] so it seems that arpnetworks has simply preserved the timestamp from the mirror site the image was retrieved from [12:54] Yeah, releases get tagged 2-3 months before actual release date. [12:54] A couple weeks for testing, and a few archs take months to build packages. [12:57] VAX... [13:39] toddf: oh real [13:39] that's months prior though? [13:39] i suppose it can take a while to press [13:40] i suppose it's 3 motnhs not four [13:40] i was thinking 7=july, 11=november [13:40] but iot's 30 july to 1st november [13:41] i was also looking at how 5.2 said feb, .. [13:41] but 5.1 is actually more cent than 5.2 [13:41] s/cent/recent/ [13:41] but 5.1 is actually more recent than 5.2 [13:42] oh wow [13:42] s/^o/O/ [13:42] Oh wow [13:43] i had to try that :) [13:47] s/mercutio/Mercutio/ [13:47] so, it's just on the output, not the nick. [14:02] all i did was rsync them, i swear ;) [14:05] yeh [14:05] well toddf's explanation works [14:06] btw up_the_irons have you considered using unbound for recursive dns? [14:07] i have [14:07] i assume it'd be one more thing to maintain [14:07] cos you'd have to keep resolving working with the old dns with people using that currently. [14:08] in fact, unbound *is* running on 208.79.88.9 [14:08] oh? [14:08] actually you don't host dns for people do you? [14:08] so i suppose you could remap your authorative [14:08] hmm i was using .7 [14:08] i'm not atm for some reason [14:09] oh, 89.9 is the secondary normally? [14:10] oh, nah it does say 88.9 [14:10] i'd just looked at host -t ns arpnetworks.com not close enough [14:11] hmm, 88.9 resolves to ns2 which resolves to 89.9 [14:14] and 88.7 appaers to be faster than 88.9, probably cos most people using primary [15:51] just run your own locally ;) [16:03] *** ThalinVien has quit IRC (Quit: leaving) [16:07] i haven't run my own recursive or authoritative ns' in years [16:07] m0unds: :( [16:07] missing out [16:07] nah [16:07] i think authorative is more important to run yourself than recursive [16:08] recursive you can just cache locally if you do lots of dns [16:08] yeah, recursive if you're an ISP or have lots of machines in one place [16:08] i like to pretend fairies answer queries and never give it a second thought [16:08] and authoratative if you need control of your zone [16:08] recursive if you have more than one transit provider [16:08] is more where i'd say it starts [16:08] whether or not isp [16:09] well, multiple recursive :) [16:09] i don't reckon wireless isp's need their own recursive dns rather than just cache if they are single-homed. [16:09] well single-homed transit, with peering recursive still good. [16:10] I've seen ISPs go horribly wrong when they have split upstreams and their recursive server on a different upstream to their customers [16:10] TBH I think everyone should run their own recursive [16:10] what do you mean a different upstream? [16:10] so say you have business customers and resi customers [16:11] and a cheap upstream and a more reliable upstream [16:11] do you mean having non PI space and having some IP on one transit provider, and the other on another transit provider? [16:11] shove business customers on the reliable one falling back to the cheap one [16:11] and visa versa [16:11] so PI space, right. [16:11] and you get to use the bandwidth on both transits [16:11] or at least dual advertising [16:11] yip [16:11] yeah [16:11] google does some really funky stuff when you mess that up [16:12] oh right i get yah [16:12] you mean like it'll push stuff over one provider or the other [16:12] but the DNS picks something for the other isp [16:12] and then the route sucks for the other isp? [16:12] yeah so, all the google CDN stuff is based on the IP it thinks the resolver is coming from [16:12] i think that's generally not too bad as long as you send outgoing via the best path [16:13] as google will choose an isp that's good for the connecting IP [16:13] so when you do a lookup to google.com the CDN goes, alright you have a GGC node at X IP nearby and returns that [16:13] and then you try connect to that IP from the client machine, and the GGC goes, hold on you're not using my transit [16:13] yeah you have to dual advertise routes at least [16:13] and falls you back [16:13] yaeh, that's why you need a dual advertiseement [16:13] yeah [16:13] even if you have like much longer as-path~ length [16:13] yup [16:13] it'll still let you use it [16:14] at least from what i've seen [16:14] you can actually use other isp's to transit to upstream ggc [16:14] mmm, but it would have been far more efficient to use the GGC node on the upstream you're connected to :) [16:14] on the alternate transit provider and it'll work [16:14] no, not really [16:14] cos generlaly speaking it'll still come down the transit provider that you're connecrted to [16:14] 's link [16:15] because most tarnsit providers will prefer transit routes over learned routes [16:15] but [16:15] it'll suck from a load balancing point of view [16:15] the GGC cache stuff is nasty anyway :/ [16:15] also depends on how you're doing your forward routes [16:15] problem is it's so much traffic [16:15] so it matters. [16:15] yeah, I notice a fault on GGC about once a week :/ [16:15] yeah i'd advocate doing best path forward path regardless. [16:16] I've got some fantastic graphs if you give me one second [16:16] graphmaster gizmoguy [16:16] 1 .. 2 .. 3 [16:16] google have been recently sending us to pretty much the furthest location in their network [16:17] i've had that issue [16:17] it was amsterdam [16:17] second class citizens [16:17] oh look yay [16:17] and only on some videos [16:17] they're doing it again today [16:17] http://amp.wand.net.nz/graph/rrd-smokeping/23235/1384215383/1384388183 [16:17] i'm in new zealand [16:17] oh hai [16:17] oh so are you? [16:17] me too :) [16:17] was it amsterdam? [16:17] google wouldn't tell me [16:17] and I couldnt' work out from traceroutes [16:17] oh that doesn't really tell you where you're going [16:17] necessarily [16:18] but the biggest spike I see on the graph is 600ms [16:18] do your videos actually go to there? [16:18] oh [16:18] actually [16:18] I don't really care about that [16:18] that shows me local [16:18] (not an ISP :)) [16:18] if you look at tcpdupm or such when viewing videos [16:18] and trace to those ip's [16:18] it can be kind of random where it sends you [16:18] yeah for sure [16:18] when I send those graphs to google [16:18] but i've seen that go to amsterdam [16:19] and the IPs we were hitting [16:19] via australia [16:19] they said I couldn't have got much further down their network [16:19] with horrible route [16:19] :) [16:19] yeah GGC is an interesting beast [16:19] do you host a GGC box? [16:19] nope [16:19] ah yup [16:19] i work for small isp [16:19] don't have ggc [16:19] sweet, where 'bouts in NZ? [16:19] but have dual upstreams [16:19] i'm in auckland [16:19] ah cool [16:19] not too far from me [16:20] hamiltron here [16:20] (small world) [16:20] heh [16:20] i was from chch [16:20] but moved after the earthquakes [16:20] fair enough [16:20] i haven't actually had youtube performance issues recently [16:20] what was wrong with old zealand? [16:20] hey what [16:21] http://www.youtube.com/my_speed [16:21] check out global on that [16:21] m0unds: i think it's in the netherlands actually [16:21] http://en.wikipedia.org/wiki/Zeeland [16:21] Zeeland :: Zeeland (Dutch pronunciation: [ˈzeːlɑnt] ( listen), Zeelandic: Zeêland), also called Zealand in English, is the westernmost province of the Netherlands. The province, located in the south-west of the country, consists of a number of islands (hence its name, meaning "sea-land") and a strip bordering Belgium. Its capital is Middelburg. With a population of about 380,000, its area is about 2,930 km², of which almost 1,140... [16:21] hamilton representing at 6.99mbit [16:21] gizmoguy: look at the global grpah though [16:21] the grey line [16:21] large spike? [16:21] lol at google thinking im in Ottawa [16:22] yeah [16:22] upwards [16:22] interesting [16:22] i wonder what google did [16:22] then look at the new zelanad graph [16:22] so it's not new zeealand boosting the global speeds. [16:22] it seems to be geteting worse not better [16:22] why [16:22] are the averge speeds [16:23] showing a time related trend [16:23] weird dutch [16:23] google have said it's higher in weekends [16:23] err lower in weekdns [16:23] i can't remember which [16:23] lower speed? [16:23] something about people having faster or slower net at home/work [16:23] interesting [16:23] i can't rembmer now [16:23] ah, facinating [16:23] it probably varies by country if people have faster net at work or home [16:23] my work tubez a lot faster than my home tubez [16:23] in korea i imagine it's faster at home for instance [16:23] cos fibre so common [16:24] I'm still failing in my quest to get 10gig to my desk [16:24] but probably "shared" connectino at work and non shared at home [16:24] i have infiniband [16:24] gizmoguy: gotta work harder at it [16:24] hah! [16:24] nice [16:24] giving > 10 gigabit [16:24] it's cheap [16:24] do it [16:24] I got close to 10gig at my desk [16:24] it's not 10 gigabit internet though :/ [16:24] found some spare fibre pairs [16:24] found a 10gig internet provider [16:24] i got nowhere near 10gig anywhere near me [16:24] it does like 1.4 gigabytes/sec nfs [16:24] just needed to run some patch leads and buy an optic [16:24] well, i guess i could walk in the other room and look at 10gig interconnects but meh [16:25] hahaha [16:25] but I got lazy [16:25] gizmoguy: 10 gigabit international in new zealand? [16:25] only 1 gig international :( [16:25] going up soon [16:25] i've found it interesting looking at peoples expectations of international performance in new zelaand. [16:26] it wasn't that long ago people were happy with 2 megabit/sec international [16:26] which i thought was a bit off but hey [16:26] but as you start going up you end up getting less and less improvement [16:27] but like with UFB coming etc [16:27] theyl'l soon figure out that single threaded 100 megabit isn't really likely to work out that often [16:27] to anywhere furhter than australia [16:28] well 1 gig to states 1 gig to syd [16:28] though that's going up shortly [16:28] hell, i was only getting 100 megabit between chicago and arp [16:28] both on gigabit [16:28] UFB will be interesting to see rolled out [16:28] i don't know anyone with ufb yet [16:29] you're in the UFF area right? [16:29] hamilton/tauranga/christchurch are so far ahead of the rest of the country in UFB [16:29] yeah [16:29] I work closely with two UFF RSPs [16:29] one in hamilton one in tauranga [16:29] ahh ok. [16:29] what do you think of UFF? [16:29] in waikato we actually have 2 cities fully rolled out with fibre [16:29] UFF are the worst [16:29] my area of auckalnd isn't in the UFB thing [16:29] they contract out everything [16:29] but there's fibre on my street [16:29] huawei build the network [16:30] what latency you been seeing? [16:30] they contract out to another company to oversee the design of the network [16:30] latency is pretty good [16:30] is it getting under 1 msec yet? [16:30] no way [16:30] well [16:30] i was seeing 1.5 [16:30] huawei, oh boy [16:30] I haven't tested [16:30] with someone i know [16:30] but they don't have fibre to their house [16:30] actually they're not in a ufb area either [16:31] it's meant to be about 80% of new zealand isn't it? [16:31] the fun ones with UFF [16:31] are the funky ways they handle their vlans across the network [16:31] m0unds: huawei is big in nz [16:31] sort of [16:31] oh i read something about that gizmo [16:31] i got confused. [16:31] yeah [16:32] it's using lots of huawei technologies [16:33] big because of cost, or because of some other factor? [16:33] just curious - the guys i know who have had to work with huawei gear hated it [16:34] cost probably [16:34] does NZ have import taxes on stuff? [16:34] yup [16:34] *** ThalinVien has joined #arpnetworks [16:35] does it depend on hw cost or where it's imported from? [16:35] m0unds: new zealand is cheap too [16:35] m0unds: hw cost i think [16:35] ah, ok [16:43] internet is expensive in new zealand [16:45] here's another good graph mercutio [16:45] http://wand.net.nz/smokeping/?displaymode=n;start=2013-11-04%2013:44;end=now;target=Off-net.google [16:46] google.com likes to move around a lot [16:46] which is strange considering we have 2 GGC nodes upstream of us [16:46] gah i give up :) [16:46] ~30ms away is SYD, and ~50ms away is japan [16:46] on trying to find email [16:46] haha no worries [16:46] email is hard [16:46] * mercutio makes mental note to organise his email better [16:47] uhh [16:47] is that frmo christchurch? [16:47] nah, hamilton [16:47] 50 msec seems rather high to google [16:47] yes, yes it does [16:47] we get taken to japan sometimes [16:47] i wonder if it's going to melbourne [16:47] yeah i seen that before [16:48] i have seen apple.com go to malaysia too [16:48] do you work in hamilton uni? [16:48] I don't even bother tracking that one :) [16:48] yeah, I'm at the network research group at waikato uni [16:48] ahh cool. [16:48] i thought it was interesting that hamilton had network reserach stuff going on [16:49] i want to do a bit of research myself in a way :) [16:49] mmm we do a lot of random stuff [16:49] which is quite fun [16:49] cool. [16:49] doing a heap of openflow/SDN stuff right now [16:49] you know how there's a standard for specifying maximum link bandwidth in a path? [16:49] but every hop would have to be able to diminish the bandwidth if necessary? [16:49] so it needs router support so it went nowehere [16:50] as do most standards [16:50] err proposed standrad i think [16:50] well, IETF drafts I should say :) [16:50] i want to know how much benefit that has in the real world. [16:50] does PMTUD not do enough for you? [16:50] cos like on adsl connections, if you get the transmitting host to rate limit [16:50] single threaded throughput can often be significantly higher internationally. [16:50] it's not about mtu [16:50] it's about not overflowing buffers/queues. [16:51] Ohh right [16:51] in between [16:51] and losing heaps of packets. [16:51] sorry with you now [16:51] and then having to retransmit. [16:51] so like if you have a 20 megabit dsl connection [16:51] 20 emgabit sync rate [16:51] and do single threadd download, you'll probably only get 10 megabit [16:51] but if you cap the speed at 16 megabit you'll probagbly get 12 megabit [16:52] if you increase the download size, then it matters less in a way [16:52] because tcp/ip adapts. [16:52] but lots of downloads are small [16:52] and cubic is pretty good at ramping up [16:52] and tbh i care more about the speed of downloading 10mb than 200mb normally [16:52] generally speaking for smaller downloads i'm more likely to be wanting it "now" and larger ones i can go make coffee or whatever [16:53] yeah, tcp is fun times [16:53] gah [16:53] a general protocol meant to support speeds of 1k up to 100s of gbit [16:53] so i try downloading my 10mb file from arp and it's going slow atm [16:53] well cubic is pretty good [16:54] TCP slow start \o/ [16:54] fwiw i downtune for infiniband [16:54] the same way i downtune for gigabit [16:54] like i set my maxium window sizes down [16:54] and for some reason something's been going around for a while advocating massive window sizes [16:54] and saying that tcp/ip will deal [16:54] but often it actually diminishes performance being set too high [16:55] static: well cubic takes over with slow start [16:55] o [16:55] and actually works pretty well [16:55] basically it looks at time between packets [16:55] and uhh [16:55] something else [16:55] i don't think it's simple packet pairs though [16:56] but it's not ack 16 times 32 more packets. [16:56] oh, also, linux is sneaky, and acks every packet for short connections. [16:56] for the first 16 packets. [16:57] SACK helps out a lot [16:57] sack doesn't end up acking enough packets. [16:57] for my liking [16:58] wireless throughput is limited with tcp versus udp quite significantly. [16:58] because wireless is half duplex. [16:58] wireless is the worst :) [16:58] yeah but wireless also buffers randomly etc [16:58] not showing it to the applications [16:58] or giving feedback [16:58] speaking as someone who used to work for a company that build embedded wireless devices [16:58] s/build/built [16:58] so if it's going to do that anyway, you may as well just throw more packets at it, and not worry about having the acks in a timely fashion [16:58] speaking as someone who used to work for a company that built embedded wireless devices [16:58] closely synced. [16:59] and you may as well ack less often [16:59] mercutio: got a masters student working on 802.11ad at the moment [16:59] that stuff is funky [16:59] "WiGig" [16:59] what's 802.11ad? [16:59] is it like ac but better? [16:59] 60ghz wireless [16:59] ahh ok [16:59] does it use more forward error correction? [17:00] it gets most of it's awesome from beam forming [17:00] ahh [17:00] it's only built for short lengths [17:00] i thought that was just a buzzword [17:00] like in a room for example [17:00] that wasn't really significantly implemented [17:00] so with wigig [17:00] you usually have an antenna array [17:00] like all around your device? [17:00] and then with phase shifting your array you can point/focus the 60ghz more closely to your device [17:01] you can make a flat square one I believe [17:01] wat happens if you have a wireless 802.11ad ball [17:01] and you throw it around the room [17:01] I suspect it doesn't work very well [17:01] it's more for stationary devices [17:01]