Mailing List Archive

ethereal cvs version is less slow than ethereal 0.9.16 due to a heroic
effort by a large number of people on the list.

the cvs version of ethereal has for some testcases been seen to be
approximately twice as fast as the 0.9.16 version.
a capture that previously took 100 seconds to load now only takes 50
seconds. your mileage will vary.


now all the low hanging fruits in the previous GPROF data have been
addressed and it would be very nice with new GPROF data on the
current cvs version of ethereal.
can someone produce GPROF data when analyzing a largte capture (i am too
lazy to do it myself)

On Thu, Nov 27, 2003 at 08:15:37PM +1100, Ronnie Sahlberg wrote:
> the cvs version of ethereal has for some testcases been seen to be
> approximately twice as fast as the 0.9.16 version.
> a capture that previously took 100 seconds to load now only takes 50
> seconds. your mileage will vary.

If you have color filters, a read filter, or a tap that uses filters
active while you're reading the file, the changes will make a big
difference; if you don't have color filters or a tap that uses filters
active, it probably won't make as big a difference - but it'll probably
make filtering the display faster, *ex post facto* colorizing the
display, or running a tap with a filter faster in either case.

I just want to salute all that are involved in and contributing big and
small to improving the performance.


Thanks to all.


Please keep ideas, patches and profile data coming. We have already in just
a few weeks made ethereal significantly faster than
version 0.9.16.


I just checked in patches for 2 pretty cheap fixes that made tethereal maybe
3% faster. Not much in itself but if we do 20 more of these 3% fixes
it all adds up to something one can actually notice.



Gerald, maybe there should be a temporary ethereal-performance mailing
list for these activities? there are many interested and contributing and
it would keep performance stuff from spamming/polluting the main developer
list?
Not everyone is really working with datasets large enough that performance
is an important issue and performance related mailings are already taking up
a large amount of the ethereal-dev traffic.

I have to say good job as well.
A trace I have been using with a million packets in it now only takes 59
seconds to decode, as opposed to 0.9.16 where it was at 1 minute 56
seconds!




On Wed, 3 Dec 2003, Ronnie Sahlberg wrote:

> I just want to salute all that are involved in and contributing big and
> small to improving the performance.
>
>
> Thanks to all.
>
>
> Please keep ideas, patches and profile data coming. We have already in just
> a few weeks made ethereal significantly faster than
> version 0.9.16.
>
>
> I just checked in patches for 2 pretty cheap fixes that made tethereal maybe
> 3% faster. Not much in itself but if we do 20 more of these 3% fixes
> it all adds up to something one can actually notice.
>
>
>
> Gerald, maybe there should be a temporary ethereal-performance mailing
> list for these activities? there are many interested and contributing and
> it would keep performance stuff from spamming/polluting the main developer
> list?
> Not everyone is really working with datasets large enough that performance
> is an important issue and performance related mailings are already taking up
> a large amount of the ethereal-dev traffic.
>
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

On Wed, Dec 03, 2003 at 10:00:07PM +1100, Ronnie Sahlberg wrote:
> Please keep ideas, patches and profile data coming.

I've checked in a change to use our own data structure, rather than a
tree of GNodes, for the protocol tree; it sped up one test case by
5-10%, and significantly sped up the processing of one capture with a
large YPALL reply (as appending to the list of child nodes of a node is
now constant-time rather than linear in the number of child nodes -
"proto_node" structures have pointers to the first and last child).
(Unfortunately, I suspect the GTree widget uses a tree of GNodes, so
building the display for that packet is still slow.)

Hopefully I haven't broken anything.

Cool. Once again the ethereal team is scoring a complete and crushing
victory. Like as when the ozzies are playing a normal cricket one day
test.



Ill try it with one of my mother-of-all-packets.
Its a packet that once if has been reassembled in NBSS, SMB(Ttrans+Write)
and the DCERPC fragment layer becomes
>1MByte !!!!

I tell you, you do notice when ethereal hits the last fully reassembled
frame for that one and starts to dissect a >1 MByte PDU.


----- Original Message -----
From: "Guy Harris"
Sent: Thursday, December 04, 2003 10:08 PM
Subject: Re: [Ethereal-dev] ethereal performance


> On Wed, Dec 03, 2003 at 10:00:07PM +1100, Ronnie Sahlberg wrote:
> > Please keep ideas, patches and profile data coming.
>
> I've checked in a change to use our own data structure, rather than a
> tree of GNodes, for the protocol tree; it sped up one test case by
> 5-10%, and significantly sped up the processing of one capture with a
> large YPALL reply (as appending to the list of child nodes of a node is
> now constant-time rather than linear in the number of child nodes -
> "proto_node" structures have pointers to the first and last child).
> (Unfortunately, I suspect the GTree widget uses a tree of GNodes, so
> building the display for that packet is still slow.)
>
> Hopefully I haven't broken anything.
>

