***: sga0 has joined #arpnetworks
xales has joined #arpnetworks
sga0_ has joined #arpnetworks
sga0 has quit IRC (Ping timeout: 246 seconds)
medum has quit IRC (Ping timeout: 246 seconds)
medum has joined #arpnetworks
SpaceDum1 has quit IRC (Ping timeout: 255 seconds)
SpaceDump has joined #arpnetworks mercutio: quiet in here. RandalSchwartz: "yeah... a little TOO quiet" mercutio: :) ***: SpaceDump has quit IRC (Ping timeout: 244 seconds)
SpaceDump has joined #arpnetworks mnathani: BryceBot: yes BryceBot: Okay! twss! ':)' mercutio: :)
hmm?
i dunno how brycebot works mnathani: @google nexus 6 BryceBot: 1,260,000 total results returned for 'nexus 6', here's 3
Nexus 6 release date, news and rumors | News | TechRadar (http://www.techradar.com/us/news/phone-and-communications/mobile-phones/nexus-6-release-date-news-and-features-1232946) 13 hours ago ... Nexus 6 release date, news and rumors - All the latest on the Nexus 6, and if you believe the rumors we're in for a giant phone from Motorola.
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. mnathani: 1440 x 2560 pixels, 5.96 inches (~493 ppi pixel density) BryceBot: That's what she said!! mnathani: BryceBot: no BryceBot: Oh, okay... I'm sorry. '1440 x 2560 pixels, 5.96 inches (~493 ppi pixel density)' brycec: mercutio (and mnathani): It's bayesian learning
:)
twss? BryceBot: That was 50% what she said. ':)' brycec: I love when it's hard
twss? BryceBot: That was 92.63% what she said. 'I love when it's hard' brycec: twss BryceBot: Okay! twss! 'I love when it's hard' brycec: twss? BryceBot: That was 92.77% what she said. 'I love when it's hard' mercutio: Bryce: i meant how to trigger it
the new samsung 840 evo firmware update is out. brycec: Say something >97%
(or is it 96?) mercutio: i wish samsung made updates easy on linux. staticsafe: mercutio: ooh thanks for the reminder
lol their software tells me I have the latest firmware 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. staticsafe: :o mercutio: magician wasn't showing me the update either, but it may be some caching thing. staticsafe: yeah 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 staticsafe: ah i have two EVO drives in separate machines, no RAID
its gonna be annoying to update the one in the NUC mercutio: there's actually an iso boot thingy.
which runs dos and so on.
which you can probably get going on a usb stick. staticsafe: yeah 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 mnathani: mercutio: I dont see the update on ther website
Samsung 840 EVO that is mercutio: under firmware restoration till it lists the firmware
oh sweet it finished
now what ***: dj_goku has quit IRC (Remote host closed the connection) mnathani: If you are trying to establish an Internet connection using BGP, what kind of interconnect between the providers must first be present? brycec: Any sort of IP interconnect
Typically RFC1918
(because why waste public addresses and possible routing headaches) mnathani: would those RFC1918 ever show up in traceroutes? brycec: Yes
You can see a 10. address tracerouting out of ARP sometimes mnathani: thats the OpenBSD box, correct? 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 mnathani: so the any2 side would also have an RFC1918 within that same segment as the 10. 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 mnathani: fiber I would assume? up_the_irons: mnathani: no, the 10.10.10.5/30 is between s7.lax and r1.lax (which is the .6) brycec: (my bad, sorry) up_the_irons: no worries brycec brycec: I'd assume copper, since 10GbE copper is pretty cheap. But I'm just guesing
*guessing up_the_irons: it's r1.lax that carries all the peer traffic mnathani: I remember seeing flickr images of fiber runs up_the_irons: yes, data center porn brycec: <3 data centre porn mnathani: who doesnt? up_the_irons: better than real porn
sometimes brycec: Most spouses, for starters :p
lol up_the_irons up_the_irons: ;) mnathani: so do ARP <> other Transit, or Peers BGP go over RFC1918 Address Space? 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 up_the_irons: no, i just have a couple RFC1918 addresses between our own equipment (why waste a perfectly good public /30? ;) brycec: (oh I was totally wrong, my bad) mercutio: up_the_irons: for pretty traceroutes! up_the_irons: indeed, it *does* make the traceroutes better mnathani: brycec: np 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. mnathani: I guess it depends on who wants mroe control over PTR records
s/mroe/more BryceBot: <mnathani> I guess it depends on who wants more control over PTR records up_the_irons: mnathani: all my transits and peers do not use rfc1918 address space mercutio: mnathani: you can delegate sometimes too
but yeah, it varies a bit brycec: s/who's/whose/ BryceBot: <mercutio> it's normal to use /30s to interconnect to other providers, but it can vary whose ip address space is used. 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 up_the_irons: mercutio: yes
129.250.198.185 is their side mercutio: so yaeh, that in itself is weird. up_the_irons: 129.250.198.186 is mine BryceBot: That's what she said!! mercutio: oh
i thought it was other way around
but yeah that makes sense. up_the_irons: usually the provider has the lower number mercutio: so yeah that looks like ntt ip
up_the_irons: yeah.
but sometimes it's the other way around up_the_irons: sometimes 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. brycec: I use .254 for that very reason :D mnathani: my home network is a /16 with gw at 10.10.10.10 mercutio: heh. brycec: Because idiots may bring a .1 onto the network and risk fucking shit up mercutio: well i have a /29 with high too brycec: Or just to avoid bad programs that assume a gateway at .1 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 brycec: .251 and .252 are my gateways, with .254 as the carp'd address :D mercutio: and want to reconfigure it brycec: mercutio: There is that too sometimes, lol mercutio: when using dhcp it doesn't really matter what the address is brycec: Indeed, indeed. mercutio: speaking of annoying things, why does coresite show all of it's hosts with the same dns name brycec: s/it's/its/ BryceBot: <mercutio> speaking of annoying things, why does coresite show all of its hosts with the same dns name mercutio: heh brycec: (speaking of annoying things :P) mnathani: mercutio: How is the ARP lg coming along? BryceBot: That's what she said!! brycec: twss? mercutio: i was thinking possessive. mnathani: BryceBot: no 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?' mercutio: mnathani: it's working, but incomplete. brycec: mercutio: you were thinking it, but you didn't write the possessive form
What, why isn't that something "she" would say? :P mercutio: brycec: my typing/thinking/whatever is pretty messy sometimes :) 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) mnathani: k, cool mercutio: is anyone from canada in here? mnathani: yup mercutio: ahh. brycec: i'm canadian... not technically from canada though up_the_irons: lol mnathani: If you are wondering *.*.149.228 is me mercutio: heh
yeah figured
was going to see if anyone figured out where it was. mnathani: will it eventually get the wildcard ARP SSL Cert? mercutio: probably not?
i wouldn't myself. BryceBot: That's what she said!! 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 ? mnathani: Its quick
compared to other looking glasses mercutio: yeah that's what i thought mnathani: but I guess that cos theres no traffic hitting it really mercutio: also cos it's not using perl
it's c code mnathani: and BGP sessions to the VPS
right
rather than forward queries to a router mercutio: yeah actually quagga is so much quicker than ciscso
for route servers
for the ones with telnet mnathani: this one wont support telnet will it? mercutio: i don't think so
that would be pretty cool
surprised that bryce didn't pipe up BryceBot: That's what she said!! brycec: I didn't? mercutio: and try the looking glass. brycec: mercutio: Why am I piping up here?
Is the lg up yet? mercutio: mnathani found it :) brycec: And if so, what's the address?
lol mercutio: guess :) -: brycec found it too brycec: Ewww why is this ipv4 only? mercutio: haha brycec: Guess that explains why my cmd=ping6 failed mercutio: it won't be ipv4 only for long
i knew someone would complain about ipv4 only hah up_the_irons: we haven't hooked up ipv6 yet -: brycec is the preeminent complainer about lack of ipv6 mercutio: hmm i reckon icmp traceroute would be better mnathani: I wonder why show ip bgp as doesnt work for AS25795 brycec: I wonder why a traceroute to 174.136.103.130 fails miserably
(my arp vps) 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 brycec: Am I? Hm mercutio: lots of people do brycec: I can traceroute and traceroute -I from home just fine mercutio: you may have an allow on from your ip? brycec: Oh wait, my home IP is whitelisted, lol mercutio: yeah mnathani: could have something to do with s1.lax not hooked up yet 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 brycec: (blocked packet)
Sorry for the false alarm :) mercutio: hah no write permissions
try now brycec: bam worked mercutio: yeah i modified the code brycec: YOU HACKER mercutio: jsut to add -I in
it's beter overall.
i did it for traceroute6 too
but can't tes tthat. brycec: lol how the first hop has higher latency than my VPS mercutio: yeah cisco brycec: mercutio: you could use ::1 :P 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? brycec: vps3.cobryce.com mercutio: yeah -I fixes it for ipv6 too -: brycec notes some ipv6 hits mercutio: so should be good to go brycec: twss BryceBot: Okay! twss! 'so should be good to go' 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 mnathani: whats a query I can request to show all prefixes originating from a certain AS ? mercutio: source-as
i wonder if the timeout should be bumped up too for hops that don't respond mnathani: cool, crazy fast response mercutio: i'd kind of like to see mtr added. 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 mercutio: heh my pva monitor gets so hot
but newer ones don't really use that much power 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 mercutio: my dehumidifier warms my room up a little.
i was using heater a bit before, but dehumidifer actually seems more useful to me. brycec: heh
I avoid running a heater at all costs mercutio: for cost reasons? :) brycec: Feels like I've lost the battle
mercutio: Hmmm more like principle
I have all this tech that puts of heat mercutio: i used to never use heaters. brycec: I should be able to stay warm by it mercutio: i'd even sleep with the window open in winter.
but my health seems to prefer having some heat now days. brycec: I did that back when I lived in AZ... mercutio: and to me health is more important than principle :)
cos it sucks being sick. -: brycec doesn't get sick easily, much less from the cold 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. brycec: Because you're an old man now? 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 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 mercutio: uhh
i'll lookup that route
it doesn't paste well :)
you mean with so many damn prepends? mnathani: yes, the prepends 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 mnathani: I see 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. mnathani: makes sense now mercutio: cool. ***: acf_ has quit IRC (Quit: leaving) mnathani: Is true that just because you peer with someone, you need not advertise all your routes? ***: acf_ has joined #arpnetworks 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? 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. mnathani: only 4 routes I see mercutio: and all with pings of like 1 msec? mnathani: out of a potential 400 mercutio: 205.251.228.0 is an example of san jose
but it may just be near there 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? mercutio: i doubt it
they just don't want to carry traffic across the country mnathani: they why peer in the first place?
s/they/then BryceBot: <mnathani> then why peer in the first place? 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 BryceBot: Knock that off you jackass, mercutio mnathani: thanks
whats up with BryceBot 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 mnathani: @iata frc BryceBot: FRC: Not a valid IATA. mercutio: hmm it goes from sjc to frc
sjc is obvious
maybe it's a city mnathani: fremont,ca ? mercutio: i dobut it
forest city data centre?
north carolina
i think that's what it is mnathani: frc-nat.thefacebook.com
Menlo Park mercutio: http://en.wikipedia.org/wiki/Hot-potato_and_cold-potato_routing
oosp
Power::Datacenter.add 2, "FRC", "forest-city" mnathani: https://dazzlepod.com/ip/173.252.71.1/ 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 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 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. mnathani: would be easy to determine
traceroute from an ec2 instance? mercutio: i don't have an ec2 instance
i'm trying to ggoogle for looking glass mnathani: not so easy - getting a lot of books with looking glass in the tile available from amazon.com 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 mnathani: ec2 might be its own AS number though? RandalSchwartz: we all know a friend "with amazon" :) mercutio: he was making noises about shifting off
i told him it was bad in the first place. mnathani: greetings RandalSchwartz 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. mnathani: I think ARP spoils us RandalSchwartz: if the answer is EC2, you might have asked the wrong question mnathani: VPS hosting out there in general is pretty bad RandalSchwartz: it's scalable. and, yeah, it's scalable
other than that... ugh. BryceBot: That's what she said!! mercutio: well arp can feel slightly laggy to me at times.
but amazon was annoyingly noticably delaying laggy. RandalSchwartz: arp was amazingly quick when I was at oversee.net
then again, ping times of 0.01 seconds
2 hops mercutio: whereas arp more reminds me of dialup
i'm like 140 to 170 msec ping or something RandalSchwartz: oversee.net office -> fiber -> card cage at one wilshire -> fiber -> arp mercutio: weird it goes up to 180 now and it alternates.
my dedicated server in nz always seems really fast/responsive. RandalSchwartz: I was downloading about 40GB from my arp box, and I was limited by disk-write speed. :) mercutio: i think virtualisation can increase your chances of mild lag/delay. RandalSchwartz: I miss those oversee days :)
when I was testing speedtest.net servers, not mine. :) 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 mnathani: have you tried using mosh 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. BryceBot: That's what she said!! 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. mnathani: you are trying to gain the speed from UDP
? 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. mnathani: custom client and server
? mercutio: like one pf the problems with tcp is that if you send some data, the other end acknowledges it mnathani: or would it be more like a proxy
for ssh 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 mnathani: it would have to be installed on the client and server
or just one side mercutio: on two sides.
i still want to do this :) mnathani: sounds interestings 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. mnathani: what language was your implementation written in? 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 mnathani: I am available should you need some sort of beta tester mercutio: heh.
do you have a close dedicated server and a slow connection? mnathani: I have 2 laptops running linux nearby mercutio: i actually played with quite a few ideas. mnathani: and ARP is about 80 msec away 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
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 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? mercutio: it's more if there's packet lsos
loss
but latency can also be a factor. mnathani: s/high latency/packet loss 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? 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? ***: Guest86251 is now known as atmark
atmark has quit IRC (Changing host)
atmark has joined #arpnetworks