>>> Has anyone achieved TDMA cycles below 200us so far? Is short, I need to >> >> I don't think so. >>
That's what I suspected :( >>> serve 8 slaves within 165us (~6kHz) and I was wondering if it's possible >>> using RTnet. The amount of data is very small, let's say 16bits per slot >>> (what a waste using GBit Ethernet ;) but, it's got to be _fast_ >> >> You would be surprised about how much 0.1 vs. 1 GBit/s actually matters >> with minimal packet sizes - compared to the remaining latencies and >> jitters of your whole system... >> >>> Those also reading the RTAI list might have seen my latency/jitter >>> benchmarking with a very powerful Core 2 Quadcore machine. This machine >>> shall serve as the RTnet master, equipped with an Intel Pro/1000 NIC for >>> RT communication. >> I tried the more sophisticated ones form showroom but had some problems iterpreting the results. Will go back and do more research there. >> [ Reading the mail. ] You've done the standard timer jitter test, maybe >> also not yet with optimal load (see [1]). Things become far uglier when >> you start using periphery, eg. the PCI bus. >> Yes, I've seen that happening... >>> Jan once mentioned freqs somewhere below 10kHz should be possible using >>> a decent machine. well... is it doable? >> >> Maybe, but likely not without careful tweaking of the involved >> subsystems. Specifically, your application should perform 1-to-n >> communication where the server collects all states via unicasts from the >> slave and distributes updates via a single broadcast. And don't do other >> traffic on the line (no non-RT tunneling, no RTmac heartbeats after >> startup). The final setup foresees a pure RT network w/o tunneling. >> That should scale quite well. So a simple 2-nodes test may >> already give you an impression of what is possible with your hardware >> and what not. I've set up that scenario (two machines, one cable) and started playing some days ago but this will need more time. The bandwidth of deviation regarding the synchronisation timestamps was quite large 200 ~ 4000 ns but still adequate IMO(?) > And, of course, if you have some SMP box, tuning IRQ and task affinities > for both the RT side as well as Linux is highly recommended. You gain a > lot if your RT-NIC IRQ can only be disturbed by the unavoidable RT-timer > IRQ. Can you point me where I can find more information about that? > Just don't try running some RT task as a busy loop on an "isolated" core > - you will lock up your non-RT side sooner or later as Linux is not yet > prepared to do complete CPU isolation. This is a good hint! Thx! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
