King: estimating latency between arbitrary internet end hosts
Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment
TRIDENTCOM '05 Proceedings of the First International Conference on Testbeds and Research Infrastructures for the DEvelopment of NeTworks and COMmunities
How's My Network? A Java Approach to Home Network Measurement
ICCCN '09 Proceedings of the 2009 Proceedings of 18th International Conference on Computer Communications and Networks
Netalyzr: illuminating the edge network
IMC '10 Proceedings of the 10th ACM SIGCOMM conference on Internet measurement
HostView: annotating end-host performance measurements with user feedback
ACM SIGMETRICS Performance Evaluation Review
Broadband internet performance: a view from the gateway
Proceedings of the ACM SIGCOMM 2011 conference
Fathom: a browser-based network measurement platform
Proceedings of the 2012 ACM conference on Internet measurement conference
Proceedings of the 2012 ACM conference on Internet measurement conference
Dasu: pushing experiments to the internet's edge
nsdi'13 Proceedings of the 10th USENIX conference on Networked Systems Design and Implementation
An in-depth study of LTE: effect of network protocol and application behavior on performance
Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM
Hi-index | 0.00 |
Conducting network measurement in a web browser (e.g., speedtest and Netalyzr) enables end users to understand their network and application performance. However, very little is known about the (in)accuracy of the various methods used in these tools. In this paper, we evaluate the accuracy of ten HTTP-based and TCP socket-based methods for measuring the round-trip time (RTT) with the five most popular browsers on Linux and Windows. Our measurement results show that the delay overheads incurred in most of the HTTP-based methods are too large to ignore. Moreover, the overheads incurred by some methods (such as Flash GET and POST) vary significantly across different browsers and systems, making it very difficult to calibrate. The socket-based methods, on the other hand, incur much smaller overhead.Another interesting and important finding is that Date.getTime(), a typical timing API in Java, does not provide the millisecond resolution assumed by many measurement tools on some OSes (e.g., Windows 7). This results in a serious under-estimation of RTT. On the other hand, some tools over-estimate the RTT by including the TCP handshaking phase.