Alex Bligh wrote:
--On 15 October 2004 13:33 +0200 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
However, the cause can also be rate limiting. Rate limiting is deadly for TCP performance so it shouldn't be used on TCP traffic.
Add "unless appropriate shaping is performed prior to the rate-limiting with the parameters carefully tuned to the rate-limiting"
You can also see an effect similar to rate-limiting from inadequate buffering where there is a higher input media speed than output.
The following link provided a great overview of tcp throughput http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm
I can't remember what the tool is now, but there used to be a tool which worked like ping but sent a udp stream at a given rate per second and told you about packet drops, and also allowed for some parameter to be tweaked to give stochastic variation in interpacket delay (i.e. massive jitter). You could use this to show inadequate buffering on gigabit interfaces where a 2Mb/s stream would get through, but if you wound up the jitter sufficiently, a whole burst of packets would arrive together and a gigabit interface with (deliberately) misconfigured buffers would then drop packets.
Alex
netiq's qcheck (the artist formerly known as ganymede) is a utility we commonly use to prove to customers that they are indeed receiving correct throughput. http://www.ixiacom.com/products/performance_applications/pa_display.php?skey... -Gordon