https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3246
Summary: RTP stream analysis finding next non-ok very slow at the
end of large files
Product: Wireshark
Version: 1.0.6
Platform: PC
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: christoph.furer@xxxxxxxxxxxx
Build Information:
wireshark 1.0.6BiasMaxNumNodes20
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.12, with GLib 2.16.6, with libpcap 0.9.8, with libz
1.2.3, without POSIX capabilities, without libpcre, without SMI, without ADNS,
without Lua, without GnuTLS, without Gcrypt, without Kerberos, without
PortAudio, without AirPcap.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.
Running on Linux 2.6.27.7-53.fc9.i686, with libpcap version 0.9.8.
Built using gcc 4.3.0 20080428 (Red Hat 4.3.0-8).
--
When using the function "next non-ok" in the rtp stream analysis (eg for
searching packet losses in detail), the function will be very fast at the
beginning of a file, but they will get much slower, as more you come to the end
of a file (just with pressing the button "next non-ok" after each finding, it
will take more and more time towards the end of the file). The file used has a
size of 50MB, 2 RTP-streams with each around 220000 packets. This is not new
with 1.0.6, it's independent of the OS, it happens also with the unchanged
windows runtime. If this function has to go through the whole trace, it can
take 10 minutes and more to find a packet loss (but the statistics about losses
is done in about 10 to 20 seconds)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
