Mats Nordlund wrote: > 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?
1 us definitely requires polling with IRQs globally disabled. Additionally, you need a good understanding of your NIC /wrt when it reports a packet compared to when this packet actually began to arrive to compensate for any latencies. Still, the problem remains how to keep up with bursts of short packets where only a few micros are between each of them (given "only" 100 MBit/s). I order to keep up with such scenarios, you need a fast machine and hand-optimised code (i.e. not some beautifully layered approach :)). Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
