From: Steven W. <swi...@us...> - 2000-05-27 12:42:48
|
Paul W Cassella wrote: > > Steven Wilcoxon wrote: > > > Looking at this portion, you always enqueue every packet to be sent. > > Right. In the next version of the patch that I posted, on the 19th, I > also updated node_enqueue to try to send everything it was given if > there's nothing enqueued for that node already, so there should be no > performance impact. Actually the feature I was looking for would require everything to be buffered to reduce the number of packets sent. The patch from the 19th (which I had overlooked) would start getting complicated to implement both together. I like the KISS principle. The two area of overhead I see are the GSList for counting and the memcpy/memmove's. > Hmm. Now that I look at the code again, the sendto_one() in CVS will > always call write(), even if there's previous data enqueued, which would > be bad if we've sent part of an enqueued packet. > > > What I was thinking about was buffering every packet (specially PINGS!) > > being sent and not sending until the buffer was full enough or a certain > > amount of time had passed. The idea is to reduce network traffic by > > reducing the amount of packet overhead we suffer by sending lotsw of > > little packets. > > > Feedback from anyone? Is this idea too simple to be true? What about the > > timeout feature? > > The gain may not be significant, because TCP will use Nagle, which means > that if the link is slow or near capacity, the cases where this change > would help, it will do something similar. (See RFC 896) I suspect that PPP/modem users would benefit more then others. They have less overhead but are the most congested. > It probably wouldn't be hard to do anyway, in order to actually measure > it: change node_enqueue to set a timer if there's not enough data yet, > have that timer do the gdk_input thing, and have that function send and > then un-register itself, but also set a new timer if there's still data to > send. Doing it simple, it's the actual measurement to see if it made a difference thats hard at my end. I'm not setup to simulate a slow network connection. Note: I noticed that your sent packet counter won't keep an accurate count and can leak memory if the entire buffer is not sent at once. You're memorizing where in the bufer each packet ends (via offset/sq_pos). If the entier buffer is not written, everything gets slid forward. That means we should either count the packet as it's buffered or memorize the length of each packet (and each time the buffer is totally empty, make sure the GSList gets emptied also). > -- > Paul Cassella :: Doctor Who: He's back, and it's About Time. > for...@cm... :: http://www.contrib.andrew.cmu.edu/~pwc S.W. |