Mats Nordlund wrote:
> Jan,
>
> thanks a lot for your quick reply! I have some additional questions below:
>
> On 11/11/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>> Likely, those packets were received by the same IRQ event. The typical
>> RTnet driver looks like this:
>>
>> irq_handler()
>> {
>> timestamp = read_timestamp();
>> ...
>> while ((packet = incoming_packet())) {
>> packet.timestamp = timestamp;
>> enqueue_received_packet(packet);
>> }
>> ...
>> }
>>
>
> I am not fully aware of the details of the mode of operation of the
> NIC, but do you suggest that the NIC stores/buffers multiple packets
> before raising an interrupt to the CPU? If this is the case, INope, though this is also supported by many cards. RTnet drivers are configured to raise an IRQ as soon as at least one event has occurred. But packets can come in quickly, the smallest ones in 6 us-intervals on 100 MBit/s. So while the IRQ is forwarded to the CPU and finally to the driver (after leaving some potential IRQ-off section in the OS), further packets may have already arrived. The same could happen while the driver processes the first packet. > understand that the timestamp could be the same (quantized to > microsecond level at least). > > Is is possible to make the NIC to raise an IRQ for every single packet > or would this have severe impact of performance? > > I really would like to examine the *actual* receive time into the NIC > as close to the real time as possible. Then you would have to busy-wait on packets, i.e. poll the hardware and take care to do only minimal work to be able to receive the next packets. Things like storing all packets or forwarding them to Linux would have to be deferred after the capturing is finished - or memory is sucked up. Alternatively, you could try to setup two or more RTnet sniffer boxes and let them vote on the reception time (can be done belatedly, of course). The earliest one is closer to reality. The idea is that disturbances on those sniffers should (almost) never happen for the same packet. One could imagine to write some tool that processes multiple libpcap files like this, synchronising the clocks first, then filtering delayed receptions. Finally, a new capturing file would be generated with only the corrected reception times. Still, the timestamp error of packet burst would remain. But what error would be acceptable for you? A few then microseconds? Less then 10 us? Sub-microsecond? > >> That's due to the fact that Linux "only" handles timestamps via struct >> timeval, i.e. with microsecond resolution. But that's ok as the error of >> your timestamp is in microsecond range anyway, even on unloaded passive >> sniffers. > > Thanks for informing me about the struct timeval, that explains the > behaviour. What kind of timestamp error would I expect on an unloaded > vs loaded system? Do you have any rough figures of the error or could > you refer to any other sources of information? That is highly hardware-dependent. There is likely some IRQ latency test in RTAI's repository to check this for your box. On Xenomai, we use irqbench in mode 2 for this. It benchmarks how fast some node can react on an IRQ. You could run some typical load in parallel, or even stressing tests like a cache benchmark, hard disk access loops etc., see http://www.rts.uni-hannover.de/xenomai/lxr/source/TROUBLESHOOTING#L39 Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
