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/wip/pdch-alloc has been updated
discards 6b36049b1adc63886cbb9c4b51185caaba1c675d (commit)
discards b01199cc6d95be9dee18a5e476d528f5eba91a99 (commit)
discards 01213ceba8b84da093dbe9aa50828696a00e688f (commit)
via 7a4bd9661bd5b5297132ea55c16cd8a5248cb693 (commit)
via 66ba0844be5058032cb31c6ee3e31428417b171f (commit)
via 6eed1911fd619fb594a9d1a7fc734c1f62ff2f08 (commit)
via b31f5ef69963c4e8139515368a3bf867a5d76b00 (commit)
via d4ad731baecb1993481941b0cbb6b6d512708572 (commit)
via 4f666bc1136eb581d11dc47741928725c76b09c6 (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 (6b36049b1adc63886cbb9c4b51185caaba1c675d)
\
N -- N -- N (7a4bd9661bd5b5297132ea55c16cd8a5248cb693)
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=7a4bd9661bd5b5297132ea55c16cd8a…
commit 7a4bd9661bd5b5297132ea55c16cd8a5248cb693
Author: Jacob Erlbeck <jerlbeck(a)sysmocom.de>
Date: Tue Jul 14 08:26:17 2015 +0200
alloc: Optionally enforce first common TS in find_multi_slots (TODO)
TODO:
- This isn't probably triggered at all currently, so this commit
can possibly be dropped
http://cgit.osmocom.org/osmo-pcu/commit/?id=66ba0844be5058032cb31c6ee3e3142…
commit 66ba0844be5058032cb31c6ee3e31428417b171f
Author: Jacob Erlbeck <jerlbeck(a)sysmocom.de>
Date: Tue Jul 21 17:25:52 2015 +0200
bssgp: Use measured leak rate for flow control (EXPERIMENTAL)
THIS IS EXPERIMENTAL, DO NOT USE IN PRODUCTION
The leak rate sent to the SGSN does not reflect the current CS level,
lost frames, and control message overhead.
Use the ratio between sent blocks and successfully received bytes to
derive the net leak rate.
TODO:
- The values are not stable, possibly resulting from interference
with the sampling rate or from the interval between send and
receive if they fall into different sampling intervals.
- Perhaps the rate can be computed from sent data bytes / sent data
frames or from the average packet size and the global nack rate.
-----------------------------------------------------------------------
Summary of changes:
src/gprs_bssgp_pcu.cpp | 67 +++++++++++++++++++++++++++++++++++++++++++----
src/gprs_bssgp_pcu.h | 4 +++
src/gprs_codel.c | 24 ++++++++++++-----
src/gprs_codel.h | 48 ++++++++++++++++++++++-----------
src/gprs_ms.cpp | 2 +-
src/gprs_rlcmac_sched.cpp | 4 +++
src/pcu_main.cpp | 2 ++
src/tbf.h | 9 ++++++-
src/tbf_dl.cpp | 38 ++++++++++++++++++++++-----
tests/Makefile.am | 3 ++-
tests/codel/codel_test.c | 2 +-
11 files changed, 166 insertions(+), 37 deletions(-)
hooks/post-receive
--
UNNAMED PROJECT