none
closesocket() is very slow RRS feed

  • Question

  • Hi

    I am upgrading our product from 500MHz x86 cpu board running CE6 to 1000MHz ARM Cortex A9 running Compact 7.
    ARM is a lot faster according to all other tests that I have made but there is a problem with IEsample.exe.
    WCE7 runs javascript fast but loading several pages is very slow, especially from local server.

    I have made test client to find the problem and looks like problem is in behaviour of closesocket() function.
    Client is very simple
    - get socket
    - connect to server
    - send request
    - read response (about 4700bytes)
    - close socket

    I have tested with four types of sockets
    1) non blocking
    2) blocking with lingeronoff=1 and linger=2
    3) blocking with lingeronoff=1 and linger=0 (hard close)
    4) default behaviour without mode changes after socket()

    Response times have some variance but conclusion is clear.
    WCE7 closescoket() is slow when file is asked from remote server and very slow when local server is used.
    I assume that browser component uses sockets in default mode because the delays that I have measured with javascript code are about same as delays with closesocket().

    I call closesocket() after whole file has been received so there is no pending send/rec data.

    Below is a table of results

    - CE7 client reads from CE6 server
    non blocking socket: 34ms
    lingering socket: 41ms
    hard close: 18ms
    default mode: 13ms + 130ms for closesocket()

    - CE7 client reads from local server server (127.0.0.1)
    non blocking socket: 16ms
    lingering socket: 11ms
    hard close: 12ms
    default mode: 10ms + 400ms for closesocket()

    - CE6 client reads from CE7 server
    non blocking socket: 19ms
    lingering socket: 12ms
    hard close: 12ms
    default mode: 15ms

    - CE6 client reads from local server server (127.0.0.1)
    non blocking socket: 40ms
    lingering socket: 6ms
    hard close: 11ms
    default mode: 6ms

    Wednesday, May 2, 2012 1:05 PM

Answers

  • Thanks for your answer.

    Looks like board works better with CE6 BSP, I will start working with it.



    • Marked as answer by Jari Aalto Monday, May 7, 2012 12:20 PM
    • Edited by Jari Aalto Monday, May 7, 2012 12:20 PM
    Monday, May 7, 2012 12:19 PM

All replies

  • I can't fix this; it sounds like a performance issue in the TCP stack (CE7 reportedly has many of these). For the device <--> device communication, capturing the packets would be useful. When you do a closesocket(), you'd expect a packet to be sent from the closing device with the FIN bit set. The other end of the connection should respond with ACK and FIN (possibly in two separate response packets), followed by an ACK and FIN from the closing device. At that point, both ends should disassemble the socket.

    For support from MS, you'll want to monitor the turnaround times for each of these steps. For example, if the closing device doesn't send the first FIN for 200ms, that tells you something. If the responding device ACKs the first FIN, but doesn't send its own FIN, that tells you something else.

    If you are using the same hardware for CE6 and CE7, check the interrupt handling in the Ethernet driver to be sure there's not some difference affecting you.

    Paul T.

    • Marked as answer by Jari Aalto Monday, May 7, 2012 12:17 PM
    • Unmarked as answer by Jari Aalto Monday, May 7, 2012 12:17 PM
    Thursday, May 3, 2012 6:55 PM
  • Thanks for your answer.

    Looks like board works better with CE6 BSP, I will start working with it.



    • Marked as answer by Jari Aalto Monday, May 7, 2012 12:20 PM
    • Edited by Jari Aalto Monday, May 7, 2012 12:20 PM
    Monday, May 7, 2012 12:19 PM