Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Let's talk about Distance Sniffing/Remote Visibility

  • From: E.B. Dreger
  • Date: Thu Mar 28 13:41:12 2002

> Date: Thu, 28 Mar 2002 13:14:17 -0500
> From: Richard A Steenbergen <ras@e-gerbil.net>


> Logging interesting packets is easy enough, its logging ALL packets that 
> would be a problem. At any rate, you'd run out of harddrive space pretty 
> quick if you were pushing max performance at any length of time. I can 
> write a linerate FastE's worth of data to a $100 IDE disk on a $100 
> processor easily enough, so as long as you're buffering it intelligently 
> it shouldn't be an issue.

This is true.  Logging interesting packets, efficient buffering,
and selective parsing make the big difference.

I guess it also depends on log format:  Raw packet( fragment)s
work great.  Human-readable -- a la, say, Linux kernel verbose
IP logs -- make things get ugly in a hurry.

With fixed-size packet captures, it would be trivial to use a
disk slice as one big scratchpad, much like a swap partition.  No
real need for fs overhead, and one could reserve blocks for
indices or other conveniences.


> Eliminating the bulk "data" being DMA's across the PCI bus is what adds
> most of your "capacity". Doing zero copy just lets you spend all your CPU
> time doing actual analysis instead of copying stuff around unnecessarily.  

Hmmmm.  Looking back at Agner Fog's Pentium optimization guide,
it does appear that the memblk cp would be less of an issue than
the DMA transfers.


> I never did get the opportunity to benchmark it at 1.4million packets/sec,
> (I spent more time trying to get the 20ft of fiber to reach the lab at the
> previous employeer than I did writing the code to do this in the first
> place) but I don't see any reason it shouldn't work, with proper interrupt
> coalescing of course.

It would be an interesting test.  But ~100 MB/sec of traffic
would choke most any single spool drive... and, assuming that all
the data were of interest, it would probably take people awhile
to review all the data.


--
Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

--
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist@brics.com>, or you are likely to be blocked.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.