| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4B216A61.7020704@hp.com> Date: Thu, 10 Dec 2009 13:38:41 -0800 From: Rick Jones <rick.jones2@...com> To: Eric Paris <eparis@...hat.com> CC: netdev@...r.kernel.org Subject: Re: [PATCH] net: export the number of times the recv queue was full Eric Paris wrote: > We got a request in which a customer was trying to determine how often their > recieve queue was full and thus they were sending a zero window back to the > other side. By the time they would notice the slowdowns they would have all > empty receive queues and wouldn't know which socket was a problem. Wouldn't a tcpdump command with suitable filter expression on the window field of the TCP header do? > It also > allows them to find the sockets in which they need to up the recv queue size > rather than doing it for all sockets across the box. Doesn't Linux by default "autotune" the socket buffers? (Or perhaps is that how they got zero windows from time to time anyway?) Or does this customer's application(s) bypass that by making explicit setsockopt() calls, and presumably have a way to tell the application(s) on a destination by destination basis which connections to increase? More generically, zero window means the application isn't calling read/recv fast enough right? Or is it "known" that the traffic the applcation is receiving is bursty and this isn't a sustained overload situation? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists