Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm doing a feasibility study on a proposed wireless/wired network topology for a coming project of ours. A rough description of its use is "like an industrial sensor system". It looks something like this:

                                            +----+            +----------+
                                     +------| AP | - - RF - - | Endpoint |
                                     |      +----+     |      +----------+
                                  Ethernet             |
+--------+              +--------+   |      +----+     |      +----------+
| Server |-- Ethernet --| Router |---+------| AP |     +  - - | Endpoint |
+--------+              +--------+   |      +----+     |      +----------+
                                     |                 |
                                     |      +----+     |      +----------+
                                     +------| AP |     + - -  | Endpoint |
                                     |      +----+            +----------+
                                     |      +----+
                                     +------| AP |

The Server and Access Points (of which there might be hundreds) talks IP over ethernet. The Acces Points talks proprietary RF with the Endpoints (of which there might be thousands per Access Point). The Access Points have infinite power, but the Endpoints runs on batteries, so we need to keep their draining scenarios to a minimum. Anyway, that's not the question.

In this study I've done a simulation of the system interaction on the Access-Point-to-Endpoint part to find radio congestion situations, optimal update intervals for the Endpoints and more to get as long battery life time as possible given the response time requirements of the RF endpoints.

The simulation is basically a time-stepping scheme where all states of this Endpoint cycle are stepped a time unit for each Endpoint in the simulation (hundreds to thousands): sleeping, starting the MCU, starting the radio, performing clear channel assessement, backing off, transmitting a payload of predefined size to the Access Point, waiting for the radio to turn over to receiving, going back to sleep.

We have a pretty solid understanding of all timings involved in the above situation where real RF is involved. Not so for the Ethernet part, however.

When an Access Point receive a payload from an Endpoint, it'll repack it and send it to the server, which will give back a reply to the Access Point with minimal payload, a payload that is repacked in the Access Point before transmitting it to the Endpoint.

Question: What order of magnitude can we expect for the time it'll take for the server query/reply, from the perspective of the Access Point? We can assume that the server is "close" to the router and Access Points, no Internet requests will be involved.

I realize that the question might be extremely under-specified, so please chime in with anything needed to give a rough guesstimate.

share|improve this question
(ping time between the Server and an AP)+(time for the Server to unpack,compute,repack data)+((size of data)/link speed) –  TiFFolk Nov 16 '09 at 10:08
ping time=time for signal to travel from an AP to the Server and back. TCP will provide less performance than UDP. –  TiFFolk Nov 16 '09 at 10:14

1 Answer 1

up vote 1 down vote accepted

I suspect the delay in the ethernet segment(s) will be far outweighed by the RF links, especially if low power is used.

For one, most ethernet today is bi-directional, and you'll be hard pressed to get less than 100 MB/sec on most links. So long as you do not saturate the wire (like if all the radios decided to transmit at once) the switch will manage this well.

Typical latencies on local ethernet, even though a quality switch and a quality router, will probably be less than 10 ms, so I'd just add that to your simulation and see if it fits.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.