ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4037] Automatically scrolling up

Date: Mon, 1 Feb 2010 00:48:09 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4037

--- Comment #16 from Jim Young <jyoung@xxxxxxx> 2010-02-01 00:47:59 PST ---
@Anders,

Some observations about "second trial patch". (Observations appear to hold true
w.r.t. SVN_31749).

Realtime test was with "Update list of packets in real-time" and "Automatic
scrolling in live captured" enabled.

 - When the "Stop" capture button is pressed there is a momentary flash of the
frames from the beginning of the capture before the packet list redisplays the
last of the captured packets.

 - After stopping the capture the status bar's "Displayed:" field reports one
less frame number than the "Packets:" field.

 - The status bar does not update the "Displayed:" field when if and when a
display filter is applied.

 - The status bar's file load "Time:" field reads zero after loading a file.

 - Real time capture scrolling performance and file loading performance is not
quite as good as with the initial test patch. 

I did a series of tests capture tests with realtime scrolling enabled. I sent
one million multicast frames from the capturing machine at a rate of about 8000
frames/second.  

Capture test summary:
SVN_31745,  transmit_time (secs), all_displayed(secs), latency (secs)
unpatched,  125.11              , 232.48             , 107.37
patch_1,    130.40              , 130.40             , 0             
patch_2,    131.37              , 138.96             , 7.59

transmit_time is elapsed time as to transmit the 1,000,000 mcast frames
all_displayed is the elapsed for wireshark to display the 1,000,000 frame
latency is the difference between the all_displayed and transmit_time

I also did a series of capture file load tests with three capture files.  Each
of these capture files were different in size, frames and content.

file#1 - 50MB, 180749 frames (91.5% LLC, 7.5% IP, 1.0% ARP) snap at 76 bytes
file#2 - 78MB, 75911 frames (99.0% LLC, 0.75% IP, 0.25% ARP) no snap
file#3 - 213MB, 400318 frames (88.0 %IP, 6.5% SLOW, 4.0% ARP, 1.5% LLC) no snap

The table below summerizes the average capture and load times using unmodified
SVN 31745 on a Windows XP, then with test patch 1 applied, then with test patch
2 applied.  For the unpatched and patch_1 tests I dropped the occasional
outliers (the samples when the "Loading" dialog did NOT appear).  I did not
experience any outliers when patch_2 was applied.  

File load test summary:
SVN_31745,  file#1 (secs), file#2 (secs), file#3 (secs) 
unpatched,  9.15         , 5.07         , 28.47
patch_1,    7.62         , 3.64         , 16.83
patch_2,    17.14        , 8.72         , 46.40

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.