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 good
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
Saku Ytti s...@ytti.fi 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
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, TCP
Saku Ytti s...@ytti.fi 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
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 =
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 s...@ytti.fi
To: juniper-nsp@puck.nether.net
Sent: Monday, April 08, 2013 8:13 AM
Subject: Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi 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
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
Saku Ytti s...@ytti.fi 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
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
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
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.
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 up
14 matches
Mail list logo
