On Jun 20, 2:13 pm, Ross Vandegrift <[email protected]> wrote: > On Sat, Jun 19, 2010 at 02:16:42PM -0700, cd34 wrote: > > I did a quick run of ab, several requests came in at 3.1 seconds. I > > don't know what sort of network they are running, but 3 seconds seems > > very similar to an arp table rebuild in certain switches. When enough > > machines are put on a network, it overflows the 8192 record tcam (or > > whatever the limit is on that switch), which causes it to need to > > rebuild the arp tree as it rediscovers. Until each machine is > > rediscovered, they are basically 'off-net'. > > Such ARP table exhaustion would typically be steady-state in a > datacenter environment - a complete and total meltdown, never > recoverging. 3 seconds wouldn't be nearly enough time for such a > thing to wring out. Also, TCAM isn't used for ARP entries - lots of > things are stored in TCAM, but ARP isn't one of them.
my error. We don't run Cisco gear. Our client modified: sdm size ip-adjacency 8192 to sdm size ip-adjacency 12288 which fixed their 3 second pauses on their network. I had thought they claimed it was a tcam setting, but, in reviewing my notes, I was wrong. The symptom was identical to what I was seeing when I was fetching from his network. I am still getting 6%-8% packet loss from two separate locations to his current host on their inbound router. While ICMP is a bad indicator of issues, the packet loss did coincide with the throughput issues while downloading. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
