Our application uses UDP protocol in the transport layer.

I'm currently filtering the packet trace with the port and then manually checking the RTT by selecting the packet stream and by using " Set time reference".

As shown in the picture, I'm currently evaluating the performance manually.

  1. 3.47 rtt and 2. 3.7 rtt

I also tried to use the "Time delta from previous captured frame" in the Wireshark. However, Sometimes the application uses multiple sessions to send the complete payload.

What is the best and efficient way to benchmark and plot the UDP response time in an IO graph format?

enter image description here

  • Could you elaborate on "Sometimes the application uses multiple sessions to send the complete payload"? Is the traffic something like 1 C->S, 2 S->C, 3 S->C and you want the time between packets 1 and 3? How can you tell which replies are associated with which requests? – jonathanjo Feb 20 '19 at 10:32
  • The application daemon pull the data from the device X. So the traffic is like, 1 S-->C,2 C-->S,3 S-->C,4 C-->S.. Some time the same iteration can go towards 5 to 7 pairs of comms if the CRC validations are failed. Now, I need to calculate the total elapsed time daemon needed to pull the complete data from device X. In this case timestamp 1 to 4. The association(between request and replies) is actually in the payload which is encrypted and decryption it is nearly impossible with the current circumstances. All I know now is that it will not consume more than 10 seconds to reply. – Maverick Feb 20 '19 at 13:41
  • Sounds a little tricky to properly identify when a conversation is finished. Is there any way to bracket the fetch on the server by running the query just once? Something like ping -c 1 -p 1 C ; fetchdata C; ping -c 1 -p 2 or alternatively perhaps just time on server time fetchdata C – jonathanjo Feb 20 '19 at 16:51
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Apr 19 '19 at 14:45
  • 1
    If there's no (easy) way to filter the protocol in Wireshark to get a decent tracking, and it's "your" protocol, you can very easily implement a response tracking in the server or the client application. That however is more suitable for Stack Overflow and off-topic here. – Zac67 Jul 20 '19 at 11:46

Filter the displayed packets to only show one session. Use source and/or destination port/address. Then use the "Delta time displayed" field type.

enter image description here

  • There is more than million transactions and do you think it will work for a bunch of transactions? – Maverick Feb 20 '19 at 9:08
  • Why not? That's how the system distributes the right packets to the right socket. – UaT Feb 20 '19 at 9:30
  • Okay, I got what you meant. This will only give you the delta between the packet arrived. Like I mentioned before, Application sometimes uses multiple back and forth communication with the device. I'm looking for the complete duration of that session as shown in the picture. Besides,I already had the "Time delta from previous displayed frame" field in my colums – Maverick Feb 20 '19 at 10:08
  • Ok, now I get you too. I thought that you wanted the RTT for a packet and its response. – UaT Feb 20 '19 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.