Hey there!
I am trying to use tshark for printing UDP data and I noticed a delay of 0.6 seconds between the frame info time epoch and the actual writing to stdout.
I am using UBUNTU 22.04 with 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz and 16GB RAM in performance mode, so it is quite strange.
The command I am running is /usr/bin/tshark -l -n -x -i lo -f "udp port 7777".
Is there any way to make the output faster?
I tested on a linux VM in my lab with the command date +"%T.%6N" | nc -u 127.0.0.1 7777
It does not show such a high delta on my VM (Ubuntu 20.04 LTS):
sake@jump:~$ /usr/bin/tshark -c1 -ta -l -n -P -x -i lo -f "udp port 7777"; date +"%T.%6N"
Capturing on 'Loopback: lo'
1 17:42:13.157521841 127.0.0.1 → 127.0.0.1 UDP 58 59670 → 7777 Len=16
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 2c e4 9c 40 00 40 11 58 22 7f 00 00 01 7f 00 .,..@[email protected]"......
0020 00 01 e9 16 1e 61 00 18 fe 2b 31 37 3a 34 32 3a .....a...+17:42:
0030 31 33 2e 31 35 35 30 38 33 0a 13.155083.
1 packet captured
17:42:13.219419
sake@jump:~$
The timestamps I see are:
17:42:13.155083 (0.000) Date generated it's output
17:42:13.157521 (0.002) Libpcap timestamped the packet
17:42:13.219419 (0.062) Tshark exited (so printing to STDOUT had definitely finished already)
What does your system show with the test above?
In that case my system show the output fast, so if you don't mind I would ask you for the whole case: When running with python3.11
import subprocess
import time
print(time.time())
p = subprocess.Popen(['ls', '-R', '/home'], stdout=subprocess.PIPE)
d = p.stdout.read(100000)
print(time.time())
`
it prints:
1677505233.4244854
1677505233.4286182
but when I run:
import subprocess
import time
p = subprocess.Popen(['/usr/bin/tshark', '-ta', '-x', '-q', '-f', 'udp port 7777', '-i', 'lo', '-T', 'json'], stdout=subprocess.PIPE)
d = p.stdout.read(100000)
print(time.time())
print(d)
and send packets with for ((i=0;i<10;i++)); do date +"%T.%6N" | nc -u 127.0.0.1 7777; done
the last epoch that is printed is 1677505307.545133347 but the time that is printed is 1677505308.2807975
When I use your python script, I too get around ~600ms difference. It boils down to:
So that leaves ~200 ms which is added by the python processing.
So for the 600ms, they are not so much a tshark issue in my opinion. I personally have no experience in profiling and improving python script performance.
Thanks a lot for your help!
How do you disable the name lookups?
My initial feeling was that python is the problem too, but running tcpdump / ls / yes with different sizes stays fast (around 0.004 seconds), event if I measure the initial time before calling the Popen
https://discord.com/channels/88921418...
Dumpcap only sends packet counts to its parent every 500 ms. Seems like that could be faster. For slow displays over VNC, or people who just like the delayed update, couldn't the update delay be a GUI setting? It also means that autostop / file switching granularity is limited to half a second too.
Asked: 2023-02-26 09:02:11 +0000
Seen: 378 times
Last updated: Mar 08 '23
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Normally its the case that the buffer size is increased (-B|--buffer-size <capture buffer="" size="">) because packets are being dropped.
If the packet rate is low, perhaps decreasing the buffer will reduce the latency.
tcpdump has the
--immediate-modeoption but there is no such option fordumpcap(ortshark).Unfortunately, tcpdump doesn't have -T json
Did you try a smaller buffer with
tshark?I tried, the minimum buffer configurable is 1MiB as long as I understand