| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| *** | sga0_ has quit IRC (Read error: Connection reset by peer) | [03:30] | |
| .................................. (idle for 2h48mn) | |||
| sga0 has joined #arpnetworks | [06:18] | ||
| .................................................... (idle for 4h16mn) | |||
| xales has joined #arpnetworks | [10:34] | ||
| ................ (idle for 1h15mn) | |||
| sga0_ has joined #arpnetworks
sga0 has quit IRC (Ping timeout: 246 seconds) medum has quit IRC (Ping timeout: 246 seconds) medum has joined #arpnetworks | [11:49] | ||
| .............. (idle for 1h9mn) | |||
| SpaceDum1 has quit IRC (Ping timeout: 255 seconds)
SpaceDump has joined #arpnetworks | [13:08] | ||
| mercutio | quiet in here. | [13:11] | |
| RandalSchwartz | "yeah... a little TOO quiet" | [13:13] | |
| mercutio | :) | [13:17] | |
| *** | SpaceDump has quit IRC (Ping timeout: 244 seconds)
SpaceDump has joined #arpnetworks | [13:19] | |
| ................ (idle for 1h16mn) | |||
| mnathani | BryceBot: yes | [14:36] | |
| BryceBot | Okay! twss! ':)' | [14:36] | |
| mercutio | :)
hmm? i dunno how brycebot works | [14:41] | |
| mnathani | @google nexus 6 | [14:51] | |
| BryceBot | 1,260,000 total results returned for 'nexus 6', here's 3
Nexus 5 (16GB, Black) - Devices on Google Play (https://play.google.com/store/devices/details/Nexus_5_16GB_Black?id=nexus_5_black_16gb&hl=en) Real life doesn't fit in 4” x 6”, so Nexus 5 comes with Photo Sphere. Create the effect of an immersive 360° view that no traditional camera can match. When you ... Motorola Nexus 6 - Full phone specifications (http://www.gsmarena.com/motorola_nexus_6-6604.php) Motorola Nexus 6 Android smartphone. Announced 2014, October. Features 3G, 5.96″ AMOLED capacitive touchscreen, 13 MP camera, Wi-Fi, GPS, Bluetooth. | [14:51] | |
| mnathani | 1440 x 2560 pixels, 5.96 inches (~493 ppi pixel density) | [14:52] | |
| BryceBot | That's what she said!! | [14:52] | |
| mnathani | BryceBot: no | [14:52] | |
| BryceBot | Oh, okay... I'm sorry. '1440 x 2560 pixels, 5.96 inches (~493 ppi pixel density)' | [14:52] | |
| brycec | mercutio (and mnathani): It's bayesian learning
:) twss? | [14:57] | |
| BryceBot | That was 50% what she said. ':)' | [14:57] | |
| brycec | I love when it's hard
twss? | [14:58] | |
| BryceBot | That was 92.63% what she said. 'I love when it's hard' | [14:58] | |
| brycec | twss | [14:58] | |
| BryceBot | Okay! twss! 'I love when it's hard' | [14:58] | |
| brycec | twss? | [14:58] | |
| BryceBot | That was 92.77% what she said. 'I love when it's hard' | [14:58] | |
| mercutio | Bryce: i meant how to trigger it
the new samsung 840 evo firmware update is out. | [15:00] | |
| brycec | Say something >97%
(or is it 96?) | [15:00] | |
| mercutio | i wish samsung made updates easy on linux. | [15:01] | |
| staticsafe | mercutio: ooh thanks for the reminder
lol their software tells me I have the latest firmware | [15:03] | |
| mercutio | static: it's only in the performance restoration tool atm
which takes ages to run, i'm running it on my windows box atm. it rewrites all teh data or something, but it needs available space, so it's doing some remap or something. | [15:07] | |
| staticsafe | :o | [15:08] | |
| mercutio | magician wasn't showing me the update either, but it may be some caching thing. | [15:08] | |
| staticsafe | yeah | [15:08] | |
| mercutio | i'm wondering if linux will like me running the restoration tool plugged into windows box.
i hate having to use the windows box to do firmware updates. i really wish they'd add linux support. i'm using mdadm/zfs. so i'm wondering if i can get a firmware update done, and kill the drive readd. mdadm means you can just unplug the drive and it'll rewrite everything, but zfs is more intelligent than that. also their progress bar sucks. it got to 80% pretty quick, and then it's been between 80 and 86% for longer than it was up to 80% but oh well somehow should be resolvable. it was kind of disconcerting when i used to get 1gb/sec then it went down to less than 200mb/sec | [15:09] | |
| staticsafe | ah i have two EVO drives in separate machines, no RAID
its gonna be annoying to update the one in the NUC | [15:14] | |
| mercutio | there's actually an iso boot thingy.
which runs dos and so on. which you can probably get going on a usb stick. | [15:14] | |
| staticsafe | yeah | [15:14] | |
| mercutio | i just thought that may be more problematic than stickign in windows box.
maybe i should try that. they're not even listing the new firmware other than restoration tool on their site yet though http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/support/downloads.html under performance restoration is what i used oh that's not even on iso i dunno if raid on ssd is overkill, but one of them has been dropping out of array occassionally, and it's the same one. i was running swap striped rather than on raid, and linux really doesn't like it when swap is unavailable. but it doesn't actually crash, just applications crash. 89% so i imagine update is on the over an hour side | [15:15] | |
| mnathani | mercutio: I dont see the update on ther website
Samsung 840 EVO that is | [15:33] | |
| mercutio | under firmware restoration till it lists the firmware
oh sweet it finished now what | [15:34] | |
| .......................... (idle for 2h9mn) | |||
| *** | dj_goku has quit IRC (Remote host closed the connection) | [17:44] | |
| mnathani | If you are trying to establish an Internet connection using BGP, what kind of interconnect between the providers must first be present? | [17:50] | |
| brycec | Any sort of IP interconnect
Typically RFC1918 (because why waste public addresses and possible routing headaches) | [17:52] | |
| mnathani | would those RFC1918 ever show up in traceroutes? | [17:54] | |
| brycec | Yes
You can see a 10. address tracerouting out of ARP sometimes | [17:54] | |
| mnathani | thats the OpenBSD box, correct? | [17:54] | |
| brycec | 2 s7.lax.arpnetworks.com (208.79.88.135) 1.385 ms 1.359 ms 1.334 ms
3 10.10.10.6 (10.10.10.6) 1.273 ms 1.264 ms 1.244 ms 4 any2ix.coresite.com (206.72.210.41) 1.232 ms 1.576 ms 1.756 ms That's in the peering with any2ix unrelated to the OpenBSD box | [17:55] | |
| mnathani | so the any2 side would also have an RFC1918 within that same segment as the 10. | [17:56] | |
| brycec | or that is the any2ix side, but you get the idea
While I'm no expert ( up_the_irons would be best person to explain ARP's routing)... basically s7 has a bunch of interfaces, one for each interconnect peer, each interface has a private address and a route to the upstream peer's router | [17:56] | |
| mnathani | fiber I would assume? | [17:57] | |
| up_the_irons | mnathani: no, the 10.10.10.5/30 is between s7.lax and r1.lax (which is the .6) | [17:58] | |
| brycec | (my bad, sorry) | [17:58] | |
| up_the_irons | no worries brycec | [17:58] | |
| brycec | I'd assume copper, since 10GbE copper is pretty cheap. But I'm just guesing
*guessing | [17:58] | |
| up_the_irons | it's r1.lax that carries all the peer traffic | [17:59] | |
| mnathani | I remember seeing flickr images of fiber runs | [17:59] | |
| up_the_irons | yes, data center porn | [17:59] | |
| brycec | <3 data centre porn | [17:59] | |
| mnathani | who doesnt? | [17:59] | |
| up_the_irons | better than real porn
sometimes | [17:59] | |
| brycec | Most spouses, for starters :p
lol up_the_irons | [18:00] | |
| up_the_irons | ;) | [18:00] | |
| mnathani | so do ARP <> other Transit, or Peers BGP go over RFC1918 Address Space? | [18:01] | |
| mercutio | hardly aanyone uses rfc1918 space to reach others.
as it means that traceroutes don't show people usually block responses from rfc1918 addresses into their own network | [18:01] | |
| up_the_irons | no, i just have a couple RFC1918 addresses between our own equipment (why waste a perfectly good public /30? ;) | [18:02] | |
| brycec | (oh I was totally wrong, my bad) | [18:02] | |
| mercutio | up_the_irons: for pretty traceroutes! | [18:02] | |
| up_the_irons | indeed, it *does* make the traceroutes better | [18:02] | |
| mnathani | brycec: np | [18:02] | |
| mercutio | it's normal to use /30s to interconnect to other providers, but it can vary who's ip address space is used.
some people alternate. some people assume the other end can't maintain reverse lookups properly so just decide to use their own ip's. | [18:02] | |
| mnathani | I guess it depends on who wants mroe control over PTR records
s/mroe/more | [18:03] | |
| BryceBot | <mnathani> I guess it depends on who wants more control over PTR records | [18:03] | |
| up_the_irons | mnathani: all my transits and peers do not use rfc1918 address space | [18:03] | |
| mercutio | mnathani: you can delegate sometimes too
but yeah, it varies a bit | [18:03] | |
| brycec | s/who's/whose/ | [18:04] | |
| BryceBot | <mercutio> it's normal to use /30s to interconnect to other providers, but it can vary whose ip address space is used. | [18:04] | |
| mercutio | up_the_irons: are you 129.250.198.185 for connecting to ntt?
it can be hard to tell sometimes which ip hits inside the network | [18:04] | |
| up_the_irons | mercutio: yes
129.250.198.185 is their side | [18:05] | |
| mercutio | so yaeh, that in itself is weird. | [18:05] | |
| up_the_irons | 129.250.198.186 is mine | [18:05] | |
| BryceBot | That's what she said!! | [18:05] | |
| mercutio | oh
i thought it was other way around but yeah that makes sense. | [18:05] | |
| up_the_irons | usually the provider has the lower number | [18:06] | |
| mercutio | so yeah that looks like ntt ip
up_the_irons: yeah. but sometimes it's the other way around | [18:06] | |
| up_the_irons | sometimes | [18:06] | |
| mercutio | i used to always use 192.168.1.254 as a gateway address on home networks
then i found everyone using 192.168.1.1 i usually use gateway high, but some people usually use gateway low. | [18:06] | |
| brycec | I use .254 for that very reason :D | [18:07] | |
| mnathani | my home network is a /16 with gw at 10.10.10.10 | [18:07] | |
| mercutio | heh. | [18:07] | |
| brycec | Because idiots may bring a .1 onto the network and risk fucking shit up | [18:07] | |
| mercutio | well i have a /29 with high too | [18:07] | |
| brycec | Or just to avoid bad programs that assume a gateway at .1 | [18:07] | |
| mercutio | i've actually got 192.168.1.13 as my gateway atm
bryce.. or sensible people may bring an adsl modem onto the network or such | [18:07] | |
| brycec | .251 and .252 are my gateways, with .254 as the carp'd address :D | [18:08] | |
| mercutio | and want to reconfigure it | [18:08] | |
| brycec | mercutio: There is that too sometimes, lol | [18:08] | |
| mercutio | when using dhcp it doesn't really matter what the address is | [18:08] | |
| brycec | Indeed, indeed. | [18:09] | |
| mercutio | speaking of annoying things, why does coresite show all of it's hosts with the same dns name | [18:09] | |
| brycec | s/it's/its/ | [18:10] | |
| BryceBot | <mercutio> speaking of annoying things, why does coresite show all of its hosts with the same dns name | [18:10] | |
| mercutio | heh | [18:10] | |
| brycec | (speaking of annoying things :P) | [18:10] | |
| mnathani | mercutio: How is the ARP lg coming along? | [18:10] | |
| BryceBot | That's what she said!! | [18:10] | |
| brycec | twss? | [18:10] | |
| mercutio | i was thinking possessive. | [18:10] | |
| mnathani | BryceBot: no | [18:10] | |
| BryceBot | That was 96.82% what she said. 'mercutio: How is the ARP lg coming along?'
Oh, okay... I'm sorry. 'mercutio: How is the ARP lg coming along?' | [18:10] | |
| mercutio | mnathani: it's working, but incomplete. | [18:10] | |
| brycec | mercutio: you were thinking it, but you didn't write the possessive form
What, why isn't that something "she" would say? :P | [18:11] | |
| mercutio | brycec: my typing/thinking/whatever is pretty messy sometimes :) | [18:11] | |
| up_the_irons | mnathani: we have r1.lax and s7.lax routes in the lg, still need to hook up s1.lax and ipv6 (s3.lax) | [18:12] | |
| mnathani | k, cool | [18:12] | |
| mercutio | is anyone from canada in here? | [18:16] | |
| mnathani | yup | [18:16] | |
| mercutio | ahh. | [18:16] | |
| brycec | i'm canadian... not technically from canada though | [18:16] | |
| up_the_irons | lol | [18:16] | |
| mnathani | If you are wondering *.*.149.228 is me | [18:17] | |
| mercutio | heh
yeah figured was going to see if anyone figured out where it was. | [18:17] | |
| mnathani | will it eventually get the wildcard ARP SSL Cert? | [18:18] | |
| mercutio | probably not?
i wouldn't myself. | [18:18] | |
| BryceBot | That's what she said!! | [18:18] | |
| mercutio | as it's another place for the ssl cert security to leak.
and it really shouldn't need to be encrypted. and if proxypassing for it, then it would rely on web server working. and looking glasses can be handy wehn things are semi-broken. what do you thinko of it mnathani ? | [18:18] | |
| mnathani | Its quick
compared to other looking glasses | [18:20] | |
| mercutio | yeah that's what i thought | [18:21] | |
| mnathani | but I guess that cos theres no traffic hitting it really | [18:21] | |
| mercutio | also cos it's not using perl
it's c code | [18:21] | |
| mnathani | and BGP sessions to the VPS
right rather than forward queries to a router | [18:21] | |
| mercutio | yeah actually quagga is so much quicker than ciscso
for route servers for the ones with telnet | [18:21] | |
| mnathani | this one wont support telnet will it? | [18:22] | |
| mercutio | i don't think so
that would be pretty cool surprised that bryce didn't pipe up | [18:24] | |
| BryceBot | That's what she said!! | [18:27] | |
| brycec | I didn't? | [18:27] | |
| mercutio | and try the looking glass. | [18:27] | |
| brycec | mercutio: Why am I piping up here?
Is the lg up yet? | [18:27] | |
| mercutio | mnathani found it :) | [18:28] | |
| brycec | And if so, what's the address?
lol | [18:28] | |
| mercutio | guess :) | [18:28] | |
| brycec | brycec found it too
Ewww why is this ipv4 only? | [18:28] | |
| mercutio | haha | [18:28] | |
| brycec | Guess that explains why my cmd=ping6 failed | [18:29] | |
| mercutio | it won't be ipv4 only for long
i knew someone would complain about ipv4 only hah | [18:29] | |
| up_the_irons | we haven't hooked up ipv6 yet | [18:29] | |
| brycec | brycec is the preeminent complainer about lack of ipv6 | [18:29] | |
| mercutio | hmm i reckon icmp traceroute would be better | [18:31] | |
| mnathani | I wonder why show ip bgp as doesnt work for AS25795 | [18:33] | |
| brycec | I wonder why a traceroute to 174.136.103.130 fails miserably
(my arp vps) | [18:34] | |
| mercutio | i don't think 25795 advertisements are included atm
i think UDP trace being blocked. yeah you're blocking udp traceroute and icmp traceroute works i wonder if it's easy to change that | [18:34] | |
| brycec | Am I? Hm | [18:35] | |
| mercutio | lots of people do | [18:35] | |
| brycec | I can traceroute and traceroute -I from home just fine | [18:35] | |
| mercutio | you may have an allow on from your ip? | [18:36] | |
| brycec | Oh wait, my home IP is whitelisted, lol | [18:36] | |
| mercutio | yeah | [18:36] | |
| mnathani | could have something to do with s1.lax not hooked up yet | [18:36] | |
| mercutio | bgplg.h: { TRACEROUTE, "-ASl", NULL } }, [18:36] <brycec> IN=eth0 OUT= MAC=52:54:00:27:23:74:00:0d:65:ab:c8:bf:08:00 SRC=208.79.88.163 DST=174.136.103.130 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=36118 PROTO=UDP SPT=36114 DPT=33438 LEN=20 | [18:36] | |
| brycec | (blocked packet)
Sorry for the false alarm :) | [18:37] | |
| mercutio | hah no write permissions
try now | [18:37] | |
| brycec | bam worked | [18:41] | |
| mercutio | yeah i modified the code | [18:41] | |
| brycec | YOU HACKER | [18:41] | |
| mercutio | jsut to add -I in
it's beter overall. i did it for traceroute6 too but can't tes tthat. | [18:41] | |
| brycec | lol how the first hop has higher latency than my VPS | [18:42] | |
| mercutio | yeah cisco | [18:42] | |
| brycec | mercutio: you could use ::1 :P | [18:42] | |
| mercutio | ::1 will work with or without icmp
www.arpnetworks.com has the same issue but it seems to work with and without -I on ipv6 what's your hostname bryce? | [18:42] | |
| brycec | vps3.cobryce.com | [18:46] | |
| mercutio | yeah -I fixes it for ipv6 too | [18:46] | |
| brycec | brycec notes some ipv6 hits | [18:47] | |
| mercutio | so should be good to go | [18:47] | |
| brycec | twss | [18:49] | |
| BryceBot | Okay! twss! 'so should be good to go' | [18:49] | |
| mercutio | y'know, the traceroute updates bit by bit so much better than most of the looking glasses.
most show huge chunks of information, but it basically shows things as they're happening | [18:51] | |
| mnathani | whats a query I can request to show all prefixes originating from a certain AS ? | [18:54] | |
| mercutio | source-as
i wonder if the timeout should be bumped up too for hops that don't respond | [18:54] | |
| mnathani | cool, crazy fast response | [18:55] | |
| mercutio | i'd kind of like to see mtr added. | [18:55] | |
| brycec | Winter is coming, it's getting colder... Time to start using more monitors (which happen to put off a good chunk of heat) :D | [18:55] | |
| mercutio | heh my pva monitor gets so hot
but newer ones don't really use that much power | [18:55] | |
| brycec | Mine don't use that much power, but there's still plenty of heat from them. IR therm reads around 100F on the screen surface | [18:57] | |
| mercutio | my dehumidifier warms my room up a little.
i was using heater a bit before, but dehumidifer actually seems more useful to me. | [18:59] | |
| brycec | heh
I avoid running a heater at all costs | [19:00] | |
| mercutio | for cost reasons? :) | [19:01] | |
| brycec | Feels like I've lost the battle
mercutio: Hmmm more like principle I have all this tech that puts of heat | [19:01] | |
| mercutio | i used to never use heaters. | [19:01] | |
| brycec | I should be able to stay warm by it | [19:01] | |
| mercutio | i'd even sleep with the window open in winter.
but my health seems to prefer having some heat now days. | [19:01] | |
| brycec | I did that back when I lived in AZ... | [19:01] | |
| mercutio | and to me health is more important than principle :)
cos it sucks being sick. | [19:02] | |
| brycec | brycec doesn't get sick easily, much less from the cold | [19:03] | |
| mercutio | apparently original reasons for using udp rather than icmp for traceroute was about icmp needing higher privileges on unix
brycec: i was like that too! damnit, why can't i be like that again. | [19:03] | |
| brycec | Because you're an old man now? | [19:04] | |
| mercutio | actually i think for me it's more about wet and cold together. and i'm in a wetter place.
like dry cold doesn't phase me as much | [19:04] | |
| .... (idle for 15mn) | |||
| mnathani | why do some routes look like: I 202.28.12.0/24 208.79.88.135 100 289 2914 4651 7470 7470 7470 7470 7470 58806 58806 58806 58806 58806 58806 58806 i | [19:19] | |
| mercutio | uhh
i'll lookup that route it doesn't paste well :) you mean with so many damn prepends? | [19:19] | |
| mnathani | yes, the prepends | [19:20] | |
| mercutio | well it's just as basd here
flags destination gateway lpref med aspath origin I*> 202.28.12.0/24 202.49.71.55 100 0 17746 17746 4610 4826 38082 7470 58806 58806 58806 58806 58806 58806 58806 i * 202.28.12.0/24 202.49.70.165 100 0 23655 23655 4648 2914 4651 7470 7470 7470 7470 7470 58806 58806 58806 58806 58806 58806 58806 i so yeah blame AS58806 i assume the reason is because it's in asia, and they're trying to keep traffic to close places when they can the 7470 thing seems to be about normal load shifting though ie 38082 is preferred over 4651 and it looks like thailand. with 190 msec ping from nz, so not too bad routing from here | [19:20] | |
| mnathani | I see | [19:24] | |
| mercutio | and 230 from arp
hmm i dunno what's normal for thailand i've seen more than 200 from nz before though erk that ntt route from here goes via hong kong ntt around singapore actually kidn of sucks. surprisingly so considering they're japanese based. but i think it's cos they have some of their own transit links, and wnat to use those because they're cheaper. | [19:24] | |
| mnathani | makes sense now | [19:34] | |
| mercutio | cool. | [19:37] | |
| .......... (idle for 46mn) | |||
| *** | acf_ has quit IRC (Quit: leaving) | [20:23] | |
| mnathani | Is true that just because you peer with someone, you need not advertise all your routes? | [20:24] | |
| *** | acf_ has joined #arpnetworks | [20:25] | |
| mnathani | I am looking at an Amazon route: I 205.251.221.0/24 208.79.88.135 100 0 3356 3549 16509 i
which is being preferred via Level 3 even though Amazon is a peer apparently? | [20:25] | |
| mercutio | yeah you don't have to advertise all of your routes
often people will advertise local routes but not remote routes. so they don't have to carry traffic yeah see that is ages away. but 216.137.44.0 is local it's worse than it seems amazon aren't even advertising san jose routes but yeah it's pretty much up to them what they advertise. | [20:29] | |
| mnathani | only 4 routes I see | [20:33] | |
| mercutio | and all with pings of like 1 msec? | [20:33] | |
| mnathani | out of a potential 400 | [20:34] | |
| mercutio | 205.251.228.0 is an example of san jose
but it may just be near there | [20:34] | |
| mnathani | could it also be because they have cloud type services and want the Ips as portable as possible
only updating prefixes with major transit providers? | [20:36] | |
| mercutio | i doubt it
they just don't want to carry traffic across the country | [20:37] | |
| mnathani | they why peer in the first place?
s/they/then | [20:37] | |
| BryceBot | <mnathani> then why peer in the first place? | [20:38] | |
| mercutio | well the expectation is that you peer in multiple locations
so you carry traffic as close as possible to them, then they don't have to carry traffic it's the lowest cost for them that way and then the same thing is meant to happen in reverse. so they carry traffic as close to you as possible, then offload it onto you which is all good if people play by the rules but some people try and offload traffic as soon as they can so that they don't have to carry the traffic but that means user experience can be compromised. it's hot potato vs cold potato routing if you want to read about it http://en.wikipedia.org/wiki/Hot-potato_and_cold-potato_routing | [20:38] | |
| BryceBot | Knock that off you jackass, mercutio | [20:40] | |
| mnathani | thanks
whats up with BryceBot | [20:40] | |
| mercutio | he doesn't like me :)
google and facebook seem to try to bring traffic into their network asap but it can actually work out worse. like they will bring traffic in then send it to a data centre ages away like my facebook seems to go to east coast, but come in at fb on west coast. it says frc dunno what location that is | [20:41] | |
| mnathani | @iata frc | [20:43] | |
| BryceBot | FRC: Not a valid IATA. | [20:43] | |
| mercutio | hmm it goes from sjc to frc
sjc is obvious maybe it's a city | [20:43] | |
| mnathani | fremont,ca ? | [20:44] | |
| mercutio | i dobut it
forest city data centre? north carolina i think that's what it is | [20:44] | |
| mnathani | frc-nat.thefacebook.com
Menlo Park | [20:45] | |
| mercutio | http://en.wikipedia.org/wiki/Hot-potato_and_cold-potato_routing
oosp Power::Datacenter.add 2, "FRC", "forest-city" | [20:45] | |
| mnathani | https://dazzlepod.com/ip/173.252.71.1/ | [20:45] | |
| mercutio | geoip lookups are probably wrong
that's probably where facebook is based amazon are just saying US for ip's too btw i looked it up before :) yeah wikipedia confirms that's where they're based but california costs more for power. so people don't usually want to have huge server farms there | [20:46] | |
| mnathani | what would Amazon do with traffic you send to it that is destined for its AS Number, as in originated by it but for which it has not sent you routes | [20:47] | |
| mercutio | as well as land cost.
well that's technically illegal but will often work if you static route basically if you're caught doing it they'll drop your peer. is most likely what would happen. but if they had advertised route and withdrawn it just recently, and some traffic still flowed along it, then it would give false positives. actually i don't know if it's illegal so much but rude, and likely to be not allowed in contracts. like the peering exchange will probably have a clause also it's hard to know if amazon will send traffic down their own paths to arp. | [20:47] | |
| mnathani | would be easy to determine
traceroute from an ec2 instance? | [20:52] | |
| mercutio | i don't have an ec2 instance
i'm trying to ggoogle for looking glass | [20:52] | |
| mnathani | not so easy - getting a lot of books with looking glass in the tile available from amazon.com | [20:53] | |
| mercutio | that's what i found too
so i tried doing amazon web services. but people don't necessarily say that hmm i haev a friend with amazon i think | [20:53] | |
| mnathani | ec2 might be its own AS number though? | [20:54] | |
| RandalSchwartz | we all know a friend "with amazon" :) | [20:54] | |
| mercutio | he was making noises about shifting off
i told him it was bad in the first place. | [20:54] | |
| mnathani | greetings RandalSchwartz | [20:55] | |
| mercutio | i didn't actually realise how bad it was until i saw him doing some stuff with it :)
like there's some nasty throttling high pings low bandwidth and even when it's not throttling it's slow. | [20:55] | |
| mnathani | I think ARP spoils us | [20:55] | |
| RandalSchwartz | if the answer is EC2, you might have asked the wrong question | [20:55] | |
| mnathani | VPS hosting out there in general is pretty bad | [20:55] | |
| RandalSchwartz | it's scalable. and, yeah, it's scalable
other than that... ugh. | [20:56] | |
| BryceBot | That's what she said!! | [20:56] | |
| mercutio | well arp can feel slightly laggy to me at times.
but amazon was annoyingly noticably delaying laggy. | [20:56] | |
| RandalSchwartz | arp was amazingly quick when I was at oversee.net
then again, ping times of 0.01 seconds 2 hops | [20:56] | |
| mercutio | whereas arp more reminds me of dialup
i'm like 140 to 170 msec ping or something | [20:56] | |
| RandalSchwartz | oversee.net office -> fiber -> card cage at one wilshire -> fiber -> arp | [20:57] | |
| mercutio | weird it goes up to 180 now and it alternates.
my dedicated server in nz always seems really fast/responsive. | [20:57] | |
| RandalSchwartz | I was downloading about 40GB from my arp box, and I was limited by disk-write speed. :) | [20:57] | |
| mercutio | i think virtualisation can increase your chances of mild lag/delay. | [20:58] | |
| RandalSchwartz | I miss those oversee days :)
when I was testing speedtest.net servers, not mine. :) | [20:58] | |
| mercutio | i think often what people think is latency is jitter
if you have reasonably high pings but it's smooth then it doesn't feel that bad. like if you have 15 or 20 msec pings, and it feels laggy, it's probably jitter or packet loss. i used to kind of think that 5 msec or 10 msec etc would be noticable. but it was partially because along with higher pings also tends to come higher variation in ping | [20:59] | |
| mnathani | have you tried using mosh | [21:04] | |
| mercutio | yeh, it was really high cpu
i was using an atom at the time though i was working on my personal reimplementation of tcp using udp years ago and was thinking of doing forward error correction. i kind of got sidetracked. | [21:05] | |
| BryceBot | That's what she said!! | [21:06] | |
| mercutio | but the idea goes that you connect via tcp, then it runs udp in the middle, then it goes back to tcp
and along that udp path it can handle all the connections together for resends etc. and do better windowing/congestion control through knowledge. | [21:06] | |
| mnathani | you are trying to gain the speed from UDP
? | [21:07] | |
| mercutio | so like if you have a 20 megabit connection, not send more than 20 megabit etc.
well the idea was more to not delay for ages if there's packet loss. and to give more consistent smoother performance. | [21:07] | |
| mnathani | custom client and server
? | [21:08] | |
| mercutio | like one pf the problems with tcp is that if you send some data, the other end acknowledges it | [21:08] | |
| mnathani | or would it be more like a proxy
for ssh | [21:08] | |
| mercutio | if it doesn't acknowledge it, it resends.
but this takes time. it's more like a transparent tcp proxy like it'll intercept tcp connections, then proxy them, then come back out as tcp | [21:08] | |
| mnathani | it would have to be installed on the client and server
or just one side | [21:09] | |
| mercutio | on two sides.
i still want to do this :) | [21:09] | |
| mnathani | sounds interestings | [21:09] | |
| mercutio | but one of the ideas, was that you could run it on a wireless router or such.
and then on a linux server somewehre remote. and i have a linux server 10 msec away from me. i even have a wireless router. but i also have linux box, and ... i can just use that i actually had something working before but it was bugging out. | [21:09] | |
| mnathani | what language was your implementation written in? | [21:10] | |
| mercutio | and it had like fixed window size.
c. i wonder where the code is :) i was first trying to use this thing called udt. 2012 hmm this looks liek something else i was playing with to do with socks but it's hard to know looks like preconnecting socks i probably should just start again | [21:10] | |
| mnathani | I am available should you need some sort of beta tester | [21:16] | |
| mercutio | heh.
do you have a close dedicated server and a slow connection? | [21:16] | |
| mnathani | I have 2 laptops running linux nearby | [21:17] | |
| mercutio | i actually played with quite a few ideas. | [21:17] | |
| mnathani | and ARP is about 80 msec away | [21:17] | |
| mercutio | the other thing i was playing with was just bouncing https connections
which seems to help wifi connected devices the problem is you can proxy tablets etc. and that'll handle port 80, and raise performance. but https is predominantly used. and often tehre are annoying problems like people using devices far away from access point which is also easy to try and so for minimum effort to maximum gain, focusing on https tcp transparent proxying can give some gains to mobile devices using wifi and be quite easy to implement only requring an in between router that you have contorl over 80 msec is ages away as far as the other idea goes it gets complicated if you want to know when to bypass sending via the other server or not | [21:17] | |
| wifi is the other place that's ripe for improvement too though
as it's half duplex when you acknowledge packets a lot you reduce your available speed. and all the acknowledgements get lost in bufferbloat anyway. so it's not uncommon to get high pings while downloading at maximum speed, where the acknowledging doesn't really fix it. the general consensus from what i understand for bandwidth moderation on wireless is that you should look at the delay between packets when transmitting, rather than the acknowledgement loop like you want to only look at the one way latency, rather than the two way latency. and there's not normally loss because of error correction, so it's more that you want to alert when latency is going up too much so more like a shout out that your'e sending data too fast. like me typign too much when everyone else is quiet :) i imagine from rejigging things there's probably a 25% speed increase in straight downloads / file transfers so it can probably go into the noteworthy category though. i'm not sure how 802.11ac etc fares though also a lot of the research on these areas is kind of old. like there's this thing about looking at acknowledgements and removing redundant ones to reduce bandwidth consumption on more reliable links. sweet now i'm starting to feel motivated about it again | [21:25] | ||
| mnathani | would the primary application for a tcp proxy of sorts be to make connections with high latency more bearable to use and perhaps even improve performance? | [21:36] | |
| mercutio | it's more if there's packet lsos
loss but latency can also be a factor. | [21:36] | |
| mnathani | s/high latency/packet loss | [21:36] | |
| BryceBot | <mnathani> would the primary application for a tcp proxy of sorts be to make connections with packet loss more bearable to use and perhaps even improve performance? | [21:36] | |
| mercutio | there's so many complciated factors it's not funny.
like most times servers will send to you based upon how fast you respond to packets. which is fine if you're on ethernet and have symmetric connection. but if you have less upload bandwidth than download, or half duplex connection or such, your responses to data being sent could not give a clear picture of how much bandwidth is available. then there's the reliability of your connection from your network to the internet remote host. as well as the reliability of your connection to the wireless device. if you have perfect wifi with close path, then you're pretty much just bound by the connection to remote end but if you have problems with both, then performance takes a sharp sky dive. and if you're connecting to a server quite far away, and have an unreliable wireless connection, then having a closer connection can improve the "feel" of the connection so it doesn't have to have a feedback loop all the way to rmeote server. so basically by having two feedback loops, between wireless device and your network, and your network and the internet each of those can perform better, and your overall experience can be bet4er. then there's things like that linux default retransmit time used to be 3 seconds, and using 1 second gave a huge improvement if you have like 5% loss. that's a bit moot now, as most servers are probably doing that anyway. but it's probably posssible to go down further. some of my initial tests were tesing uk hosts bouncing a tcp connection throguh the US btw. which splits things in half. and did seem to behave better i got into this before i got arp though i think i tested with arizona first? | [21:36] | |
| ................. (idle for 1h20mn) | |||
| *** | Guest86251 is now known as atmark
atmark has quit IRC (Changing host) atmark has joined #arpnetworks | [23:03] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |