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.
