|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: "Fred Baker (fred)" <fred@cisco.com> To: "valdis.kletnieks@vt.edu> <valdis.kletnieks@vt.edu" <valdis.kletnieks@vt.edu>, Luqman Kondeth <luqman.kondeth@nyu.edu> Date: Tue, 14 Aug 2012 20:22:23 +0000 In-Reply-To: <33047.1344944422@turing-police.cc.vt.edu> Cc: "menong@mengon.net" <menong@mengon.net>, "nanog@nanog.org Operators' Group" <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org On Aug 14, 2012, at 4:40 AM, <valdis.kletnieks@vt.edu> <valdis.kletnieks@vt.edu> wrote: > On Tue, 14 Aug 2012 15:32:47 +0400, Luqman Kondeth said: >> Is anyone aware of any public IPerf servers in the middle east or close >> by?(Europe) or anywhere that can do udp?. I have a 1gbps Internet link >> which I've been asked to show that it has 1gbps download speeds. >=20 > First thing that comes to mind is remembering the difference between > end-to-end throughput and the throughput across one link in the chain. > If you really need to validate the one link, you probably need to get som= e > system to inject packets at the other end of the link. You might take a look at http://www.ameinfo.com/broadband_speed_checker/. I= can't say I know anything about them beyond what Google says they say abou= t themselves, but they claim to be able to test such things. Let me put hands and feet on what Valdis points out. With a gigabit interfa= ce, you are able to carry about 83,333 1500 byte packets per second. If you= 're trying to download a file from, say, an Akamai server, TCP will allow y= ou to move one window per round trip. If you are using standard window scal= ing (e.g., your window is in the neighborhood of 65,000 bytes), you can ach= ieve 1 GBPS only if your round trip time is in the neighborhood of half a m= illisecond. Outside of a data center, such an RTT is Really Unusual. The ob= vious alternative is to use a larger window scaling value: if your RTT is 2= 0 ms, scale up by at least 40 times, which is to say a shift of 6 bits for = a multiplier of 64. Even with that, TCP's normal way of operating will prev= ent it from using the entire gigabit until quite a way into the session. Yo= u'll need a Really Long File. The reason you get such an interface, I would imagine, is that you have a l= arge number of users behind that interface and/or you are routinely moving = a large amount of data. You can make it easier for yourself if you get a la= rge number of your users to each download something really large all at the= same time, and measure the performance at the interface. Or, and this is a lot easier but involves math, you can turn on wireshark/N= etflow/tcpdump/something that will record actual throughput, and download a= file of your choosing. Later, offline, you can determine that you moved so= me number of bytes within some unit of time and the ratio is 1 GBPS, althou= gh you only ran the test for 20 ms or whatever. Even those have caveats; upstream, you're sharing a link within your ISP wi= th someone else. It's just possible that while your link will happily carry= 1 GBPS, at the instant you test, the upstream link gets hit with some heav= y load and AT THAT INSTANT only has 750 MBPS for you, making your link look= like it only supports 750 MBPS. That would be possible in any of the tests= I just mentioned. What Valdis is suggesting is to have someone at your ISP literally connect = to their router and send you traffic at a 1 GBPS or faster rate for a perio= d of time, while you record that with wireshark/netflow/etc. You can then d= o the math and record the result.=
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |