Hi I'm using tshark which is installed in embedded linux running on powerpc 440 of FPGA board. I use tshark to analyze MPEG transport stream for FHD H.264. but I'm getting packet loss when I analyze the video stream in real-time with tshark and therefore I used tcpdump to capture packets instead of tshark and then analyze the saved packets with tshark. I'm getting much better result but still there is packet loss. I don't know why I get packet loss. I don't think that it is caused by the cpu getting overloaded because many times I'm able to analyze FHD with tshark without getting packet loss. is there anyone who knows what causes the packet loss? is there some buffers in embedded Linux causing the packet loss? I tried to increase the size of the UDP buffer without getting better result..
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2009/9/3 Guy Harris
<guy@xxxxxxxxxxxx>
On Sep 1, 2009, at 8:19 AM, martin wrote:
> Does anybody know if there is any intentions to address the single-
> threaded implementation of Wireshark in the future?
> Wireshark is a great tool but suffers from performance issues when
> tracing a conversation or doing other filtering for instance.
Wireshark's performance when tracing a conversation or doing other
filtering?" Ask whether there is an intent to improve performance,
not whether there's an intent to use a particular mechanism for
improving performance, as there might be ways of improving performance
more effective than just throwing more CPU at the problem (especially
if, for example, the problem is with memory usage, not CPU usage).
The answer to that question is "yes"; a bunch of changes have been
checked into the main branch that should improve performance in a
number of places, and at least some of them will, I think, address the
items you're talking about. There are also a number of ideas that
haven't been implemented yet.
And, yes, some thought has been given to what would be involved in
using more than one CPU core to do dissection. It's not trivial -
packet dissection is not even close to an "embarrassingly parallel"
problem, as the dissection of a given packet can, in a number of ways,
depend on previous packets.
There will probably have to be a more general notion of
"conversations", with conversations existing at multiple protocol
layers (both above and below the network and transport layers), and
packets within a conversation for that protocol will, for many
protocols, *not* be able to be dissected in parallel, at least for
that protocol. If a capture has enough separate conversations at all
layers, there should be enough parallelism to get some performance
gains (where "enough" might be "at least as many conversations as
there are independent cores"; whether "cores" should be replaced by
"processor threads" with multi-threaded processors is another matter).
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
