From fischer at ftw.at Tue Feb 14 02:25:26 2012 From: fischer at ftw.at (Fischer, Hans Ronald) Date: Tue, 14 Feb 2012 10:25:26 +0000 Subject: [Netalyzr] measurement results needed Message-ID: Hi, my name is Hans Ronald Fischer I'm working at the FTW Telecommunications Research Center Vienna. Currently, we are analyzing properties of Internet home accesses in Austria. We are trying to draw a complete picture of all ISP attributes to get an overview what the current status is and how it may change in the future. We collected already a lot of data of bigger ISPs but missing information about smaller ones. Do you think it might be possible to provide us measurement results of such ISPs? It would be very beneficial for our work. Best Regards, Hans Ronald Fischer Hans Ronald Fischer, MSc. | Engineer | Ext. -63 | Mobile +43/1/5052830 | fischer at ftw.at -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20120214/e1806c9d/attachment.html From christian at icir.org Tue Feb 14 10:03:04 2012 From: christian at icir.org (Christian Kreibich) Date: Tue, 14 Feb 2012 10:03:04 -0800 Subject: [Netalyzr] measurement results needed In-Reply-To: References: Message-ID: <4F3AA1D8.2080503@icir.org> Hi Hans, On 02/14/2012 02:25 AM, Fischer, Hans Ronald wrote: > Hi, > my name is Hans Ronald Fischer I'm working at the FTW > Telecommunications Research Center Vienna. Currently, we are > analyzing properties of Internet home accesses in Austria. We are > trying to draw a complete picture of all ISP attributes to get an > overview what the current status is and how it may change in the > future. > > We collected already a lot of data of bigger ISPs but missing > information about smaller ones. Do you think it might be possible to > provide us measurement results of such ISPs? We're happy to help, but in order to do so we'll need to understand what specific measurement results or ISP attributes you're interested in. Best, Christian From brian at interlinx.bc.ca Sun Feb 26 21:25:59 2012 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 27 Feb 2012 00:25:59 -0500 Subject: [Netalyzr] upstream buffering test Message-ID: <4F4B13E7.9020002@interlinx.bc.ca> Hi, I have tried running your netalyzer on my network here and I want to verify the upstream buffering results. I run QoS here on my network and see quite stable ping times while I saturate my upstream bandwidth. During such a test I am doing: $ scp a_big_file $host and while doing that I run "mtr $host" to watch the jitter of each hop along the path. $host is 9 hops away and usually about 25ms +-3-5ms. While I'm scp'ing that big file (about 17MB) the standard deviation for most hops on the path to $host remains in the 5-10ms range which about the same whether the upstream is saturated or not. So my question is, how is netalyzer testing my upstream buffering such that it's seeing a second or more of buffering when I'm not seeing it using the above test? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20120227/a1313dec/attachment.bin From nweaver at ICSI.Berkeley.EDU Mon Feb 27 05:19:40 2012 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Mon, 27 Feb 2012 05:19:40 -0800 Subject: [Netalyzr] upstream buffering test In-Reply-To: <4F4B13E7.9020002@interlinx.bc.ca> References: <4F4B13E7.9020002@interlinx.bc.ca> Message-ID: <0701F166-1DCD-492D-8BF3-610979E829B7@icsi.berkeley.edu> On Feb 26, 2012, at 9:25 PM, Brian J. Murrell wrote: > Hi, > > I have tried running your netalyzer on my network here and I want to > verify the upstream buffering results. > > I run QoS here on my network and see quite stable ping times while I > saturate my upstream bandwidth. During such a test I am doing: > > $ scp a_big_file $host > > and while doing that I run "mtr $host" to watch the jitter of each hop > along the path. Excellent! > > $host is 9 hops away and usually about 25ms +-3-5ms. While I'm scp'ing > that big file (about 17MB) the standard deviation for most hops on the > path to $host remains in the 5-10ms range which about the same whether > the upstream is saturated or not. > > So my question is, how is netalyzer testing my upstream buffering such > that it's seeing a second or more of buffering when I'm not seeing it > using the above test? Because its a deliberately crude test that only works on FIFO buffers: It consists of a full rate UDP flow (it basically is in continual exponential ramp-up) which measures the increase in latency during the last 5 seconds of the 10 second test. If you did not have the active queueing, you would see 1s of latency, but since you have active queueing on the bottleneck buffer, this test reports the queue as being big (it is, for a single stream) but it doesn't affect the latency on your network under load. From brian at interlinx.bc.ca Mon Feb 27 06:02:00 2012 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 27 Feb 2012 09:02:00 -0500 Subject: [Netalyzr] upstream buffering test In-Reply-To: <0701F166-1DCD-492D-8BF3-610979E829B7@icsi.berkeley.edu> References: <4F4B13E7.9020002@interlinx.bc.ca> <0701F166-1DCD-492D-8BF3-610979E829B7@icsi.berkeley.edu> Message-ID: <4F4B8CD8.9080401@interlinx.bc.ca> On 12-02-27 08:19 AM, Nicholas Weaver wrote: > > Because its a deliberately crude test that only works on FIFO buffers: It consists of a full rate UDP flow (it basically is in continual exponential ramp-up) which measures the increase in latency during the last 5 seconds of the 10 second test. Can it not be made to more accurately reflect the actual situation then? > If you did not have the active queueing, you would see 1s of latency, but since you have active queueing on the bottleneck buffer, this test reports the queue as being big (it is, for a single stream) but it doesn't affect the latency on your network under load. Ultimately though netalyzer is making people thing they have a bufferbloat problem when they don't, if I'm understanding all of this correctly. I just wonder if the test cannot be made to better reflect the boatedness of the buffer in question so that people are not chasing ghosts. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20120227/07b76b05/attachment.bin From christian at icir.org Wed Feb 29 17:09:50 2012 From: christian at icir.org (Christian Kreibich) Date: Wed, 29 Feb 2012 17:09:50 -0800 Subject: [Netalyzr] New features! Message-ID: <4F4ECC5E.1050909@icir.org> Hi all, We have just released a substantial Netalyzr update. First and foremost, we've made Netalyzr a whole lot faster. After analyzing the test durations experienced by our users, we increased parallelization in test executions and optimized a number of timeouts, all with the goal of reducing execution time. Netalyzr now runs approximately twice as fast and a session typically completes in under two minutes. We have also improved the level of control you have over the amount of information displayed on the test results page. You can now expand and collapse details of individual tests, instead of entire test categories. In the initial results display, this ability lets us show details only for tests that exhibited irregularities or problems, while keeping all other results collapsed. See the help page for more information: http://netalyzr.icsi.berkeley.edu/help.html Several users reported that Netalyzr's bandwidth test at times crashes their DSL modems, causing a temporary loss of network connectivity. This outage could cause Netalyzr sessions to stall at the result upload stage. We now attempt result uploads several times while waiting for connectivity to resume. You may have noticed that Netalyzr tries to use the UPnP protocol to identify the model and manufacturer of your gateway device. In the future, this information, combined with tracking outages induced by bandwidth tests, will allow us to identify particularly fragile devices. For researchers we now provide better ways to label Netalyzr sessions and obtain the resulting set of result data. Netalyzr has long provided a command-line interface, but no convenient way to obtain test results for subsequent processing. In addition to the regular HTML summary we now also provide the session results in JSON format. To obtain a session's results in JSON, use this URL schema: http://netalyzr.icsi.berkeley.edu/json/id=[session ID] For example, here's our demo session in JSON: http://netalyzr.icsi.berkeley.edu/json/id=example-session Note that we're still in the process of improving the details reported for individual tests. We'd love to hear your feedback and suggestions. If you're a researcher providing customized ways for people to run Netalyzr, you can now arrange to have all resulting sessions automatically tagged with a string identifying your experiment and retrieve the list of resulting sessions in near-real-time, likewise in JSON format. If you're interested in this feature, please contact us. As we're approaching the 500,000 session mark, we'd once again like to thank our users for their ongoing support and use of the Netalyzr service. We couldn't do this without you! Best, Christian, Nick & Vern