On 9/24/05, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
> In message <79722fad0509240512364a1f80@mail.gmail.com>, Vlad GALU writes:
> >On 9/24/05, Tonnerre <tonnerre@thundrix.ch> wrote:
> >> Salut,
> >>
> >> On Sat, Sep 24, 2005 at 10:01:45AM +0200, Zeljko Vrba wrote:
> >> > To explain in details:
> >> >
> >> > 1. I expect to receive incoming almost full 1Gbit of traffic on bge1=
. I
> >> > will not be doing any outgoing traffic.
> >> >
> >> > 2. I don't need any network stack processing. After the ethernet fra=
me
> >> > is received, I want to record the following data only:
> >> >   - arrival time, as precise as possible (read local APIC?)
> >> >   - full TCP/UDP/IP header (I can parse eth frame myself, if neccess=
ary)
> >> >   - the data load I will discard
> >> >
> >> > 3. The collected data needs to be written to disk. As few as possibl=
e
> >> > frames should be lost.
> >>
> >> This can probably be done easiest by using pf and pflogd. Just drop an=
d
> >> log all packets on the interface, and disable outgoing just for not ha=
ving
> >> to bother with it. If the processor is fast enough...
> >>
> >
> >  That's overkill. Why not simply use bpf ? It's fast enough for most
> >needs, be they hardcore or not.
> >
>
> Does bpf provide an accurate-enough timestamp?  The better experiments
> I've seen that involve timestamped packet capture tend to do the
> timestamping in the driver itself.

  That would be closer to the 'real' timestamp, since it would be
obtained before the driver convers the received data into an mbuf,
which is then thrown in the network stack, and after some (read:
possibly many) CPU cycles is passed to userspace. Anyway, a
gettimeofday() call inside the kernel ought to have the same
precision, no matter where called from. I'm not very familiar with
NetBSD's clock scheme, so I think that if there are two clocks, of
which one is more precise than the other, the driver for that
particular NIC could be improved to use it.


>
>                 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>


--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.