Objective assessment of 'the Internet is slow' complaints
In my role at Massey University, I am often asked to investigate complaints from our Help Desk of a 'the Internet is slow' nature. We are finding this increasingly difficult to do in any meaningful way. Massey is peered at WIX, PNIX and APE we have two Internet peers and have multiple paths to them and they both have multiple upstream providers. Simply ping testing for latency/connectivity doesn't really provide much of an insight, traceroute tells us where outbound packets went and which hops are 'slow' but doesn't indicate the return path. Most of our customers equate Website == Internet, so the responsiveness of a destination seems to also be an important consideration. I am assuming that most ISPs have Help Desk calls of a similar nature. How does one substantiate or refute such complaints, pro-actively identify 'slowness/congestion' ? Evidence collected by 'tools' needs to be defensible when responding to our 'customers'. Any pointers to how I can do this better would be appreciated. Glen Massey University.
Have you looked at the timeline feature hidden in Chrome's developer tools?
It is designed to allow web developers to tune the loading speed of their
web pages but may provide a reliable way to measure request latency and
load time.
Thanks,
Leith Bade
leith(a)leithalweapon.geek.nz
On 28 February 2012 07:06, Glen Eustace
In my role at Massey University, I am often asked to investigate complaints from our Help Desk of a 'the Internet is slow' nature. We are finding this increasingly difficult to do in any meaningful way. Massey is peered at WIX, PNIX and APE we have two Internet peers and have multiple paths to them and they both have multiple upstream providers.
Simply ping testing for latency/connectivity doesn't really provide much of an insight, traceroute tells us where outbound packets went and which hops are 'slow' but doesn't indicate the return path. Most of our customers equate Website == Internet, so the responsiveness of a destination seems to also be an important consideration.
I am assuming that most ISPs have Help Desk calls of a similar nature. How does one substantiate or refute such complaints, pro-actively identify 'slowness/congestion' ? Evidence collected by 'tools' needs to be defensible when responding to our 'customers'.
Any pointers to how I can do this better would be appreciated.
Glen Massey University. ______________________________**_________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/**mailman/listinfo/nznoghttp://list.waikato.ac.nz/mailman/listinfo/nznog
You can't get to every node in the path, but you can sometimes traceroute back from a remote point using some of the looking glasses internationally. http://www.traceroute.org/ More NZ based looking glasses in the core of ISP networks would be very very useful though (hint, hint...) Gerard On 28/02/2012 9:53 a.m., Leith Bade wrote:
Have you looked at the timeline feature hidden in Chrome's developer tools?
It is designed to allow web developers to tune the loading speed of their web pages but may provide a reliable way to measure request latency and load time.
Thanks, Leith Bade leith(a)leithalweapon.geek.nz mailto:leith(a)leithalweapon.geek.nz
On 28 February 2012 07:06, Glen Eustace
mailto:geustace(a)godzone.net.nz> wrote: In my role at Massey University, I am often asked to investigate complaints from our Help Desk of a 'the Internet is slow' nature. We are finding this increasingly difficult to do in any meaningful way. Massey is peered at WIX, PNIX and APE we have two Internet peers and have multiple paths to them and they both have multiple upstream providers.
Simply ping testing for latency/connectivity doesn't really provide much of an insight, traceroute tells us where outbound packets went and which hops are 'slow' but doesn't indicate the return path. Most of our customers equate Website == Internet, so the responsiveness of a destination seems to also be an important consideration.
I am assuming that most ISPs have Help Desk calls of a similar nature. How does one substantiate or refute such complaints, pro-actively identify 'slowness/congestion' ? Evidence collected by 'tools' needs to be defensible when responding to our 'customers'.
Any pointers to how I can do this better would be appreciated.
Glen Massey University. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz mailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Netspace Services Limited http://www.netspace.net.nz Phone +64 4 917 8098 Mobile +64 21 246 2266 Level 4, 191 Thorndon Quay, Thorndon PO Box 12-082, Thorndon, Wellington 6004, New Zealand
I use Firebug for Firefox to achieve same. Being able to plot the load times for websites and for more specifically, the individual items of content within the site, is enough to satisfy many people, especially when you point out that the 3.5meg flash animation in the middle of the page really does need several seconds to load, but that the download time for it was reasonable. The other tool i've used is iperf, this obviously requires you to have a well connected endpoint with appropriate access (often requires root?) but can again be used to verify that the bits of the network under your sphere of influence are performing as expected. Mark. On 28/02/12 09:53, Leith Bade wrote:
Have you looked at the timeline feature hidden in Chrome's developer tools?
It is designed to allow web developers to tune the loading speed of their web pages but may provide a reliable way to measure request latency and load time.
Thanks, Leith Bade leith(a)leithalweapon.geek.nz mailto:leith(a)leithalweapon.geek.nz
On 28 February 2012 07:06, Glen Eustace
mailto:geustace(a)godzone.net.nz> wrote: In my role at Massey University, I am often asked to investigate complaints from our Help Desk of a 'the Internet is slow' nature. We are finding this increasingly difficult to do in any meaningful way. Massey is peered at WIX, PNIX and APE we have two Internet peers and have multiple paths to them and they both have multiple upstream providers.
Simply ping testing for latency/connectivity doesn't really provide much of an insight, traceroute tells us where outbound packets went and which hops are 'slow' but doesn't indicate the return path. Most of our customers equate Website == Internet, so the responsiveness of a destination seems to also be an important consideration.
I am assuming that most ISPs have Help Desk calls of a similar nature. How does one substantiate or refute such complaints, pro-actively identify 'slowness/congestion' ? Evidence collected by 'tools' needs to be defensible when responding to our 'customers'.
Any pointers to how I can do this better would be appreciated.
Glen Massey University. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz mailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
erg.cs.waikato.ac.nz provides some historical info that can help with this type of question. I.E. it can tell you if the performance is the same today as it was last week and, if not, when it changed and if there was a path change associated with that. AMP supports http tests although we don't run then routinely to many sites. If you wanted more, we may be able to add them. Tony On 28/02/12 09:06, Glen Eustace wrote:
In my role at Massey University, I am often asked to investigate complaints from our Help Desk of a 'the Internet is slow' nature. We are finding this increasingly difficult to do in any meaningful way. Massey is peered at WIX, PNIX and APE we have two Internet peers and have multiple paths to them and they both have multiple upstream providers.
Simply ping testing for latency/connectivity doesn't really provide much of an insight, traceroute tells us where outbound packets went and which hops are 'slow' but doesn't indicate the return path. Most of our customers equate Website == Internet, so the responsiveness of a destination seems to also be an important consideration.
I am assuming that most ISPs have Help Desk calls of a similar nature. How does one substantiate or refute such complaints, pro-actively identify 'slowness/congestion' ? Evidence collected by 'tools' needs to be defensible when responding to our 'customers'.
Any pointers to how I can do this better would be appreciated.
Glen Massey University. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
participants (5)
-
Gerard Creamer
-
Glen Eustace
-
Leith Bade
-
Mark Foster
-
Tony McGregor