Please excuse me if this is off-topic. I'm needing some expert TCP
analysis and not sure where to turn. I'm experimenting with CAR
rate-limiting using the Cisco IOS. I am using Iperf to test TCP
throughput, PRTG to poll the Cisco interface traffic levels each second
and Wireshark to
If the normal burst value is too low you may always be exceeding the
normal burst limit. You can do a show int rate-limit to look at
current burst values.
Phil
On Jun 19, 2008, at 12:00 PM, Christopher Hunt wrote:
Sorry,
The rate-limit statement that results in 0.2mbps throughput is:
Phil,
I do understand that the lower burst (5000) is too low for production
and wouldn't use it. However, I can see that in a 10 second transfer I
can only push about 248Kbytes:
[EMAIL PROTECTED] ~]# iperf -c 10.180.55.211 -P 1 -i 1 -t 10
On Thu, 19 Jun 2008, Christopher Hunt wrote:
Sorry,
The rate-limit statement that results in 0.2mbps throughput is:
rate-limit input 1000 5000 5000 conform-action transmit exceed-action
drop
Those burst values appear to be far below the recommended values for most
cases. See the
Antonio,
Thanks for the reply. I understand that those values are not
recommended and in fact i do not use them outside of the lab. I am,
however, struggling to understand how TCP reacts to very very low burst
levels. What mechanism is causing such low throughput as the
tcp_receive_window
[ i deleted some of this thread already am too lazy to search archives
to see if you posted tcpdumps, i'll go off what's in my mailbox. ]
On Thu, Jun 19, 2008 at 02:22:39PM -0700, Christopher Hunt wrote:
Thanks for the reply. I understand that those values are not
recommended and in fact
Bill, Sake et al.,
Thanks for taking the time to check into this. I've posted a zip
containing the orginal .pcap/.cap files from both ends of the test plus
the .txt translations and also a MS Word document containing the router
output, testing results etc. The file is at
On Thu, Jun 19, 2008 at 03:07:27PM -0700, Christopher Hunt wrote:
I am familiar with TCP's concept of Slow Start, but my understanding
is that it is the RWIN that is slow to start. The packet does show the
first packet as 24 Byte payload, but even then the client RWIN is 5888
(scaled
Bill,
I am starting to see. I also realize now that the
TCP_congestion_window (cwnd) is not the same as the RWIN. The is like
the RWIN for the slow_start state. The cwnd value is not in the packets
themselves (forgive me if you already know this. Posterity may not...)
is best inferred
On Thu, Jun 19, 2008 at 04:16:19PM -0700, Christopher Hunt wrote:
It would appear from the sender's counters and from the snmp checks
on the router interface that the interface never hits 10mbps even for a
second, but the rate-limiting counters do show tail drops. I guess it is
difficult
10 matches
Mail list logo
