brycec: looks like its O.K now : ping wolfman.devio.us
PING wolfman.devio.us (66.7.199.108) 56(84) bytes of data.
64 bytes from devio.us (66.7.199.108): icmp_seq=1 ttl=244 time=35.3 ms
I wonder what can explain this: https://smokeping.cobryce.com/?displaymode=n;start=2014-10-18%2013:26;end=now;target=Internet.VoipMS.toronto3voipms
latency drop from 160ms to about 70ms
are you experiencing periodic abnormal latencies on ipv6?
every 8 or so pings has very high latency
64 bytes from 2607:f2f8:acd0::1: icmp_seq=1 ttl=64 time=20.8 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=2 ttl=64 time=29.8 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=3 ttl=64 time=0.527 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=4 ttl=64 time=0.847 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=5 ttl=64 time=0.496 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=6 ttl=64 time=0.512 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=7 ttl=64 time=9.80 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=8 ttl=64 time=25.5 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=9 ttl=64 time=11.1 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=10 ttl=64 time=0.795 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=11 ttl=64 time=0.736 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=12 ttl=64 time=0.709 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=13 ttl=64 time=0.548 ms
64 bytes from 2607:f2f8:acd0::1: icmp_seq=14 ttl=64 time=1.32 ms
zhangxiaobao: use pastebin for multi line messages
ok, sorry
I have not noticed anything, you are probably experiencing ICMP de-prioritization
and looking glass seem to have lost ipv6 connectivity, can't ping anywhere?
I don
I don't think they set up Ipv6 on the looking glass as yet
mercutio: i fixed ipv6 on the lg
oh cool
heh traceroute6 to www.arpnetworks.com shows as www
maybe take the search path out in resolv.conf?
lol
yeah go for it
mnathani: That is interesting about the voip.ms hosts. If you look at the "Last 7 days" you'll see it's consistent, same times every day for the last week, coinciding with packet loss too. Apparently there's congestion along the route. Here's an mtr, you can clearly see it's the Level3/NTT handoff http://sprunge.us/dDNW
hmm that didn't seem to work
brycec: I would think its more like a shift in routing, in a schedule like that rather than congestion. I plan to compare mtr reports from times of lower latency to higher latency to see if I can figure it out
mnathani: well you have my mtr from the high latency time period :)
I do indeed
if there is actual congestion usuallyt iperf in udp mode at low bandwidth over a long period of the time is best way to monitor
you can usually get it to report every 0.5 seconds, but you can hack the source to report every 100 msec.
mercutio: you probably need access to a box at each end to test that out?
mnathani: yeah.
that's the annoying part.
remote end being monitored is a Toronto Voip.ms POP
is there a way to get a reverse trace route without access to a looking glass or the remote end?
oh.
nope
you could email them
is it level 3 outbound?
hopefully level3 inbound is turned on soon and fixes it.
i use Toronto's voip.ms POP
i tried google hangouts outbound voice thingy before.  the free thing.  it seemed laggy.
skype worked better.
i dunno how skype manages so well tbh.  for international calls it seems to have some great jitter correction or something - it doesn't feel like it breaks up and jitters heaps.
and the echo cancellation seems superb.
+1 for Skype
connection has to be really poor for quality to degrade
i kind of hate skype, but it works well for actual calls.
it seems to be quite buggy though, especially on android.
and uses way too much cpu on android, linux, macos etc.
it never seems jabber really got as well functioning for every day users as i would have liked :(
I use Skpe all the time on Windows, no complaints
From an ARP VPS? That would be really silly.   15:44:40     staticsafe | i use Toronto's voip.ms POP
oh nope
from home
heh
Bear in mind that latency is being measured from an ARP vps... you're probably fine :p
er, bare
im 10ms away from it, peering at the local IX
staticsafe: looking at the smokeping graphs, it seems toronto, toronto2 and toronto3 are the ones where latency changes drastically every day. ie: toronto4 seems unaffected
as brycec mentioned, this is latency to an ARP VPS
(I don't think I knew there was a toronto4...)
toronto4 goes over Cogent
although the return traffic might be different as level3 is not announcing ARP IP space at the moment
eww cogent
mnathani: on windows it works better than other platforms.
http://lg.arpnetworks.com/cgi-bin/bgplg?cmd=show+ip+bgp&req=184.75.213.210
http://lg.arpnetworks.com/cgi-bin/bgplg?cmd=show+ip+bgp&req=184.75.215.146
first is toronto4, second toronto3
oh, that's nlayer
i'm surprised it's going to nlayer via level3
so cogent is a better route if dual advertised, .. so they're avoiding cogent by not even advertising to cogent, or prepending
i like to add a prepend to cogent routes myself.
cogent often have short as-paths.  but intermittent performance.
although on-net is a lot better than it was.
it's mostly their peering/transit that sucks.
mercutio: what do you mean by 'on-net' ?
mnathani: cogent at both ends
like cogent -> at&t is crap etc.