> At the moment there is a timeout of 4s to allow androiddump to connect to ADB.
I should be fixed right now and timeout should be 10ms (aka
non-blocking socket on Windows and <maybe> on Linux/FreeBSD). If it is
no 10ms (no ADB daemon started), then there is only a need to do truly
non-blocking socket also for Linux/etc. (follow Windows solution).
Current solution works (for me) on Linux (Ubuntu and LFS).
The question is why there is significant delay for Guy, but not for
me. I use Linux+cmake (out of source) + run Wireshark(s) from, build
directory.
Dario, could you share your results for:
$ adb kill-server
$ time run/extcap/androiddump --extcap-interfaces
My results:
real 0m0.013s
user 0m0.000s
sys 0m0.001s
> about .26 seconds for randpktcdump
It seems that your OS is much more slower than me in case of loading
programs. What is it?
"strace -tt -v ./run/tshark -D" may show there reason for it.
Is that true that g_dir_open() is call many times for all extcap
captures? It may be slow on some file[/]systems.
Maybe the problem is extcap architecture: "small" binaries that must
be run. We can (?) change it to
libraries (plugins) + one generic small application that use "plugin".
Then it is possible to link or dlopen libraries by Wireshark, but
still can run it as standalone apps. I think that can save significant
loading time and multiplatform compatibility.
In other words:
./genericExtcapTextUI --load=randpktdump --extcap-interfaces
or
./wireshark # it dlopen("libextcap_randpkt.so") etc.
2017-03-27 22:33 GMT+02:00 Guy Harris <[email protected]>:
> On Mar 27, 2017, at 1:14 PM, Guy Harris <[email protected]> wrote:
>
>> Currently, with that fix, I get results like
>>
>> $ time ./tshark -r /tmp/nothing.pcap
>>
>> real 0m1.407s
>> user 0m0.312s
>> sys 0m0.676s
>>
>> with the extcap directory in place and results like
>>
>> $ time ./tshark -r /tmp/nothing.pcap
>>
>> real 0m0.334s
>> user 0m0.182s
>> sys 0m0.146s
>>
>> with the extcap directory moved out of the way, so the extcap executables
>> are taking some time to run, but it's better than wasting time trying to run
>> androiddump.c or Makefile.am.
>
> And, if I move various extcap executables out of the way:
>
> $ time ./tshark -r /tmp/nothing.pcap # all executables
>
> real 0m1.484s
> user 0m0.313s
> sys 0m0.720s
>
> $ time ./tshark -r /tmp/nothing.pcap # after removing androiddump
>
> real 0m1.179s
> user 0m0.287s
> sys 0m0.588s
>
> $ time ./tshark -r /tmp/nothing.pcap # after removing ciscodump
>
> real 0m0.950s
> user 0m0.254s
> sys 0m0.491s
>
> $ time ./tshark -r /tmp/nothing.pcap # after removing randpktcdump
>
> real 0m0.688s
> user 0m0.228s
> sys 0m0.334s
>
> $ time ./tshark -r /tmp/nothing.pcap # after removing sshdump
>
> real 0m0.493s
> user 0m0.198s
> sys 0m0.235s
>
> $ time ./tshark -r /tmp/nothing.pcap # after removing udpdump
>
> real 0m0.335s
> user 0m0.183s
> sys 0m0.145s
>
> So that's about .3 seconds for androiddump, about .23 seconds for ciscodump,
> about .26 seconds for randpktcdump, about .19 seconds for sshdump, and about
> .16 seconds for usbdump.
>
> So none of them are individually out of the ordinary, but about 1.5 to 2.5
> seconds per program, with 5 programs, adds up.
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <[email protected]>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:[email protected]?subject=unsubscribe
--
Michał Łabędzki
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
