Disk speed is certainly a potential bottleneck when capturing with Ethereal.
Why would you think that using a NAS solution (which would cause you to
start making NFS or CIFS calls adding quite a bit of additional overhead
as well as possibly being particularly subject to network latency when
performing write I/Os (particularly with Samba/CIFS)) would be faster
than writing to a local (or dirct-attached) disk/disk array, no matter
how expensive the NAS box you use is?
Now, getting a Fibre Channel HBA and connecting to EMC DAS or SAN
storage might be a different story...
I doubt getting a solution using Ethereal/tcpdump to capture at the same
rates as Infinistream would be as simple as throwing an expensive disk
array at the box, but I do think that a fast disk subsystem is crucial
to performing near-gigabit rate capture to disk.
Ian
darren wrote:
Hi,
Can the problem with the dropped frames be due to poor storage performance?
I was wondering if one can achieve what NAI's Infinistream does by coupling
a nice server pc (2 x Xeons 3GHz with 4 GB ram) with a NetApp or EMC NAS
solution for better I/O performance. Infinistream is afterall using only a
RAID5 config.
Any comments?
-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Martin Heroux
Sent: Thursday, November 20, 2003 4:58 AM
To: ethereal-users@xxxxxxxxxxxx
Subject: [Ethereal-users] tcpdump vs ethereal
I am experiencing some proof of concept of using ethereal to replace our
distributed sniffer and I see some differences between the traces.
It would runs on gigabits links, on a RH-9 with 1GB Ram on with altheon
gigabit cards on optic fiber (SX)
We are spanning ports using Cisco 6509
I have 2 interfaces in my proof of concept box, one to sniff and one to
access it... I am accessing it through eth1 and sniffing with eth0
eth0 is promiscous and have no IP address...
Here's some quick numbers from a quick trace :-)
Distributed sniffer: 2844520 packets captures, no drop
tcpdump: 2842639 packets captures, some drop (1881)
tcpdump -w /dev/null -i eth0
But doing it with ethereal gives
2830298 packets captures, some drop (14222)
So I turned the swap off and did the same test (swapoff -a)... no program
in swap should increase the performance due to page swaping time...
Distributed sniffer: 3025830 packets captures, no drop
tcpdump: 3013675 packets captures, (1105 drops)
ethereal: 2984633 packets captures, (30147 drops)
The switch reports no errors on the ports
The interface on which I sniff reports no error or dropped
The ethereal -v issue the following
ethereal 0.9.16
Compiled with GTK+ 1.2.10, with GLib 1.2.10, with libpcap 0.7.2,
with libz 1.1.4, with Net-SNMP 5.0.6, without ADNS
Running with libpcap (version unknown) on Linux 2.4.20-6
As of libpcap rpm -qa | grep libpcap returns the following
libpcap-0.7.2-1
Now, here are my questions:
1- why does tcpdump don't get the same amount of packets as a regular
sniffer (Dolch for instance) I am using one of the best gigabit card on the
market I should get the same result. BTW the altheon card can be driven to
wire speed, I saw it on an Auspex.
2- why does ethereal which uses tcpdump don't read the same amount of
packets ?
3- is there a any work around ?
4- Any other way than tcpdump (libpcap) to sniff and get no or less packet
drops, with ethereal ?
Any help will be appreciated
M.H.