Guy Harris wrote:

> On Wed, Dec 03, 2003 at 10:00:07PM +1100, Ronnie Sahlberg wrote:
>
>>Please keep ideas, patches and profile data coming.
>
>
> I've checked in a change to use our own data structure, rather than a
> tree of GNodes, for the protocol tree; it sped up one test case by
> 5-10%, and significantly sped up the processing of one capture with a
> large YPALL reply (as appending to the list of child nodes of a node is
> now constant-time rather than linear in the number of child nodes -
> "proto_node" structures have pointers to the first and last child).
> (Unfortunately, I suspect the GTree widget uses a tree of GNodes, so
> building the display for that packet is still slow.)
>
> Hopefully I haven't broken anything.

Looks like this is broken:

> make[2]: Entering directory `/u/morriss/ethereal-dev/source'
> source='packet-dcerpc-epm.c' object='packet-dcerpc-epm.o' libtool=no \
> depfile='.deps/packet-dcerpc-epm.Po' tmpdepfile='.deps/packet-dcerpc-epm.TPo' \
> depmode=gcc3 /bin/sh ./depcomp \
> gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./wiretap -I/usr/local/include -DINET6 -DSOLARIS8_INET6 -D_U_="__attribute__((unused))" -Wall -W -g -O2 -Wno-return-type -DFUNCPROTO=15 -I/usr/local/include -I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -I/usr/openwin/include -c `test -f packet-dcerpc-epm.c || echo './'`packet-dcerpc-epm.c
> packet-dcerpc-epm.c: In function `epm_dissect_ept_entry_t':
> packet-dcerpc-epm.c:195: structure has no member named `parent'
> make[2]: *** [packet-dcerpc-epm.o] Error 1
> make[2]: Leaving directory `/u/morriss/ethereal-dev/source'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/u/morriss/ethereal-dev/source'
> make: *** [all] Error 2

or is the anonymous CVS behind?

On Dec 4, 2003, at 6:52 AM, Jeff Morriss wrote:

> Looks like this is broken:
>
>> make[2]: Entering directory `/u/morriss/ethereal-dev/source'
>> source='packet-dcerpc-epm.c' object='packet-dcerpc-epm.o' libtool=no \
>> depfile='.deps/packet-dcerpc-epm.Po'
>> tmpdepfile='.deps/packet-dcerpc-epm.TPo' \
>> depmode=gcc3 /bin/sh ./depcomp \
>> gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./wiretap -I/usr/local/include
>> -DINET6 -DSOLARIS8_INET6 -D_U_="__attribute__((unused))" -Wall -W -g
>> -O2 -Wno-return-type -DFUNCPROTO=15 -I/usr/local/include
>> -I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2
>> -I/usr/local/lib/glib/include -I/usr/openwin/include -c `test -f
>> packet-dcerpc-epm.c || echo './'`packet-dcerpc-epm.c
>> packet-dcerpc-epm.c: In function `epm_dissect_ept_entry_t':
>> packet-dcerpc-epm.c:195: structure has no member named `parent'

Gak. I'd assumed nobody was using the parent link, and removed it
before checking in, without rebuilding. (It was almost 3AM.)

I've checked in a fix, putting the parent link back in.

On Thu, 27 Jul 2006 07:23:34 -0600, <ethereal-dev-request@ethereal.com>
wrote:

> Has anyone done any serious performance testing of
> Ethereal as regards network capture performance?
> I'm trying to evaluate performance by capturing a
> gigabit Ethernet link with this configuration :
> •OS Linux Debian
> •Pentium 4 processor
> •2 GB memory
> •Ethernet card : Intel 1000 CT
> I need to monitor a 600 Mbits/s link but actually, I
> can’t capture more than 230 Mbits/s without dropping
> packets.
> What are the important parameters (hardware, OS…) in
> the aim to monitor a full gigablt link.

The network card itself is critical here. Here
(http://www.digit-life.com/articles2/gigeth32bit/gig-eth-32bit-2.html) are
some speed comparisons of various cards. To get throughput on the order
you are talking, you need a fast processor (hopefully dual core) and a
pci-x card. The Pro1000 is in general the fastest of the 32bit cards, at
least as reported in the article cited above. It seems that under ideal
conditions, it might be able to keep up. However, I suspect the tests were
the only thing the computers were doing at the time, and that no ethereal
was running. Note that the Pro1000 did have the lowest CPU usage under
Windows 2k: no info about Linux. Also note that with some jumbo frames,
the Pro1000 performance suffered significantly. What size are the frames
you are trying to capture?

--john
--
John McDermott, CPLP, CCP
Writer, Educator, Consultant
jjm at jkintl.com www.jkintl.com
V: +1 505/377-6293 F: +1 505/377-6313

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev