[Sake Blok | SYN-bit <sake.blok@xxxxxxxxxx>]

Hi,

I fully agree with Hugo with regards to needing to look at the (individual) packets to be able to explain this behaviour. There can be tons of reasons. 

I do have a hunch though, based on the two graphs. As the packet sizes are mostly below MSS, there might be a Nagle/DelayedACK issue in this traffic. Nagle would cause segments to not be sent immediately and DelayaedACK would could ACK's after the delayed ack timer expires (usually 200ms). But again, without looking at the packets, this is just speculating.

Cheers,

Met vriendelijke groet,


Sake Blok
Relational therapist for computer systems

+31 (0)6 2181 4696
sake.blok@xxxxxxxxxx

SYN-bit
Deep Traffic Analysis
http://www.SYN-bit.nl

On 28 Mar 2019 (Thu), at 10:06, Hugo van der Kooij <hugo.van.der.kooij@xxxxxxxxx> wrote:

Graphs are just that. They can show you some information on where to focus your investigation.
But now you have to get into the trenches and fight it out with the sessions in packet to packet combat.

Based on just a graph there is no way to answer you questions.
So you have to dig into the packet capture AND understand what you are looking at.

There is now way to do that based on an interpretation (graph) of a packet capture in an environment no one here knows anything about.

Sorry, my cristal ball is out for repairs and I'm not expecting it back anytime soon.

​Met vriendelijke groet / Kind regards,​
​

Hugo

van der Kooij

network engineer

<image057856.png>

<image999920.jpg>

<image052689.jpg>

T:	+31 15 888 0 345		F:	+31 15 888 0 445
E:	hugo.van.der.kooij@xxxxxxxxx		I:	www.qsight.nl

Arnhem ‑ Delft ‑ Veldhoven

<image222234.png>

<image228962.png>

<image864457.png>

<image018609.jpg>

-----Original Message-----
From: Wireshark-users <wireshark-users-bounces@xxxxxxxxxxxxx> On Behalf Of L A Walsh
Sent: Thursday, 28 March 2019 07:15
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Subject: [Wireshark-users] How to interpret RTT graph

I was looking to understand the Round Trip Time graph and why it seems to jump up and down between near 0 and 270ms. That doesn't make sense to me -- first I don't see how some of them would have an RTT time of near 0 -- I don't see how that would be possible, so I figure I don't understand how to read the graph.

Also, I don't see why the RTT would jump up and down and why there are "gaps" in the graph like between 45-85 seconds, vs. almost a solid-like appearance between 380-410s.
Here is the RTT and througput graphs I'm trying to decipher:

https://i.imgur.com/4ijLxTJ.jpg

It looks like I have a relatively low latency when the graph peaks at around 150ms, but then something causes a jump so that latency climbs to over 250ms.

It also seems to be the case where I'm getting low latency that my throughput peaks with average packet length falling from 1500 down to <100bytes.

I don't see any clear errors. or why there is such a sudden drop

Should I be looking for some type of dropped packets or errors?

Could this be cause by my ISP cutting bandwidth in a step-wise manner as a means to control? Or could this be some sort of buffer-bloat with some buffer filling up and something halting output to wait for some buffers to drain...??

Another possibility is the application on my end is running on a high speed internal net with a 9k jumbo frame size -- could the mismatch between that the external frame size of 1.5k be causing some type of hysteresis?

Any ideas on how, if it is possible I might even this out?

It sorta wreaks havok with the local application...

Thanks!

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.wireshark.org%2flists%2fwireshark-users&c=E,1,8ZTsaNKt9SeZzVOdHVaJKKMZ34t7oRBLgJ8QJ3YXFu-GWQgY3-aqBRMtrYwzaHC1h0uBWfzcBeizriU4BhD935QttWCKY5uHvJhIxQkcz_9gLbwsSSZlvLYS7A,,&typo=1
Unsubscribe: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.wireshark.org%2fmailman%2foptions%2fwireshark-users&c=E,1,-snK-HCy8u_ZyNshnrpjna6CNcpbKQLU2YLFOkH8ZCyX51t8oIpMoSc3ZfuMAUXoj48UEJex4yovrTc1nJTL943AxSP6rl0x7xJOymGA3Msy64w,&typo=1
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe