Luigi Rizzo wrote: > are you sure you aren't running out of mbufs ? > netstat -m should tell you. No, its not mbufs (such messages are shown on the console I believe and I haven't seen them; also, running netstat -m states there's plenty of buffers remaining). > Additionally, note that the 250ms of delay are probably way too much > for your config (you are adding 250ms each way, which makes a 500ms RTT, > not accounting for transmission times -- i think normal values here > are more like 150-200ms rtt), and possibly irrelevant given how > large your queues are -- a full-size packet is 12000 bits or 200ms, > you can have up to 20 queued... Oh sorry, I pasted from a wrong shell script. I've been experimenting with different values and am considering settling at 75ms, queue of 5. I'm still not sure: how does the number of buckets influence the operation? I don't think it's clear to me how would such large queues produce my errors (connection reset by peer & broken pipe). Is this reasoning correct: in the above case, 200ms*20 = 4s, so in the worst case the packet from the end of a queue will travel 4s until it reaches its destination. Is 4s enough for a timeout of some sort? I've tried running on a different machine, running 4.9-release, and there I also get this error (in large numbers): Error: socket: address is unavailable.: Can't assign requested address -- C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void.Received on Mon Apr 26 2004 - 15:25:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:52 UTC