TCP Packet Processing Speed?

Hi all, just getting started with Arduino and like the possibilities. I've been searching for a few days now for the answer but have not been successful.

My final goal is to have the ethernet shield receive a tcp packet, and then send a preformed reply depending on the content. What I am trying to find out is the processing speed (in microseconds) for this set of events. For example, time it takes to read in a small TCP packet, time to do a look up, then send reply packet. This is strictly for 1 packet..not worrying about transaction setup, etc.

Also not sure how to measure the actual speed accurately since the micros() gives 4us resolution.

Glad I found this board. =]

Thanks all.

it's very hard, because it depends on your loop code for the response. You can have a little idea creating a skect that wait for a connection, and then reply all data. On the pc you create a program that connect and send some data, and calculate the time for response. You can also change the data size and see if arduino like big or short message.

Note that tcp is not a "packet oriented" protocol. Assorted algorithms come into play when converting a bytes stream into a packet stream (inside the wiznet, probably) that may play a part in determining response time. (slow start, delayed ack, Nagel Algorithm, and more...)

what do you recommend then for testing speed/latency?

you can upload and download a fixed size file, so you will know the speed, for latency you can send timestamp, the receiver wil immediatelly send it back.
elapsed time / 2 is the ping(latency), but you will also measure some lag because of computation of receiving and resending the packet. So you will measure bigger ping if you’re using your pc for calculation, because arduino software layer for TCP is slower (this can change if TCP is elaborated by external chip like netwizard).

what do you recommend then for testing speed/latency?

some sort of transaction-oriented "ping" implemented within the actual application you are using.

To expand a bit, a "full featured" TCP/IP implementation would have some kind of performance measurement capability at each "layer" of the protocol. Logic analyzer for ethernet reception, "ping" at IP/ICMP level and TCP "discard" at TCP level, and a file copy to NUL: for scp, for instance. Then you could find out maybe-meaningful data about where delays actually were occurring (and which pieces of code you needed to try to speed up.) It sort-of falls apart when the implementations are so different that the results are meaningless. For instance, a modern high-speed router has LOTS of hardware assist for packet switching, and maybe to help with IP and TCP as well, but is somewhat likely to treat an ICMP ping request as a low-priority (and probably throttled) event...

Hmm, the more I think about it, software timestamping probably won’t provide enough accuracy. Also, are there libraries available to process ethernet packets themselves? That would actually be preferred, if I could take the ethernet packet and just look in a certain location for info. I think sending the packet up the stack is unnecessary time wasted.

Also haven’t figured out a way to take out variables like router. I have available to act as server an ubuntu system, OSX, and windows. I guess I’ll need a crossover cable to hook the shield up to the ubuntu system. For server side I was thinking of writing up something using raw sockets, so it too (the server) is handling things at ethernet level and not waiting as headers are stripped. I have a basic packet sender working so far(I think anyway…the router is eating my UDP packets).

The idea in my head is, server sends a ethernet packet that it forms programmatically to the shield, then the arduino grabs the ethernet packet, reads something, then sends back a preformatted packet to the server. This is the basic action I would love to get working. I guess then test and see how fast it is.

Thanks for all your input! Still trying to wrap my head around this stuff and the forum has been really helpful.

My final goal is to have the ethernet shield receive a tcp packet, and then send a preformed reply depending on the content ... This is strictly for 1 packet..not worrying about transaction setup, etc.

So do you actually want to process a TCP packet, or are using "tcp" in a generic sense to mean "some packet vaguely part of a typical tcp/ip/ethernet protocol suite? Valid "raw" IP/UDP/TCP packets (in increasing order of difficulty) will be tough to get past the operating system(s) that want to process them correctly. If you want a simple packet exchange and are writing the code on both sides, it would be best to pick a low-level protocol that the operating system is not already planning to process. linux-side systems will let to open IP and UDP sockets that get individual packets, since they're packet-based protocols, but you'd best avoid protocol or port numbers that already belong to well-known services. Getting an individual raw TCP packet to an application program would be difficult.

And yes, the wiznet chip supports "raw" UPD, IP, or Ethernet packets. Though I don't think any of those are supported by the current arduino libraries. (MAYBE UDP...)

I would think that with an appropriate o-scope one could measure the time between the arduino receipt of a packet and the return of the packet.

ragefuljoe: For example, time it takes to read in a small TCP packet, time to do a look up, then send reply packet. This is strictly for 1 packet..not worrying about transaction setup, etc.

Also not sure how to measure the actual speed accurately since the micros() gives 4us resolution.

I'm not sure what you are up to here, but TCP "1 packet" is a bit of a contradiction. TCP can involve multiple packets if they have to be retransmitted, or split up due to their size. TCP needs an ACK, so a "single-packet" TCP is not really possible. Maybe UDP?

As for 4us, I just pinged a local server (so we aren't talking about going through even a cable modem - and I know ping uses ICMP and not TCP) and it took 0.671ms, that is 671us. If you are hoping to get a response in the 1us area from TCP, you are going to be disappointed, I think.