Matthew Dillon wrote: > Terry, I don't think you quite understand the problem. From the server's > point of view NOTHING IS WRONG. Any non-USB-ethernet client would have > no problem whatsoever with the large number of small packets that the > server is sending, nor can the server just arbitrarily decide that 8 > packets is too much, because doing so screws up bandwidth over long-haul > links. The server can not arbitrarily limit its window size because > the problem only occurs with small packets. So how is the server > supposed to figure out the difference between between normal packet > loss and packet loss due to the client having a USB adapter and not > being able to handle lots of tiny packets?
Uh, Matt, the window size is a negotiated value between the server and the client. What the server wants is irrelevant, if the client wants a smaller window, since the value is MIN(server_wants,client_wants). So if the problem is that the FreeBSD USB<->ethernet connected client can't handle that many outstanding packets, then the place to fix it is _obviously_ the FreeBSD USB<->ethernet driver. Julian did similar work already in the InterJet in order to control the advertised window size on the client, and therefore do what the AltQ code is supposed to do, but without congesting the intermediate router. > New-Reno might be able to help but it would have to be hacked up a bit > to send a double ack to the server to force the server to reduce its > congestion window. New-Reno is a mess and I am not volunteering to > hack it up more. The Rate-Halving algorithm is used with FACK in order to halve the window size in the presence of failures (like the one being seen here). Again, the place that this should happen is on the client, not the server. I don't understand why you think this is a server problem, when it is not the server hardware where the failure is occuring? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
