This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Max msuraev at sysmocom.deI'm not sure what to make of this timing difference. I'm using sysmoBTS hw to test different osmoPCU versions (including ssharan/egprs) and I can see pacch timeouts on all of those I've tried. For some phones it really breaks connectivity, others seems to be able to ignore it somehow. I do not see a pattern yet. Do you have some test setup where you try it and see if it's the same for you? On 02/26/2016 04:13 PM, Saurabh Sharan wrote: > Hello Max, > Though I have not analyzed the missing UL poll response, few of my > observations from the pcap file attached is mentioned below > > 1. There seems to be difference in FN UL versus DL being processed at > any given time by the order of approx. 10 FNs, example given below > > 1. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 > 2. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972 > 3. From above example difference in time is 48milliseconds or > approx.. 10FN duration > > 2. For processing DL timeslots 2 to 6 at any given DL FN time taken > seems to be approx. 3milliseconds, example given below > > 4. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2 > 5. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6 > > Please let me know if these are known behavior in your integration > environment ? > These time variations may have an impact on the poll response behavior > from MS as well. > Regards > Saurabh > -----Original Message----- > From: Max [mailto:msuraev at sysmocom.de] > Sent: Thursday, February 25, 2016 3:58 PM > To: osmocom-net-gprs at lists.osmocom.org; Saurabh Sharan > <Saurabh.Sharan at radisys.com> > Subject: PCU scheduling and PACCH timeout question > Hello. > I'm trying to debug issue with current OsmoPCU master when some > basebands ignore polling requests. > The debug output from RLCMAC layer and corresponding .pcap files are > attached. > The issue appears somewhere after line 112 in debug.log The > corresponding packet in pcu.pcapng is 6866 > After receiving PACKET_CONTROL_ACK from phone we're trying to schedule > polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 > (packet 6874) which subsequently fails. > This seems suspiciously close but I have not found in the spec yet if > this is legitimate thing to do. > There are several other occurrences like that in both log and pcap. > Have you experienced something like this? Do you have an idea why only > some basebands are affected while others work fine? > -- > Max Suraev <msuraev at sysmocom.de <mailto:msuraev at sysmocom.de>> > http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/53498e1a/attachment.htm>