On (2013-04-10 00:01 +0200), Benny Amorsen wrote:
> Yes, you can in theory cause microbursting of UDP if you want. I am just
> not sure which tool I would use to do that. Typical UDP tests like iperf
> attempt to do perfect timing of packets so bursts are avoided, and they
> seem to do a fairly go
Saku Ytti writes:
> Obviously microbursts can (in both TCP or UDP) scenario happen without any
> background traffic. Consider you're connected to 1GE port, testing another
> host in 100M port, if you limit your rate to 100M, you still causes the
> 100M port to congest, as incoming rate is always
On (2013-04-09 15:03 +0200), Benny Amorsen wrote:
> There will only be packet loss if you test while there is background
> traffic on the link. If the only load is a perfect stream of UDP
> packets, the buffers will not fill and no packets will be dropped.
This is completely L4 agnostic though, T
Saku Ytti writes:
> Microbursts will drop UDP has well, you'll experience this as packet loss
> just the same, so you want to find value which has 0 packet loss. This same
> number will indicate when TCP will start dropping (and reducing
> window-size)
There will only be packet loss if you test
On (2013-04-08 23:29 +0200), Benny Amorsen wrote:
> UDP tests can be too generous on the network. A stream of perfectly
> spaced UDP packets will not show problems with microbursts. Almost all
> bulk transfer protocols are TCP, so it is important to test with TCP.
Microbursts will drop UDP has we
Saku Ytti writes:
> This highlights the fact that you should not test network with TCP, always
> UDP, with TCP there are so many things to go wrong which are not network
> related, UDP is much more reliable indication that problem actually may be
> in the network.
UDP tests can be too generous o
On (2013-04-08 13:44 +0200), Benny Amorsen wrote:
> In my experience, you cannot trust iperf to not override the OS window
> size. Explicit -w seems to be the only reliable solution.
I remember one test I had, not long ago, where any -w value fared worse
than no -w value.
I never tsharked it, I j
Saku Ytti writes:
> make sure with tshark what your actual window size is, don't trust iperf.
> Best thing is to configure OS TCP stack to window scaling and dont touch
> iperf window settings, I don't know why, but they just seem to break stuff.
In my experience, you cannot trust iperf to not o
Use TCP Optimizer to increase WSCALE/RWIN on Windows hosts to achieve better
TCP perf
http://www.speedguide.net/downloads.php
Thanks
Alex
- Original Message -
From: "Saku Ytti"
To:
Sent: Monday, April 08, 2013 8:13 AM
Subject: Re: [j-nsp] Speed
On (2013-04-08 03:46 +02
On (2013-04-08 03:46 +0200), Johan Borch wrote:
> of a single session with a RTT of only 8ms? The performance is the same if
> I use 2 switches and the clients directly connected as if i use routers
> between. Any idea what it could be?
bw * delay = window
so
window / delay = bw
64k*8 / 0.008
Hi
This issue is somewhat off topic :)
I have a 1Gbps wavelenght from a supplier (1310), the RTT is about 8ms and
whatever I do I can't get more than 25-40 Mbps from a single session
(iperf, 64K ws, 2 x windows 8, same result with linux clients, same with
http and ftp tests). I can get up to 1Gbp
> Did you hard-code the speed/duplex setting on both the Juniper and Cisco
switches, or just the Juniper's?
> We've been happy with auto-nego'ing all connections, including with
upstreams. Life has been much easier going that route. I can't remember the
last time anything good came out of hard-cod
On Tuesday 23 March 2010 08:50:01 pm Paul Stewart wrote:
> When I did the configuration I set the ether-options for
> 100/full ... most of the ports are facing Cisco
> switches. All the ports that were hard coded would not
> come up at all - the minute I removed the ether-options
> they came
Hi folks...
We just cut in another couple of EX4200's into production overnight. These
are the first deployments that don't have pure GigE ports - several ports
100/full.
When I did the configuration I set the ether-options for 100/full ... most
of the ports are facing Cisco switches. All
14 matches
Mail list logo
