[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improving the data supplied by BPF
Arnaud Lacombe <lacombar%gmail.com@localhost> wrote:
>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.
> - Arnaud
Well, we can make the counter 64 bits...
Main Index |
Thread Index |