Hi all,

  I suppose I have a rather weird question for this forum, however I need to fix a packets latency in AP to a constant value say 10ms. By latency I mean the time interval starting when the last bit of the input frame reaches the input port and ending when the first bit of the output frame is seen on the output port. I vaguely told that it is possible on Linux, however I am not sure if this has to be taken care by the sender of the packet or inside the APs firmware. I did try googling however in vain. Maybe you guys have any suggestions?

I know it may sound pointless but I can assure its not

Why not just fix the ap's rate

Well thing is that I need to have as deterministic system as possible, and fixing the AP's rate still leaves me with uncertainty.

There's no way to reliably do a precise delay without a real RTOS, but you can use TC to induce 'rough' delays.  You probably won't notice the difference unless you really do mean 10ms, but in that case you're shopping in the wrong market.

Sorry TC?

well I am currently trying to squeeze RTAI into OpenWRT for this purpose

The 'standard' Linux utility for shaping traffic.  Check lartc.org for extensive documentation.

RTAI probably isn't going to help you, that's only for real-time userspace applications; nothing in networking is in userland.

Also, check out one of the 2WIRE 2700 units - they induce a consistent 200ms delay in every packet.  I hate them.

Thank you, I'll look at them right now.

But RTAI is not only in userspace, it has a HRT kernel space as well, the only problem is to put it into ASUS 500gP

Yes, it has a kernel-space driver; it couldn't claim RT-like performance if it didn't.  Even so, it has everything to do with how applications are executed and nothing to do with how traffic is routed.  It's like saying the disk scheduler is affected by a USB-serial driver - never the twain shall meet.

Yes I see your point. However (well its just an impression of Linux illiterate) wouldn't it be possible to move some network trafficking under RT conditions, since RTAI squeezes itself in between hardware and the original OS kernel layer?

RTAI doesn't place itself between the hardware and OS kernel, it replaces the scheduler and some other components, integrating itself into the kernel itself (think metastasizing).  A hypervisor (Xen, etc.) inserts itself as a shim between an unmodified kernel and the hardware.

RTnet (a sibling project of RTAI) is an attempt at using RTAI to produce hard real-time networking, but requires a dedicated ethernet segment that only RTnet devices can talk on and only supports a very narrow spectrum of copper ethernet interfaces - no wireless.  RTAI may be able to give you (again, very rough) control over the latency of the networking stack, but only by starving or providing it with CPU time - hard real-time networking requires a dedicated, purpose-written stack from copper to layer 7 with a supporting RT scheduler.  That doesn't even start to deal with the latencies and transmission issues on the relatively (as compared with copper/fiber ethernet) unreliable 2.4GHz band.

There are lots of things to say and ask here, but I think the simplest is this: why?  Of all the ways to induce rather reliable delays why did you choose to go the most hard-core route that makes even the grungiest embedded engineer shudder?  Simply deciding you're going to go for hard packet timings isn't a very trivial decision.

aoz.syn, thank you for your insight. To answer your question 'why?' I can only say because of lack of knowledge and experience in communication networks. I am from satellite positioning navigation and timing (GPS, Galileo, etc.) sphere and I have this project to augment indoor GNSS positioning with communication networks. The only reasonable way to do it is by measuring time. This project is orientated to produce a software solution which could be used together with of the shelve mainstream AP. These decisions to use ASUS AP's with MIPS chips on them and employ RTAI obviously have been made without proper consideration.

Hell, I can see that initial idea is totally FUBAR and I will need to come up with something smart ASAP...

Are you intending to re-distribute the GNSS signal, or are you just trying to distribute timing information?  If timing, I've seen somewhat-COTS MIPS systems use a combination of NTP, OXCO, and GPS discipline to get down to <30ps synchronization over 40 miles.  That's relatively easy to do.

If you're trying to actually replicate the signal, short of setting up repeaters I'm not sure there's a good solution for you.  If RTnet has a driver for the copper NICs on the APs or you could get someone to write one for you, you could conceivably set up a dedicated ethernet segment that utilized the copper interfaces on the APs for your RTnet link (signal distribution), then a custom driver for the WiFi that emitted your timing packets.  Even so, you'd still have to get over the fact that the 802.11 radios aren't going to be capable of broadcasting in a GNSS spectrum and the clients will somehow have to handle that.

No no, its a different approach, I am not trying to make pseudolites from APs, but rather going to sensor fusion solution and opportunistic positioning. Its possible to achieve a very nice accuracy with sophisticated architecture and hardware, however this project focuses on 'make it as simple as possible' goal. In this case I don't neither sinc the AP's with GPS time nor even in between, the TOA (time of arrival) measurements are then dealt with in particle/Kalman filters to obtain positioning solution. I was aware of RTnet, however it does not suit the raised objective as it requires centralized management. In my case just constraining latency and minimizing its jitter in otherwise unmodified AP is sufficient.

If you just need to minimize jitter of IP packets, do some experimentation with the 'dstlimit' iptables module.  I think tc also has some qdiscs that recognize a 'pps' rate instead of traditional data-based rates, but that's just a vague memory.

Definitely will look into it.

Appreciate your help

One more bit - the sch_netem scheduler may help as well.  I'm not sure how usable it is, but it's a testing module designed to artificially induce latency, jitter, packet loss, and so on.

If you don't fix the rate, then it doesn't matter weather you use tc or any other method.

If you set 54Mb/s that is guaranteed to send 54Mb every second even if you only send 1 bit or 300 or 54M.

The other problem you have is getting the data to the wireless card on time.

Even if you send 1 packet to the wireless card every time unit, if the wireless card change bit rates it will send the data at different rates

well the thing is if I fix the rate to a low value, expecting that the packet will be delayed until next available broadcast, I will never be sure how long the packet was in the buffer waiting for retransmission (timing uncertainty is the size of delay in buffer, minus process time). And if the rate is higher than the process time of the packet, then I will not be able to extrapolate how many cycles it missed.

You're in the right neighborhood, but approaching it completely wrong.  tA is looking at transmission latency and not at link bandwidth.  Mistake of ignoring the significant overhead of 802.11 aside, link speed on most ethernet-style interfaces has nearly zero effect on how quickly an individual packet is transmitted.  Put another way, you're not changing the speed of light.

However, part of negotiating a particular speed with an AP in WiFi involves a decision on how wide a transmit time slice you get.  If using the full 802.11 stack (which if you look at tA's other posts they likely won't end up doing), yes - if the point-in-time you issue packet data to the card doesn't align with its slice, it'll wait in the card's buffers until it has another transmit window.  AFAICT, that's not a concern here.