***: himuraken has joined #arpnetworks
himuraken has quit IRC (Ping timeout: 256 seconds)
himuraken has joined #arpnetworks
himuraken has quit IRC (Ping timeout: 245 seconds)
himuraken has joined #arpnetworks
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
amdprophet has joined #arpnetworks
dzup has quit IRC (Ping timeout: 246 seconds)
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
mnathani has quit IRC (Read error: Connection reset by peer)
mnathani has joined #arpnetworks
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
scottschecter has quit IRC (Quit: WeeChat 0.4.0)
scottschecter has joined #arpnetworks
amdprophet has quit IRC (Remote host closed the connection)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
bGeorge has quit IRC (Quit: Bye.)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
henderb has quit IRC (Ping timeout: 255 seconds)
henderb has joined #arpnetworks
bGeorge has joined #arpnetworks
heavysixer has quit IRC (Quit: heavysixer)
jm|laptop has joined #arpnetworks jm|laptop: hi
I have the super-basic "small" VPS plan
is my speed limited?
I'm trying to download a dataset from my VPS to here - and it seems really throttled to like 1M ***: amdprophet has joined #arpnetworks mnathani: jm jm|laptop: iperf seems to bear it out :/ mnathani: jm|laptop: where is "here"
VPS should be able to hit around 100mbit jm|laptop: here is my home fibre dual-xDSL mnathani: east coast? west coast? europe? asia? jm|laptop: oh. UK mnathani: k jm|laptop: icmp_req=1 ttl=44 time=166 ms mnathani: v4 or v6? jm|laptop: both / either
scp ipv6 and http ipv4 to prove it wasn't ssh overhead
and iperf ipv4
it just stalled again >.< mnathani: try the arpnetworks speed test which is on gigabit: http://arpnetworks.com/100mb.bin jm|laptop: that's coming at like 251K/s
although I still have my other scp going on -: jm|laptop mtrs jm|laptop: no obvious loss, slows down cross-Atlantic
so I have a colo in Manchester pulling 1.7M from that .bin, ramhost London pulls ~500K
ramhost down to 120K now
I wonder if this is a peering thing CaZe: moar routes mercutio: could be
or transit thing jm|laptop: seems to go myISP > L3 LON > L3 NYC > nlayer > us.pktxchng > mzima
who is nlayer? mercutio: nlayer is fine
check other direction
some of the any2ix peers can be kind of slow with transit back
atrato i've noticed be slow before for example jm|laptop: mzima > big pause > nlayer > L3 LA > L3 SJ > LA NYC x3 > L3 LON > myISP
it really bounces around L3 :S mercutio: that really should be fine unless your isp has congestion at level 3 jm|laptop: 18 level3.restless.thn.aaisp.net.uk (195.50.95.67) 145.879 ms 146.302 ms 146.025 ms
my isp peers L3 mercutio: 9. ae-82-82.ebr2.NewYork1.Level3.net 0.0% 6 138.8 139.0 138.8 139.5 0.3
ae-72-72.ebr2.NewYork1.Level3.net
like that etc? jm|laptop: yeah. With an ominous * * * in between mercutio: mtr is good at skipping over that :) jm|laptop: 14 ae-91-91.ebr1.NewYork1.Level3.net (4.69.134.77) 146.221 ms ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65) 147.240 ms ae-91-91.ebr1.NewYork1.Level3.net (4.69.134.77) 146.204 ms
15 * * *
16 ae-59-224.csw2.London1.Level3.net (4.69.153.142) 147.207 ms 147.286 ms ae-56-221.csw2.London1.Level3.net (4.69.153.130) mercutio: it does that here on another route not to arp from a uk vps jm|laptop: I guess its sub-Atlantic node :) mercutio: with like two dead hops between london and newyork
you have the same mpls exit path thingy where new york shows high ping like london jm|laptop: 150ms ? mercutio: yeh it's the same on london and new york though
rather than showing the latency from london to new york
you're not using openbsd or something are you? jm|laptop: ..... where? mercutio: openbsd's tcp/ip stack can be kind of bad for perfomrance transatlanttic jm|laptop: my router runs OpenBSD mercutio: takes longer to ramp up only seems to increase window size with scaling
router doens't matter
it's only end point jm|laptop: then no, Debian mercutio: yeah debian defaults should be fine even jm|laptop: so ARP /doesn't/ throttle? mercutio: nah it doesn't throttle
and level3 usually has good speeds
unless someone doesn't buy enough level 3 transit or such jm|laptop: just coincidence that my monitor is showing almost /exactly/ 1M :) mercutio: you're at like 150 msec altency? jm|laptop: I'm not at liberty to disclose my altency mercutio: well guessing that jm|laptop: 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 166.583/167.351/167.918/0.735 ms mercutio: your window size would be about 160k ***: heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer mercutio: which isn't generally a size anything will cap at jm|laptop: when my scp finishes I might try another iperf mercutio: ohh
it's not old scp is it? jm|laptop: no mercutio: ok jm|laptop: and I tried http also! (see above) mercutio: ssh used to have window size issues
ahh ok
well assuming you have more than 128mb ram jm|laptop: [02:44] <jm|laptop> scp ipv6 and http ipv4 to prove it wasn't ssh overhead mercutio: linux should pick big enough tcp window size
ipv6 was the same? jm|laptop: yup
scp is ipv6 mercutio: ok that's really bizzare
i've often found ipv6 and ipv4 give completely diff performance
sometimes one is like twice as fast as the other jm|laptop: doesn't make a lot of sense mercutio: yeah jm|laptop: unless the whole ipv6 topology is different
which doesn't make a lot of sense mercutio: oh it is often i think
i dunno
i even reproduced that with the same provider being used for ipv4 and ipv6
it may just be load balancing tkaing diff path jm|laptop: were they cheap? mercutio: suppose?
i dunno jm|laptop: maybe the employed a different ipv6 gateway mercutio: well arp dose
does jm|laptop: s/different/less congested/ mercutio: i can't remember which was faster
sometimes people don't shape ipv6 properly etc too
and shape ipv4 jm|laptop: hm
722141184 98% 407.45kB/s 0:00:29 mercutio: ok i need to try again :) jm|laptop: hmm that's weirder still mercutio: weird both are going slow atm jm|laptop: I had two scp making that 1M mercutio: dude i'm getting terrible speeds compared to normal from this host too
it's a friends connection but it usually does faster jm|laptop: and one has finished so I expected other to take 'spare' bandwidth
but it's 500k
wtf
587956224 80% 385.63kB/s 0:06:10
like something is making 500K per connection :S mercutio: i got 647k/sec with ipv6 and 509k/sec with ipv4
for a 10 mb file
with my normal provider getting 2267k/sec average
130 msec ping
versus 138 msec on the slow jm|laptop: [ 3] 0.0-10.2 sec 7.12 MBytes 5.83 Mbits/sec
^^ my other colo mercutio: and 139 msec with ipv6 on the slow
hmm
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10.0M 100 10.0M 0 0 509k 0 0:00:20 0:00:20 --:--:-- 504k
and that's with any2ix peer jm|laptop: (and my values include wireless overhead to the laptop) mercutio: it's prob this stupid upstream :/ jm|laptop: oh well mercutio: wireless doesn't really slow things down unless you're far away jm|laptop: part1 of my dataset is here so I can grok it mercutio: oh there's packet loss to last hop that's really weird jm|laptop: thanks for clarifications :) mercutio: well it can limit you, but doesn't slow down unless you're past bandwidth and it's giving high pings locally
basically jm|laptop: wait what?
how can I check my bandwidth limit? ***: _mnathani_ has joined #arpnetworks mercutio: i meant on wireless
like if your wirelss can do 20 megabit jm|laptop: oh mercutio: and you're pushing 25 megabit it'll slow it down to 20 megabit jm|laptop: I have 5GHz N mercutio: but if you're pushing 5 megabit then it'll be same speed on wireless and ethernet
it doesn't tend to give loss
it can, but usually bandwidth is heavily reduced before that
pings spike etc jm|laptop: [ 3] 0.0-10.0 sec 126 MBytes 106 Mbits/sec
not bad for wireless :) mercutio: yeah
so shouldn't be an issue cos you have dual dsl
oh
how does your dual dsl work? jm|laptop: I pull about 50M from my dual xdsl mercutio: do you have to do multiple connections to max it out?
or is it bonding? jm|laptop: bondage mercutio: cool
mlpppp :) jm|laptop: nth packet downstream mercutio: oh jm|laptop: no mercutio: that's better
so it doesn't split each packet half between each
does that give out of order issues? jm|laptop: aiui it balances based on latency from LCP data
yes; but TCP/IP is designed to deal with that :) mercutio: err
tcp/ip sucks with out of orer :)
perfomrance wise
it's more designed to cope
than deals well with :) jm|laptop: worksforme dot com mercutio: heh jm|laptop: if I had a more expensive router at this end I could handle it better
but obsd router doesn't do too bad a job mercutio: i'm surprised it looks at lcp data
i wanted to play with bonding some day
i was trying to think up novel ways to do it better jm|laptop: my ISP is pretty switched on with this stuff
I get per second graphing and stuff mercutio: any idea how they're doing it?
i was playing with ppp compression a while back
it works fine until you get packet drops
and it seems to make more sense on upstream than downstream for adsl jm|laptop: they made their own router mercutio: oh wow
ok that's good to know
i didn't think anything was doing those kinds of smarts normally jm|laptop: http://wiki.aa.org.uk/index.php/FireBrick
http://www.firebrick.co.uk/products_2700.php this
http://www.firebrick.co.uk/ or indeed this :'/ mercutio: oh
i read something on this site before
about some special ppp server i think jm|laptop: which part of the PPP sever?
it's not that clever :/ mercutio: To bond downlink on DSL lines you need the ISP to send traffic down multiple lines. The FB6202 LNS can do this on multiple L2TP links with per link speed controls. Bonding downlink does not need anything at the receiving end as the packets simply arrive on one of multiple simple broadband routers and go on to the LAN. It is obviously a good idea to use an FB2700 at the customer end to also bond uplink
though.
it's not acutally specific to the termination device ***: mnathani has quit IRC (*.net *.split)
Ehtyar has quit IRC (*.net *.split)
hazardous has quit IRC (*.net *.split)
Lucifer7 has quit IRC (*.net *.split)
toddf has quit IRC (*.net *.split) mercutio: but the sending ppp
Because bonding works on a per-packet basis, even a single session can make use of multiple lines. However, it is worth bearing in mind that whilst IP does not guarantee packet order, most TCP stacks will have trouble if you bond more than about 4 lines or if the lines are very different latency. jm|laptop: that's multihoming mercutio: nah that's bonding dsl jm|laptop: the former
re: the latter, I only have two :) mercutio: it's both under bonding
yeh
but it does out of order a bit
ok jm|laptop: and the latency is pretty much similar because it comes to my house on the same 6-string drop :) mercutio: it's actually really easy for it to be different
if lacp etc is being used jm|laptop: yup
again: wfm.com mercutio: it'll matter less for big packets though jm|laptop: I have poor-mans bonding at this end
an Alix
mpath routing mercutio: anyway, i'd try a udp test jm|laptop: whence? mercutio: iperf -u jm|laptop: whence? mercutio: which'll tell you if there' any packet loss
and it'll tell you how much is out of order
if there's loss it's prob reason it's going slow jm|laptop: [ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries. mercutio: if there's no loss and no out of order your isp may be doing something weird with tcp/ip traffic
you need iperf -s -u on server
iperf -c -b 2m
on client
where client uploads to server
well 1mbit is fine too jm|laptop: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.406 ms 2/ 893 (0.22%) mercutio: you can use -i 1 as well on server to list per second
hmm jm|laptop: hmm indeed :) mercutio: maybe try -l 512
on both
to send smaller packets
and i think it's -t 30 to do 30 second test jm|laptop: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.225 ms 0/ 2561 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order mercutio: that seems fine
hmmm jm|laptop: I know: except for the speed :) mercutio: that's cos you have -1m
-b 1m
try -b2m jm|laptop: hm mercutio: udp sends at fixed speed
but generally speaking if udp is fine at low speeds without loss then the link is going ok jm|laptop: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.216 ms 0/ 2561 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
something really only wants 1Mb/s :) mercutio: -b 2m
on the client jm|laptop: I did that mercutio: oh
are you sending from your dsl to arp?
you have to do arp to dsl jm|laptop: $ iperf -u -l 512 -b2m -c arp mercutio: yeh do it other way around
cos client sends to server jm|laptop: how? I have NAT?
JUST KIDDING mercutio: port forward? jm|laptop: my ISP is better than that :) mercutio: you have /64 ? jm|laptop: I have /26 and /48 actually mercutio: you can do ipv6 with iperf but you need to set -V
and if you have differnt default udp return addresss than incoming address you need to bind on the server
to the incoming address
-B <ip> i think it is
it seems much more complicated when desciribing it jm|laptop: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.224 ms 1/ 2562 (0.039%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
other direction
something somewhere really seems to be restricting me to 1M :)
anyway: off to research my dataset
thanks for your time mercutio :) ***: Ehtyar has joined #arpnetworks mercutio: i'll just it ***: up_the_irons has quit IRC (Ping timeout: 264 seconds)
mikeputnam has quit IRC (Ping timeout: 264 seconds)
DiaboliK has quit IRC (Ping timeout: 264 seconds)
[FBI] has quit IRC (Ping timeout: 264 seconds)
[FBI] starts logging #arpnetworks at Sun Mar 31 19:49:47 2013
[FBI] has joined #arpnetworks
up_the_irons has joined #arpnetworks
ChanServ sets mode: +o up_the_irons
himuraken has quit IRC (Ping timeout: 255 seconds) up_the_irons: mikeputn1m: lol nice iron maiden references earlier... ***: dzup has joined #arpnetworks mercutio: up_the_irons: do you normally allow /23s into your network now? up_the_irons: mercutio: if it's from a peer
soon, i'll have everything, with the new router
brb staticsafe: new router o/ ***: himuraken has joined #arpnetworks mercutio: up_the_irons: trit's not a peer is it?
everything would be good, it's accepting a way worse secondary route ***: _mnathani_ has quit IRC ()
himuraken has quit IRC (Ping timeout: 255 seconds)
himuraken has joined #arpnetworks
dzup has quit IRC (Ping timeout: 245 seconds)
mnathani has joined #arpnetworks
dzup has joined #arpnetworks
himuraken has quit IRC (Ping timeout: 240 seconds)
himuraken has joined #arpnetworks
himuraken has quit IRC (Ping timeout: 256 seconds)
himuraken has joined #arpnetworks
Webhostbudd has joined #arpnetworks