On 2013-03-14 14:35, Julien Houles wrote:
> Dear all,
> 
> I'm working on a telescope array project and I would like to develop a data 
> generator to simulate data sending from the telescopes cameras.
> Each camera is composed of 300 modules sending data to a "camera server" 
> through 300 gigabitethernet links (UDP). These links are merged with a stack 
> of switches in two 10Gb links connected to the camera server. Each module 
> generates 10000 packets/s (size ~ 800 bytes). Data sending from the modules 
> is synchronized. The 300 packets from the 300 modules are sent (almost 
> exactly) at the same time, and that 10000 times per second.

Wow, sounds thrilling.

> 
> In order to validate the switches stack and the whole data management chain, 
> I would like to build a full size "stimulator" with 300 physical ports 
> approaching this simultaneous sending. For that, i bought 2 of these boards : 
> http://www.evoc.com/products/NET-1820CVD6N/detail.aspx
> There will be 50 of them in the final stimulator. The boars will be 
> synchronized by a signal triggering the parallel ports. 
> 
> I began to develop a software with Linux but I think I will have too much 
> uncertainty about latency for parallel port interrupts and packets actual 
> sending.
> So I decided to start again with Xenomai.
> I've got a few questions :
>   - Do you think it is feasible ?

Could be.

>   - Do you know the approximate latency and jitter among the 50 boards I will 
> achieve ?

That depends on the overall design of your system, characteristics of
the hardware as well as how you wait for the trigger event and send the
data in software. Typical latencies with an IRQ-driven design are in
order of a few 10 us.

>   - I started to install RTnet. Is it adapted to what i want to do ?

Depends. So you have 6 ports per node. Hmm, but only a poor Atom as host
CPU. Dual or single core? At worst, you will have to send 6 packets each
100 us from a single CPU. Brute-force is to use a task that is woken up
by the parport event (IRQ) and set the packets up one after the other.
That should work, but may spread the transmission times more than you
like. Try it, measure it.

There is room for improvements in case the result is not good enough:
 1. optimize the trigger
     - schedule your transmission task via a timer a bit before the
       expected trigger event
     - poll the triggering parport for that event in a busy loop
    This reduces the latency between event arrival and transmission
    start in general. But do not poll the whole time, Linux needs some
    "air to breath" in between as well!

 2. optimize packet release
     - set up everything for the packets in advance, including their
       data structures in the TX rings of the NICs, but do not yet kick
       the NIC to process the TX structure
     - once the trigger arrived, kick TX on all NICs with very few
       instructions
    However, this will not eliminate the serialization on the memory
    bus when the NICs transfer the packet content via DMA one after the
    other. Also, this approach will require some invasive changes to
    RTnet. I cannot predict how much it may buy you, probably less than
    optimization #1.

>   - The camera server will receive data on regular sockets (not real time, 
> actually I use Netmap). Can I send data with real time accuracy using RTnet 
> to regular sockets ?

In general, RTnet does not care about the software stack on the other
end of the wire.

>   - RTnet alone (without RTmac) works with my hardware (e1000e drivers), I 
> managed to send data to the camera server through 1 link with your rtt-sender 
> example. Do I need RTmac ? I must say that I don't really understand the role 
> RTmac would play with my configuration...

No, you won't need RTmac, specifically as you network links are
exclusively used for the image data.

>   - Will I be able to use the 6 ports at the same time (on the same sub 
> network) with RTnet ? (I ask this question because with regular sockets, I 
> had to add rules to avoid sending all the data through a single physical 
> link).

See above.

HTH,
Jan


Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users

Reply via email to