> I've run across an interesting problem in libpcap that I wondered if anyone
> else has seen. I'm running tests sending RTP traffic every 20ms and then
> calculating jitter (which is based on the time a packet is received).
I.e., on the timestamp in the packet header?
> It
> seems that about 80 packets show up, evenly spaced at 20ms each, then
> there's one packet that comes in 30ms later and another 10ms later, then
> another 80 packets or so at 20ms and so on.
>
> I've tried the same captures using snoop,
On the same machine?
If so, both libpcap and snoop use the same underlying packet capture
mechanism, and, at least according to "truss" on Solaris 2.6, snoop
pushes "bufmod" onto the DLPI stream, just as libpcap does. libpcap
does four I_STR ioctls on the DLPI stream, and snoop does three;
unfortunately, truss doesn't say what those three I_STR ioctls are, so I
can't determine from that what libpcap is doing differently from snoop.
bufmod is the STREAMS module that puts timestamps onto the packets; it
has no idea when the packet was received by the network driver, so it
can only stamp them with the time when the packet was passed to it from
downstream - perhaps the stream is set up by libpcap in such a way that
packets don't pass quickly upstream from the driver to bufmod.
If the two captures were on machines running different OSes (or perhaps
even different releases of the same OS), it might be a function of
differences in the underlying packet capture mechanism.
