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(a)radisys.com
Cc: Max <msuraev(a)sysmocom.de>de>; osmocom-net-gprs(a)lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question
On 26 Feb 2016, at 21:23, Saurabh Sharan
<Saurabh.Sharan@radisys.com<mailto: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