[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improving the data supplied by BPF
On Fri, Dec 26, 2008 at 7:43 PM, Jim Wise <jwise%draga.com@localhost> wrote:
> "Arnaud Lacombe" <lacombar%gmail.com@localhost> writes:
>> 2^32 1500-bytes packets is about 6TB of data, on 100Mbit link, the
>> sequence number will wrap after 5.6 days (if you consider
>> uni-directional traffic), on a 1Gb link, half a day and a bit more
>> than 1 hour on a 10Gb link. This is the worst case scenario. Two
>> records taken at the <wrap_time> interval will likely collide on
>> high-load link.
> Will they? Wouldn't you have to not sample for a whole <wrap period>
> for it not to be immediately obvious that a wraparound had occurred?
no, think about the case where you set up a low pass filter in tcpdump
to monitor only some event. In this case, sequence number got consumed
by high frequency events and the wrap can happen in background.
> Is an application which wants to fill a 100MB link, but not sample more
> than once every five days what we should be designing for?
no, the timestamp will help to discern and to tell if wrap occurred.
If two records have the same timestamp (we only have microsec.
precision now) the seq number will give you their order. If two
records have the same seq number, but not the same timestamp, then you
can say that wrap occurred and you'll do the distinction based on
timestamp. You are in trouble if a record has the same timestamp and
seq number :-)
Note that the wrap can happens sooner than the 5.6 days if the packets
sent are smaller.
Main Index |
Thread Index |