On Thu, 2009-12-10 at 13:38 -0800, Rick Jones wrote:
quoted text
> 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 could as a post processing measure be used to find this situation.  I
believe they want a more 'on the fly' method.

quoted text
> > 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?

I believe their intent is to explicitly set the size larger for the
sockets they learn that their application needs it for and smaller for
those it knows it doesn't.

quoted text
> 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?

My understanding it that that is correct, it is not a sustained load
situation so looking at the rx-queue after the fact is useless for
discovering where they are getting overloaded.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html