We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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).
Are you using the Keil protocol stack? The Keil RL?
If so, what period have you got the TCP maintenance tick set to?
Our tests indicate that it is not a turtle; if you configure it to match your requirements!
Please tell me : What is TCP tick? How can I increase the TCP tick frequency without RL?
The TCP tick is the name given to the TCP internal maintenance call.
In the Keil TCP implementation, it is called by
timer_tick();
So you must call it more frequently.
I set in program: 1. wait max. 8 x 262ms for an ACK (about 2 sec.) 2. max. time to wait for an ACK of a FIN before closing TCP state-machine (about 0.5 s). What is TCP tick frequency?
I DO NOT have Keil RL.I use Keil evaluation kit. Is it possible to program Ethernet controller registers for MCB2300 (LPC 2378)?
"Is it possible to program Ethernet controller registers"
Of course it is.
But YOU need to learn what they do and how to configure them.
Regardless, the delay YOU are seeing is almost certainly not going to be with the way in which the registers have been configured. It is far more likely that YOUR code is not checking the status of the ethernet (and subsequently TCP) reception fast enough.
1.Program EasyWeb include module in which Ethernet controller initialize.This controller is configured using the registers : power, interrupts and so on. Nobody work with this program - is that so?
2. question for Gladys Slavek Each TCP packet was 1Kb, so there were 16 transmissions You wait acknowledge after each transmissions?
The TCPnet tick timer has nothing to to with the data throughput. Timer ticks are only used to update protocol delays. If you call timer_tick() function more often than you should, the TCPnet timeouts will expire sooner. You might have more troubles than the benefits if you are doing so.
For example, the ARP cache entries will also expire sooner. On expiration the ARP module will need to refresh the IP entries in the cache. This would on the contrary slow down the performance in some situations.
If you experience the timer_tick() calling intervals to increase the TCPnet data transfer speed, then maybe you are using the TCPnet in a wrong way.
There is theoretically a chance if you are using TCP socket and using it in the following sequence: - open TCP socket - send data - close TCP socket - open TCP socket - send data - .... When the TCP socket is closed, TCPnet has to wait for the 2*MSL time in the TIME-WAIT state before the socket is really closed. When the TCPnet configuration has enabled more TCP socket, the next one which is idle will be used for the next transaction and so on.
Franc
I see, but I don't use Keil RL.
My program send data throuth Ethernet and TCP/IP. It consists of some modules: tcp module realize protocol ARP,ICMP,IP,TCP and react to developments (receive package, API user's call), ethernet module consist of hardware driver for use EMAC controller, configure registers for write,read,receive and send packages, realized data exchange with EMAC controller.
The problem is : PC receives 4K from the board after request in 40ms. I don't know that I do not so. Timer(on PC) show 40ms = request at PC + sending 4K at board to PC (4 transmissions (TCP packet = 1K)).This is slowly.
Thanks all for ansewers, but problem remain.
"The TCPnet tick timer has nothing to to with the data throughput."
I agree with this.
However, I would say that the TCP stack MUST be called more frequently so that it can poll the incomming packets and process them accordingly.
The way to do this would surely be with the call to:
main_TcpNet();
Increase the frequency of calls to this function, and I would expect to see a proportional increase in throughput - Of course ultimately being limited by the raw ethernet communications.
People! You heard me? I don't use Keil RL. May you tell don't about my problem? More precise: PC and the board connect on local area network.
Stop. Take a deep breath. Everybody can hear you. Nobody knows that answer yet, also because your problem can stem from multiple sources. You must provide more fact-based analysis, to give people a leverage. And be patient.
So you don't use Keil RL.
But the theory of operation is almost certainly similar to that of the protocol stack you are using.
There will be a service call that checks carries out pending transmission, checks for a response and triggers appropriate actions.
Speed up the frequency that this functionality is called at, and you might just speed up your throughput.
Sorry to "invade" this thread, but I don't know why NOBODY replied to mine - see http://www.keil.com/forum/docs/thread13709.asp. I have a similar problem, my transmission rate is quite slow, 10msec maximum rate. I MUST achieve 1msec or less. How can I do? I'm quite sure this is possible, also referring to http://www.keil.com/forum/docs/thread9914.asp But I couldn't find anything to be changed, to improve the rate - all the suggestions were already put in practice. There surely is a missing HW setting.
Ok, I proved I am DEFINITELY stupid - provided a link to the WRONG thread. :P I'm sorry. So, I'm developing a real-time network application UDP based on a MCB-STR9 evaluation board. I implemented a very simple application using the HTTP_demo and the examples on UDP communication provided on the website and in the examples code. It sends very small packets (10 bytes) at the fastest possible rate, without waiting for any acknoledgment. And, I'm testing it with WireShark (=Ethereal). There's not a big problem, it just shows that doesn't matter how small I set the timer tick in the RTXconfig (or NETconfig which anyway can't be smaller than 10msec, and the specifications say to set it the higher the better) settings, the packets are sent at a minimum rate of 1pk/10msec. HOW can I improve the transfer time? The mainTCPNet task is always ready, so I think I can't improve its call frequency without improving the CPU speed, am I right? Speaking about available CPU time, the only thing CPU is doing right now is setting a GPIO port (to set LEDs) and updating the LCD display, that shouldn't keep CPU overloaded. My network is a 100T Ethernet based system. I tested the program quite extensively, and read the documentation, but I didn't find out anything related to my specific case, only this thread: http://www.keil.com/forum/docs/thread9914.asp. But I couldn't find anything to be changed, to improve the rate - all the suggestions were already put in practice. Is there some other suggestions?
The 2 problems look actually very similar, although I AM using the RL-Arm library AND targeting it to RTX.
Thank you all in advance :)
It sends very small packets (10 bytes) at the fastest possible rate
why are you doing that? you are introducing delays into your stack. performance will absolutely improve if you send larger chunks (say, 512 - 1024 bytes...?) have you considered what your transmission policy mean in terms of bus congestion control algorithems (en.wikipedia.org/.../Nagle's_algorithm) ?