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

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4037

--- Comment #17 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2010-02-01 01:50:48 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.
I think tere is a freeze/thaw action when capturing is finished that perhaps
should be removed (..finish_tail).

> - 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.
Doing the filtering probably trigers freeze/thaw and update_packts_bar() is
no longer called at thaw.

> - The status bar's file load "Time:" field reads zero after loading a file.
? perhaps the code has changed since i put it there :-)

> - Real time capture scrolling performance and file loading performance is not
>quite as good as with the initial test patch. 
The (current)changes should only affect to live captures.

>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
Patch 1 crudly "kills" all freeze/thaw
Patch 2 attemts to remove freeze/thaw when adding packets at live capture a few
freeze/thaw remains, the 7s difference is a bit suprising.

>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

That's supprising, patch 2 is not supposed to affect file loading.
what happens if you comment out line
new_packet_list.c 137
packets_bar_update()?

7Anders

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