[zeromq-dev] Interesting kernel development?

[Martin Sustrik]

Jannes Faber wrote:
 > Martin,
 >
 > I'm no kernel hacker and didn't actually look at the code yet. I'll 
try to do that later. But i was under the impression this patch would 
only has an effect when there is already data waiting in buffers anyway, 
not that it is going to sleep for x microseconds or something.
 >
 > Also as i understood it, this talks about sending the data to the 
network card but only about the in-memory and system call overhead part.
 >
 > I doubt that you can measure a latency increase when the system 
gathers a few kilobytes of data that is already waiting in memory and 
sends that to the network card in one go, instead of doing that for 1500 
bytes at a time. With the effect of greatly lowering the number of 
system calls and thus even reducing the latency for any piggy backing data.
 >
 > But as I said I could be completely misunderstanding this whole 
discussion.

I had just a very brief look at the discussion and I haven't checked the 
code myself, so I believe you may be perfectly right. If there's no 
waiting for more data involved, batching tends to improve throughput 
while not making latency worse.

 > Either way, I brought it to your attention so that, if you feel that 
it's worthwhile, you could maybe test it for yourself. If it does affect 
latency, now is still the chance to jump into the kernel list and report 
it. For example to request for this new behavior to become optional by 
/proc option or on application request.

Unfortunately we don't have enough resources right now to do much of a 
kernel hacking, however, if there's anyone on the list who would like to 
check this out, any results would be highly appreciated!

Martin