oh, ok, i've misunderstood the problem, i thought tcpdump was running on another node. anyway, i've never looked at tcpdump in depth, is it possible that it polls packets ? Or is it possible that, running at the same time, it masquerades interrupts directed to Click ?
giorgio On Tue, Jul 20, 2010 at 8:01 PM, Nicholas Weaver <[email protected]> wrote: > This case however its not from the NIC FIFO, as a TCPdump running on the same > interface at the same time doesn't experience the many second queuing delay. > > On Jul 20, 2010, at 10:57 AM, Giorgio Calarco wrote: > >> hi all, >> >> having bursts of packets and increased jitter does not only depends on >> the Click itself, but also from the queueing at the NIC FIFO. The PCI >> bus is indeed fair (in the sense that it serves each peripheral >> with a token passing policy), but once the peripheral acquires >> access onto the bus, it's not time-limited in any way. If the bus >> occupancy probability is high, for any reason, the NICs tend to accumulate >> packets in their internal FIFO and once they can start the DMA >> transfer, they move all the packets back-to-back, generating >> a burst. I 'm not sure if this is your case (which hardware are you using ? >> could the bus possibly be close to saturation ?), >> anyway, you can find more details in one of the second (?) chapther >> of my past PhD >> thesis (it's published on the Click site - Publications). >> Hope it can help in some way. >> >> Ciao, Giorgio >> >> On Tue, Jul 20, 2010 at 6:55 PM, <[email protected]> wrote: >>> On 5:25 pm 07/19/10 <[email protected]> wrote: >>>> I am seeing similar behavior on Linux as well. In my case, I carry some >>> >>> Just wanted to state that the behavior on Linux is similar but not as bad >>> as Nick is reporting for OSX. I get about 20ms worth of extra jitter by >>> using the To/FromDevice compared to sending the data via the RawSocket. >>> >>>> data between two PCs which run user-level click. If I use RawSocket >>>> element, I get much better performance compared to using To/FromDevice >>>> and manually composing the frames. >>>> >>>> >>>> On 10:42 am 07/19/10 Nicholas Weaver <[email protected]> wrote: >>>>> The test configuration: >>>>> >>>>> FromDevice(en0, PROMISC true) -> CheckIPHeader(14) -> >>>>> IPPrint('reply') -> Discard; >>>>> >>>>> >>>>> A TCPdump running at the same time gets all the packets as they are >>>>> received, but the click configuration gets them in bursts (but the >>>>> timestamps are right) >>>>> >>>>> On Jul 19, 2010, at 10:38 AM, Nicholas Weaver wrote: >>>>> >>>>>> I remember having a similar problem before and I don't remember what >>>>>> the solution is... >>>>>> On OS-X (latest version, latest devtools), FromDevice is buffering >>>>>> up a large number of packets rather than receiving them in real >>>>>> time. A TCPdump running at the same time does not have this problem. >>>>>> >>>>>> >>>>>> Suggestions? >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> click mailing list >>>>> [email protected] >>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>> >>>> _______________________________________________ >>>> click mailing list >>>> [email protected] >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> >> _______________________________________________ >> click mailing list >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
