On 15 May 2003, Paul Slootman <[EMAIL PROTECTED]> wrote: > I can't really see that doing smaller writes will lead to packets being > padded, unless you're doing really small writes (ref. the ATM 48-byte > packets); the TCP and IP headers will always be added, which means that > the extra overhead of those will have a larger impact than any > padding. > > So, I'd suggest that 1024 isn't that bad a number for all cases; it'll > fit comfortably into most MTU sizes, and for dialup PPP it'll be split > into two packets without that much overhead. If not concerned with the > dialup PPP case, I'd go for something like 1400.
Of course a write() does not necessarily correspond to a TCP frame, which does not necessarily correspond to an IP packet. But nevertheless I would suggest avoiding writes that are this short. In addition to the headers that Paul mentioned, there are other per-packet costs such as Ethernet leadin and trailer times, and the hardware, interrupt and OS overhead for processing packets. Consider also that some people use rsync on fast networks, and they won't appreciate small packets *or* getting more system calls to process a given amount of data. Needlessly causing each packet hold 30% less data than it normally would is very wasteful. The point of bwlimit is after all to help users have more bandwidth for other applications. Checking for bwlimit after every say 4k I can imagine but below that is dubious. I'm happy to be proved wrong though. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
