Team,
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.
I know this is going to be difficult but thought I’d ask anyway.
Is there any other suggestion for this testing?
thanks
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 some
system to inject packets at the other end of the link.
No, I don't want to test just the link. I want to make sure the path in my
ISP also has enough backplane bandwidth and isn't using some old sup32
and thereby throttling traffic
Still the same problem - if there's a bottleneck upstream of your ISP, you won't
be testing what you think you're testing. (We once hit an interesting corner
case trying to use one of the speedtest.net servers - we had a clear 10G path
out through like 3 AS's in a row, the bottleneck was speedtest.net's server. 
you'll have to forgive me for being the cynical type, but I gave up on
Speedtest the day they reported 146Mbit/sec download over a link which was
hard-wired to 100Mbit/sec full duplex, and later that day they reported
2Mbit from another nearby server to the same box. I figured a stddev of 2
orders of magnitude wasn't going to give me figures accurate enough for my
requirements.
But hey, this is the Internet: ymmv, ianal, lolwut, bbq.
Nick
Is there a speedtest.net-like site you like?
Is there a speedtest.net-like site you like?
The problems can be:
1. Finding one that gives consistent results, as others have already noted.
2. Finding one that is topologically close to you. Me testing from my office in Pittsburgh, PA to a server in Washington, DC isn't necessarily an accurate test if I have to jump through 4-5 different ASs to reach it.
3. Path asymmetry can skew your test results. The path between you and the test server is not necessarily (often isn't) the same as the path from the test server back to you, and problems on the return path might not be as readily visible to you, when you only have access to a full suite of diagnostic tools at only one end.
Sometimes speed-test sites are fine for basic benchmarking, but I wouldn't treat the results as gospel of rely on them alone to prove/disprove whether a provider is delivering the bandwidth I contracted for.
jms
Have you looked at M-lab? XO and Global Crossing(Lvl3) now use this a their primary. XO still has some servers on various nodes, but they only get turned up for testing on a case by case basis. AboveNet has a larger presence in Europe, but no testing servers I've found yet.
J.J. Mc Kenna
Is there a speedtest.net-like site you like?
The problems can be:
1. Finding one that gives consistent results, as others have already noted.
2. Finding one that is topologically close to you. Me testing from my office in Pittsburgh, PA to a server in Washington, DC isn't necessarily an accurate test if I have to jump through 4-5 different ASs to reach it.
3. Path asymmetry can skew your test results. The path between you and the test server is not necessarily (often isn't) the same as the path from the test server back to you, and problems on the return path might not be as readily visible to you, when you only have access to a full suite of diagnostic tools at only one end.
Sometimes speed-test sites are fine for basic benchmarking, but I wouldn't treat the results as gospel of rely on them alone to prove/disprove whether a provider is delivering the bandwidth I contracted for.
jms
Is there any other suggestion for this testing?
As a general tool, I rather like PathTest - it's free and versatile, you just have to have a daemon somewhere on the other end of the circuit (even if that's multiple AS's away) that can deliver sufficient throughput for the test. It's far more efficient than a flash based test. Even a very modest laptop which chokes at 70Mbps in flash can do a few hundred Mbps with it, and anything decent can do a full gig and up.
I realize that doesn't help you find an endpoint in the Middle East to test against, but at least now you have a better tool.
Nathan Eisenberg
You can make your own endpoints, do full BERT and loop back RFC compliant testing for a small investment with PacketExpert from TSI. Reach out for a demo thanks
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 about 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 interface, 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 you to move one window per round trip. If you are using standard window scaling (e.g., your window is in the neighborhood of 65,000 bytes), you can achieve 1 GBPS only if your round trip time is in the neighborhood of half a millisecond. Outside of a data center, such an RTT is Really Unusual. The obvious alternative is to use a larger window scaling value: if your RTT is 20 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 prevent it from using the entire gigabit until quite a way into the session. You'll need a Really Long File.
The reason you get such an interface, I would imagine, is that you have a large 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 large 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/Netflow/tcpdump/something that will record actual throughput, and download a file of your choosing. Later, offline, you can determine that you moved some number of bytes within some unit of time and the ratio is 1 GBPS, although you only ran the test for 20 ms or whatever.
Even those have caveats; upstream, you're sharing a link within your ISP with 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 heavy 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 period of time, while you record that with wireshark/netflow/etc. You can then do the math and record the result.
I come up against TCP window challenges rather often due to the fact
that RTTs between eyeball and content are still between 200ms and 1000ms
for large portions of what eyeballs in Africa would like to consume.
I was trying to quantify these limitations the other day and my
Google-fu was lacking.
Can anyone point me at some resources showing default TCP windows for
the various OSes/platforms, which of them do auto scaling and what the
upper bounds are for scaled windows.
Many thanks everyone for the response. Many people have been kind enough
to offer their iperf servers so I'll be trying the test today.
Now, with regards to the email chain, all of these are very valid points.
My objectives were two fold
a) Test Path throughput through ISP backbone
b)Test my 1gbps Internet link
If the tests in (a) return speeds of anything more than 750Mbps I will be
convinced that both (a) & (b) testing objectives have been met. The best
way to test (a) is to find some ISP that connects to the same tier 1 ISP
as my immediate ISP does.
The reasons I asked for a udp server in Europe was to
1) Take out the tcp LFN problems, delay *bandwidth etc
2) Europe would probably have a server that is geographically closer and
hence have lower latency between server and client. Also it is more likely
to be connected to one of the peering points in London where my ISP
connects as well. Of course, I agree I need to verify all this and ensure
the peering exists etc.
I didn't want to do test (b) in isolation because I've seen a case like
you mentioned below and hence my comment on the SUP32(not really a fair
comment, apologies. I was trying to imply an improperly designed backbone
i.e. using access layer tech for the backbone ). I had an ISP give me
1gbps in UK but one particular path inside the ISP couldn't support that
bandwidth under load. Hence why I was trying to test (a).
I like the idea on using wireshark but wouldn't the LFN problem affect me
with that as well? I assume you are asking me to find a local server in
the region with a very large file that I can download ?
Let me know if my approach is correct.
Thanks
Luqman Kondeth