Re: delay on select()

From: Andrei Voropaev (avorop_at_mail.ru)
Date: 12/30/03

  • Next message: mallik: "Re: DW_FORM_strp pointing outside of .debug_str section" 
    Date: 30 Dec 2003 08:11:54 GMT

    On 2003-12-30, David Schwartz <davids@webmaster.com> wrote:
    >
    > "Shuqing Wu" <swu@sympatico.ca> wrote in message
    > news:rF1Ib.3593$Vl6.936305@news20.bellglobal.com...
    >
    >
    >>I execute an distributed application on LAN.
    >> When a cleant send( ) some message to server, it
    >> takes about 100 milliseconds to select( ) for that
    >> message. Is it normal?
    >
    > Yes.
    >
    >> What is the possible reason
    >> for that?
    >
    >
    > The client isn't being smart about the amount of data it passes to the
    > stack at a time. When the stack sees the first send, it has no idea there's
    > going to be a second, so it sends the data immediately. When it sees the
    > second send, it has no idea there isn't going to be a third, so it delays
    > the data by about 200 milliseconds or so.
    >
    > The solution is for programs that send data over TCP to properly manage
    > their transfer of data from the application to the network stack. For
    > example, if you have to send three lines of data at the same time, send them
    > in one call to 'send' or 'write' rather than in three. Here, 'at the same
    > time' means 'without having to wait for anything in-between them'.

    This would work, but makes life really miserable. Not always it is
    possible to join things into one package. Really you'd have to
    reimplement buffering that system already implements. Better to use
    socket options in this case. (Though I'm not sure about being portable
    here). Anyway. On Linux man 7 tcp lists TCP_NODELAY that
    allows immidiate sending of data in the TCP buffers, the reverse of it
    is TCP_CORK that allows to assemble package in system buffers and then
    send it as one.

    Andrei

  • Next message: mallik: "Re: DW_FORM_strp pointing outside of .debug_str section"

    Relevant Pages

    • Possible 2.4.18 ipv4 memory leak?
      ... I'm digging into the ipv4 tcp stack of 2.4.18 trying ... a situation where this is both high bandwidth and high latency ... My guess is the tcp/networking stack is not freeing up skb's or something. ... gives you low bandwidth and high latency. ...
      (Linux-Kernel)
    • Re: [PATCH v2 04/13] Connection Manager
      ... There is no SW TCP stack in this driver. ... TCP/IP/10GbE in HW and this is required for zero-copy RDMA over Ethernet ...
      (Linux-Kernel)
    • Re: Reentrant problem with inet_ntoa in the kernel
      ... I use google mail web interface to post messages, ... that stack space is a limited resource in the ... which means adding those buffers can hit quite hard. ... but is the kernel stack too small to contain another 32 bytes at most? ...
      (freebsd-net)
    • Re: Setting size limit of data while reading or writing from sockets
      ... The receive buffer is not limited to application data. ... They apply to TCP as well. ... the stack may wait for the application, ... Since he has no idea what window TCP advertises to the other end ... ...
      (comp.unix.programmer)
    • Re: Reasons for a buffer or RAM
      ... > You don't need to have your buffers on the stack to make it recursive. ... I think I can get old mmap working for "MAP_PRIVATE" ... always have a zero-length file, ...
      (alt.lang.asm)
    Loading