2006/8/16, Jan Kiszka <[EMAIL PROTECTED]>:
Thank You for Your help!
I'm afraid that we can not workaround the kernel patching, or?
Imre Paniti wrote:
> 2006/8/16, Jan Kiszka <[EMAIL PROTECTED]>:
>>
>> Imre Paniti wrote:
>> > 2006/8/14, Jan Kiszka < [EMAIL PROTECTED]>:
>> >>
>> >> Imre Paniti wrote:
>> >> > We want to test our RTnet aplication to see if the timing is right.
>> >>
>> >> What timing? On the cable?
>> >
>> >
>> > The time difference between sending and reciving.
>> >
>> >> Actually we find a page for Active Probing at
>> >> >
>> http://www.cubinlab.ee.unimelb.edu.au/probing/software.php#tsc-rt-linux
>> >> > but they dealing with RTnet based on RTLinux.
>> >> > Our environment: 2 PC with 2.6.15 kernel, RTAI-3.3-cv and RTnet
>> 0.9.3
>> >> > The NICs are RT8139.
>> >> >
>> >> > Do you have some suggestions for us?
>> >>
>> >> Do you have a chance to attach a third station as a sniffer to your
>> >> network (works best with one of the rare 100 MBit hubs...)? Then
>> >> grabbing the traffic with RTnet+RTcap on that box would give you a
>> good
>> >> impression with accurate timestamps (in the order of IRQ latencies).
>> >>
>> >> Jan
>> >
>> >
>> > Thanks for the idea!
>> > We can do that, but what about using RTnet+RTcap (+Ethereal as a
>> capturing
>> > tool) on those PCs without a third station?
>>
>> Also feasible. You just have different clocks then. And you see things
>> like the stations see them. If you plan to load the boxes in order to
>> generate worst case behaviour, your locally taken timestamps will suffer
>> as well. Therefore the idea of a third station dedicated to measuring.
>>
>> Jan
>
>
> I think I get it - with a third station we can measure the performance of
> RTnet under high pressure, sending loads of data with a static interval and
> see how much this interval differs from the interval with which our sniffer
> sees a packet. Is that right? If it is, that is not really what we're
> looking for. We're trying to find a way to see how RTnet affects our
> real-time thread - while sending much data and little data, and with a busy
> thread and a less busy thread. If possible, then how would a third machine
> sniffer deal with that? Or would there be an other solution?
Ah, I see. Then you are looking for something like LTTng (currently not
supported over Adeos/I-pipe unfortunately, will come) or the latency
tracer (http://download.gna.org/adeos/patches/v2.6/i386/tracer/).
The latter can be used to record the maximum IRQs-off period and to
trigger a back-trace from your application when it detects a high delay.
This happens at kernel-level by logging every function entry with a
timestamp. It also supports recording of PIDs which can be used to trace
context switches, but RTAI doesn't make use of this yet. Note that, as
the tracer degrades the performance of the target, its numbers are not
directly transferable to the production system. To sum up, the tracer is
specifically useful for finding long preemption locks and analysing
scenarios that can be detected as critical at application level (e.g. a
deadline miss).
Don't know, maybe RTAI also provides an overview of the CPU load each RT
thread consumes. Check /proc/rtai. This may give a rough impression of
the average system load. We have such stuff in Xenomai since recently,
but I do not have numbers of the RTnet threads (stack manager, TDMA,
RTcfg) at hand.
Jan
Thank You for Your help!
I'm afraid that we can not workaround the kernel patching, or?
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
