> You figured it out correctly. However at that moment TCP flow control > would kick in and save you from local packet loss so to say.
Hi, Thanks for the response, but you have actually confused me more. It is my understanding that TCP doesn't have flow control (i.e., local to the node), it has congestion control, which is end-to-end across the network. So it is entirely possible to drop packets locally in this method with a highband width, high latency (so called "long-fat") connection. For example, if there were a giga-bit/second link, with a latency of 100 miliseconds rtt, and window scaling set to 14 (the max), tcp could in theory open it's congestion window up to 2^16*2^14 or 2^30 bytes, which could be ACK'd more quickly than the net.inet.ip.intr_queue_max queue would allow for, causing packets to be dropped locally. Basically, the bandwidth-delay product dictates the size the buffer/queue should be, and in the above (extreme) example, it should be 0.1s*1Gb/s=12.5MB which is larger than the 50 packets at 1500 bytes each that you get with net.inet.ip.intr_queue_max=50. In otherwords, this is the reason for the net.inet.ip.intr_queue_drops counter, right? I'm surprised that more of the tuning guides don't suggest increasing net.inet.ip.intr_queue_max to a higher value - am I missing something? The equivalent setting in Linux is 1000, and Windows 2k appears to be 1500 (not that this should be necessarily taken as any sort of endorsement). If my understanding is incorrect, please let me know. In any case, thanks for the help (and thanks to those that have replied off list). - Rob . _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"