Hi Tery, Teresa Noviello wrote: > Hi! > I'm studying RTNet+RTAI solution performance in my thesis' project. > I'm using "ethereal" for my analysis. > Im testing performance on user space applications running in real time > mode. > Has anyone some results on this type of problem (user space applications > running in real time mode, using RTNet)? > I ask you here because there aren't numeric results in the Documentation. >
Unfortunately, I only have outdated (more or less) systematic numbers at
hand, on outdated RTAI (e.g. 3.1) with outdated RTnet (latest was 0.7.1,
TDMAv1). And it's in German. :(
Generally, the problem with "performance" analysis is that you first
have to define your scenario clearly. Otherwise, you may compare apples
with oranges. Early RTnet analysis (our own first work included) did not
take care for all aspects with the required thoroughness (also due to
limited time spent on measuring compared to designing and developing).
So here is a list of parameters, written with slightly more "wisdom":
o used hardware (architecture, performance/MHz, network adapters,
Ethernet switches or hubs)
o IRQ and scheduling latencies under load when using the favourite
RT-extension
o TDMA or not, if yes:
- TDMA cycle
- TDMA slot sizes and gaps (influences bandwidth and the time
stations may have to react on requests)
- synchronous or asynchronous packet queuing with respect to TDMA
cycle (relevant for interpreting packet jitters correctly)
o scenario to test, e.g.:
[latency tests at application level]
- master collects data from slaves (polled or unsolicited)
- master collects data from slaves and redistributes it
- random slave-to-slave communication
- ...
[accuracy test]
- recording transmission slot jitters (preferably with multiple
passive sniffers, including the Ethereal way, to reduce measuring
errors)
- external event arrives, gets recorded with global timestamp to
analyse distributed clock accuracy
- ...
[performance benchmarks]
- stack traversal times (instrument the code or use the
ipipe tracer patch)
- worst-case time spent on RTnet jobs (i.e. what latency will your
application or other driver's IRQ handlers suffer from?)
- average system load due to RTnet+application (what remains to
standard Linux?)
o load scenario:
- competing PCI devices (hard disk DMA access, non-RT NICs, etc.)
- non-RT CPU/cache load
- low-prio RT applications competing for the CPU or even RTnet
services
- non-RT networking load (if tunnelled via RTmac/TDMA, it must have
only low bounded effect)
You see there are a lot of questions, and as they depend on many
specific factors like hardware, RTOS, or system configuration, it's hard
to provide generic answers.
Anyway, you may want to pick a few of the mentioned aspects for your
analysis. You first step (if not already done) should be to get a clear
overview on what happens when a packet travels from A to B, both to the
packet and on the control layers. Then it is easier to interpret any
number one may measure later.
And feel free to discuss your setup, test tools, and results here.
Having some more standardised tests for RTnet has been on my wish list
for quite a while, any possible contribution will be highly welcome as well!
Jan
signature.asc
Description: OpenPGP digital signature
