On Tue, Feb 7, 2012 at 9:00 PM, James Carlson <carlsonj@xxxxxxxxxxxxxxx> wrote: > Srinidhi M wrote: >> Could you please let me know, which module in TCP/IP is consuming more >> time than UDP? How can we reduce packet processing time when sending >> through TCP stack? Please let me know your thoughts. > > Are you sure you wanted to post this message on the Linux PPP mailing list? No. I do not know the exact mailing list name for these type of questions. First, I mailed to main kernel, but, I did not get any response. So, I mailed to this group. Please let me know the mailing list name for posting these type of questions. > Anyway, without knowing a lot about your application, how you're > measuring things, and what environment you're running in, it's a little > hard to guess at what sort of change you might require. But I'll give > it a try. Just using "top" command. No other commands. > Have you tried setting the TCP_NODELAY option and/or redesigning around > TCP_CORK? No. We are not using these options. We will try to change the options for setsockopt call. > If your application does a lot of tiny write(2) calls, you > will sometimes see RTT delays in delivery. This is normal, and it's > something that the stack does in order to protect the network against > misbehaving (or just inefficient) applications. You can disable it in > order to force a write(2) to result in a transmission ... but be careful > if you do this, because doing so can result in a flood of tiny packets > if you (say) write a byte at a time. > > Have you considered SCTP instead? If you have a message-oriented > protocol (rather than a stream-oriented one), and you need reliable > delivery, SCTP may be a better option for you than TCP. We will think about these, later. Thank you very much for your reply. Regards, Srinidhi M. > -- > James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
