osmo-pcu.git branch jerlbeck/master updated. 0.2-589-gaf75ce8

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-commitlog@lists.osmocom.org/.

gitosis at osmocom.org gitosis at osmocom.org
Fri Aug 28 12:36:50 UTC 2015


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".

The branch, jerlbeck/master has been updated
  discards  e7349128e1525719e7fa9b3ab39b66f98f0f89e7 (commit)
  discards  7deb3648c75e5dfc289302c566f2f1d82bf39043 (commit)
  discards  3198c43c2b35f13b2a78fcb379635b35c59fb6b2 (commit)
  discards  ea4b1fd348bb869f5705c434690d843f0d3c9d38 (commit)
  discards  bacf9c806a0f63bff29a33e7c5711f9d4ea7d53f (commit)
  discards  73aa9f586ece8949bc9d3d94c337e105a1a0b9c9 (commit)
       via  af75ce8e15ec8584cbc96a0cd366a5df68b9dae8 (commit)
       via  be4a08b58ae17b44d2c02421d8346a1ccb63a6b9 (commit)
       via  60f77033ad15da909cdbc0682c781151a23c170c (commit)
       via  e77d49f2a2c20202dbdc5386c7dfeed4e773a077 (commit)
       via  ac49d0943a2a384ef99cce0933cac74d80563407 (commit)
       via  16d29c7da4ee516b4ef0a6ec18cec18f8a76d7fa (commit)
       via  b6b3c7eb2727da98fbba231d9a1e9fe4a33b2dd0 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (e7349128e1525719e7fa9b3ab39b66f98f0f89e7)
            \
             N -- N -- N (af75ce8e15ec8584cbc96a0cd366a5df68b9dae8)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-pcu/commit/?id=af75ce8e15ec8584cbc96a0cd366a5df68b9dae8

commit af75ce8e15ec8584cbc96a0cd366a5df68b9dae8
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Wed Aug 26 13:22:28 2015 +0200

    l1: Use the FN of all data_ind/ra_ind DSP messages
    
    Currently all of these messages are discarded if they are assumend to
    be caused by noise. But even in these cases, the FN and TN values
    which are added by the DSP are valid. So these can be used to update
    the current_frame value.
    
    The osmo-bts sets the fBFILevel of a physical channel to -200dB if it
    is used for PDTCH or PACCH which is the case for all PDCH. This way
    a data_ind or ra_ind message is already send at least once per block
    period (4 frames) per PDCH. These messages are passed to either
    handle_ph_data_ind or handle_ph_ra_ind even if they contain garbage
    data.
    
    The ra_ind messages are sometimes sent a few frames earlier than
    data_ind messages using the same frame.
    
    This commit adds calls to update the current_frame value based on all
    of these messages before they are discarded. The FN taken from ra_ind
    are passed with an increased max_delay (5) to compensate for early
    ra_ind messages.
    
    Sponsored-by: On-Waves ehf

http://cgit.osmocom.org/osmo-pcu/commit/?id=be4a08b58ae17b44d2c02421d8346a1ccb63a6b9

commit be4a08b58ae17b44d2c02421d8346a1ccb63a6b9
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Tue Aug 25 15:19:31 2015 +0200

    poll: Count unexpected block FN values
    
    Currently a log entry is written if FN_data_ind - FN_time_ind <= -13.
    
    This commit adds a counter 'rlc.late-block' that is incremented in
    these cases.
    
    Sponsored-by: On-Waves ehf

http://cgit.osmocom.org/osmo-pcu/commit/?id=60f77033ad15da909cdbc0682c781151a23c170c

commit 60f77033ad15da909cdbc0682c781151a23c170c
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Mon Aug 24 14:35:14 2015 +0200

    poll: Use the data_ind FN as time source for current frame
    
    The FN of the data_ind taken from the DSP are monotonic, so latency
    does not affect the detection of poll timeouts if these FN are used.
    If the FN is larger than a poll_fn value, it can safely be assumed
    that the poll response will not arrive later on.
    
    Currently a max_delay of 60 frames is used, which has the drawback
    that additional ~250ms will pass until a lost ACK is detected.
    
    Using the data_ind's FN alone breaks the poll timeout detection if
    there are no other MS sending data blocks.
    
    This commit adds BTS::set_current_block_frame_number that is called
    with the FN taken from data_ind messages. The max_delay is set to 0
    which removes the additional delay, when this FN is used to detect
    poll timeouts. So the average additional delay decreases with the
    number of data_ind per time. The current_frame is updated unless it
    seems to have been updated already (assumed if 0 < cur_fn - block_fn
    < 500). Thus the time_ind has still priority to update the
    current_frame value.
    
    Sponsored-by: On-Waves ehf

http://cgit.osmocom.org/osmo-pcu/commit/?id=e77d49f2a2c20202dbdc5386c7dfeed4e773a077

commit e77d49f2a2c20202dbdc5386c7dfeed4e773a077
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Thu Aug 27 13:28:05 2015 +0200

    poll: Set the max_delay to 60 frames
    
    Currently the max_delay parameter is set to 13, since that is
    slightly above maximum number of frames that a time_ind can preceed a
    block's data_ind of the same frame. This assumes that these messages
    are not reordered after thay have been obtained from the DSP. In the
    current implementation, the GPRS data_ind can directly be taken from
    the DSP by the PCU while the time_ind messages are provided via the
    BTS. So the messages are queued differently in that case, resulting
    in a additional delay of the data_ind with respect to the time_ind.
    The propability for this raises with a increased CPU load of the PCU.
    
    If this happens, a poll timeout is detected by mistake and the poll
    is either retried or cleared.
    
    This commit increases the tolerance to 60 frames, since
    values for FN_data_ind - FN_time_ind of up to 50 frames have been
    observed under heavy PCU load.
    
    Sponsored-by: On-Waves ehf

http://cgit.osmocom.org/osmo-pcu/commit/?id=ac49d0943a2a384ef99cce0933cac74d80563407

commit ac49d0943a2a384ef99cce0933cac74d80563407
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Thu Aug 27 13:18:24 2015 +0200

    poll: Add a max_delay parameter to PollController::expireTimedout
    
    Currently the maximum additional delay is hard coded to 13. This
    value depends on the source of the frame number value.
    
    This commit adds the max_delay parameter to make it caller dependant.
    
    Sponsored-by: On-Waves ehf

http://cgit.osmocom.org/osmo-pcu/commit/?id=16d29c7da4ee516b4ef0a6ec18cec18f8a76d7fa

commit 16d29c7da4ee516b4ef0a6ec18cec18f8a76d7fa
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Mon Aug 24 13:30:39 2015 +0200

    tbf: Add logging for polling
    
    This commit adds the relevant frame number to the "poll timeout"
    logging message. In addition, logging is added to the places where
    poll_fn gets set.
    
    The goal is to track down the source for frequent "poll timeout"
    messages.
    
    Sponsored-by: On-Waves ehf

-----------------------------------------------------------------------

Summary of changes:
 src/tbf.cpp         | 103 ++++++++++++++++++++++++++++++++++++++++++----------
 src/tbf.h           |  14 ++++---
 tests/ms/MsTest.cpp |  22 +++++------
 3 files changed, 103 insertions(+), 36 deletions(-)


hooks/post-receive
-- 
UNNAMED PROJECT



More information about the osmocom-commitlog mailing list