Hi Jan,
sorry for the late respose.
In my previous mail I did never explain the background to problem with "same
timestamps on multiple packets". I'll do that briefly.
I have noticed a general problem with the newer HW versions of the D-link
DI-604 routers (from rev C and onwards). They seem to drop user UDP packets
when the incoming WAN traffic also consist of ARP bursts entering the WAN
port at a rate of near 100 Mbps. I suspect that the internal processing of
even short 100M burst of ARPs makes the DI604 to drop user UDP traffic. This
is at least my theory which I would like to confirm.
I have injected artificial "100M ARP traffic" using bittwist (on a normal
Linux dist, not RT) and confirmed that UDP traffic seem to be dropped by the
DI604. However, the timing of bittwist using normal Linux is of course
questionable. So the test is not fully reliable.
So I captured the real WAN traffic coming into my DI604 from my 100M
Internet access with RTnet (capturing reth0 in Wireshark). My Internet
access is towards a layer 2 metro network which means that my DI604 "sees"
other user's ARP and broadcast traffic. Occationally there can be bursts of
ARPs close to 100M entering the DI604. In the capture file I noticed the
problem with the same timestamps.
My plan was to capture the incoming ARP/bcast traffic with "near-to-real"
time accuracy. The plan was then to use the capture file in reverse, that
is, to play back the captured packets into my DI604 and by that means be
able to analyze/reproduce the problem in a controlled way.
Would it be possible at all to achieve, let's say, 1us guaranteed
resolution? Would you recommend a busy-wait approach to vouch for highest
possible time resolution?
/ greetings from Mats
On 11/11/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
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, I
Nope, 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
