This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

low tcp/ip

I send data from evaluation board MCB2300 (with LPC 2378 microprocessor)
to a user's PC via Ethernet using TCP/IP protocol.
A program named Ethereal shows that MCB2300 transfers 1024 bytes segment
during 7-8 ms after ACK is received from PC. Why the transfer is so low?
(Program sample is EasyWeb).

Parents Reply Children
  • Two things.

    1) You are not asking the "Keil company" anything. You are asking end users on a forum hosted by Keil. Check the "Support" link in the page header for how to send an official support request.

    2) You are missing my point. This is not a question of 100Mbit or 10Mbit mode. 100Mbit mode means that the bits within a packet has a timing of 100Mbit/s. But that does not mean that a 100Mbit interface can transfer 12.5MB/s. It only says the baudrate inside a packet. Even a PC has a hard time to reach 50% efficiency, i.e. 50Mbit/s effective transfer rates.

    My post was about how many packages the TCP/IP stack can have outstanding, before receiving an acknowledge from the other side. A stack running with only a single packet outstanding will use a stop-and-go mode. One packet is sent. One acknowledge is received. A new packet is sent. In such a configuration, the total transfer capacity will be greatly affected by the ping times, i.e. the turn-around time from that you send a data packet until the acknowledge is received so a new packet can be sent.

    Have you checked if there are any memory or configuration options for number of outstanding packets? Any setting for sliding window? An embedded device does not have as much RAM as a PC, so it can't really run with large sliding windows and if the stack does support sliding windows, it will then be quite natural that the setting is minimized.

  • I create project in Keil uVision.
    Algoritm on board is realized so
    that the TCP/IP stack can have 1 packet before receiving an acknowledge from PC.
    Yes this is no effect. But the question is :
    the board sends next packet only after 7-8 ms. I think that this is slowly or not?

  • "I do not Keil RL."

    I would suggest you consider doing so - Or an equivalent.

    Our tests show performance is very good.

  • Really ? Gladly believe.
    What time will be measured at your miracle test?
    Do me favour:
    1. You run timer at PC and send request to the board
    2. The board wil send 4K to PC after request receiving
    3. PC receives 4K and stops the timer
    4. What is measured time?
    P.S. Data are transfered via Ethernet (TCP/IP)
    Best regards

  • When we were conducting our tests, we transmitted 16Kb blocks.

    Each TCP packet was 1Kb, so there were 16 transmissions.

    It initially took 7.6ms to send the complete 16Kb block.

    By increasing the TCP tick frequency, we could achieve the same transfer in 4.2ms.

    Very acceptable.