http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1181
------- Comment #8 from jyoung@xxxxxxx 2006-11-21 15:22 GMT -------
Hello Richard,
I would also like to see this resolved.
Am I making this problem harder than it is? Perhaps. But the comments within
capture_loop.c certainly imply to me that this problem is non-trivial. ;-)
As you mentioned in comment #7, I also think that one approach to 'fixing' this
problem is to remove "packet-batching" in dumpcap and implement some type of
"wake up and check for new packets" logic within Wireshark itself (the "tail -f
logic" I mentioned earlier). But this type of fix within Wireshark must still
leave the GUI responsive to the end user.
Interestingly the capture_loop.c diff you cited may have "fixed" this problem
in Windows. On my Windows systems, I often use buildbot versions of Wireshark.
Earlier this year I had noticed that some of the different SVN versions
suffered from this "delay" problem and/or from an extremely sluggish GUI. I
even recall having problems with getting Wireshark to "Stop" a capture until a
packet was detected. At least on Windows platforms these problems appear to
have been resolved.
One really ugly workaround that I tried on my SUSE system was to add a new
command line option to dumpcap that would disable the packet-batching behavior.
To take advantage of this new dumpcap option I implemented yet another option
in Wireshark. I abandoned this approach after seeing how bad Wireshark's GUI
performance was when flooded with a burst of live packets using the current
dumpcap "packet count message" signaling mechanism.
On my SUSE system (with "packet-batching disabled", and with the "Update list
of packets in real time" and "Automatic scrolling in live capture" display
options enabled) it took the Wireshark GUI over 10 minutes to "catch up" and
respond to the click of the capture "Stop" button after I had sent a burst of
3000 multicast packets (which only took 0.77 seconds to send).
When I let dumpcap run with its normal blocking/batching mode and clicked on
Wireshark's capture "Stop" button, the GUI responded, updated and displayed the
(buffered) burst of 3000 packets virtually immediately.
Am I seriously considering fixing it? I would like to think I could, but I'm
probably not a strong enough programer to be up to the challenge. But that's
not stopping me from investigating. ;-)
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
