Hello Holger,

The extraction was done manually from wireshark capture file. I have not created any script for this.

Steps were

· Set time display format in wireshark capture for microseconds and from beginning of capture

· Filter the log for TS 4 (control TS was chosen) and direction downlink ((gsmtap.uplink == 0) && (gsmtap.ts == 4))

· Keep column display for GSM Frame Number in the wireshark capture

· After this Print “output to file” utility in wireshark for “as displayed” converts the displayed capture into text

· Copy entire text and delimit with whitespace in an excel sheet

· Add formula for time difference and frame number difference between previous to next row (for time difference multiply by 1000 to get milliseconds)

· These new rows will serve as further elements for plot and analysis

Regards

Saurabh

-----Original Message-----
From: Holger Freyther [mailto:holger@freyther.de]
Sent: Monday, February 29, 2016 11:22 PM
To: Saurabh Sharan <Saurabh.Sharan@radisys.com>
Cc: Max <msuraev@sysmocom.de>; osmocom-net-gprs@lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question

> On 26 Feb 2016, at 21:23, Saurabh Sharan <Saurabh.Sharan@radisys.com> wrote:

>

> Hello Max,

Dear Saurabh,

> Please find below chart that indicate time skew is happening in the setup.

> I have also attached the excel sheet used for this analysis here for reference.

> TS4 in downlink is considered for drawing the plot. Please note that block duration value of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of 4,4,5,4,4,5,..and so on.

> 4FN duration is 18.4ms and 5 FN is 23 ms approx.

> But the spikes in the system as high as 26.8ms may result in incorrect air interface behavior from L1.

how did you extract the values? Did you create a lua script for wireshark/tshark? It would be interesting to automate this.

kind regards

                holger