[PATCH] osmo-bts[master]: bts-trx: Avoid enqueueing consecutive duplicate messages to TRX

[Pau Espin Pedrol]

Review at  https://gerrit.osmocom.org/5237

bts-trx: Avoid enqueueing consecutive duplicate messages to TRX

While debugging other protocol/timing issues between osmobts-trx and osmo-trx,
I found that sometimes two consecutives "POWER OFF" commands are
enqueued and sent to osmo-trx.
There's no point in doing so, as the write queue already maintains state
and retries the command until a RSP is received, then goes for the next
one.

With this change we hence improve timing response as we don't need to
wait for the second command to be processed, and on top we get cleaner
logs and simplified states which are easier to debug.

Change-Id: Ib6a5e7bfac8bc5e1b372da6a1f801c07a3d5ebb7
---
M src/osmo-bts-trx/trx_if.c
1 file changed, 7 insertions(+), 2 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/37/5237/1

diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c
index 1ac21d5..57fd953 100644
--- a/src/osmo-bts-trx/trx_if.c
+++ b/src/osmo-bts-trx/trx_if.c
@@ -214,8 +214,13 @@
 	tcm->cmd[sizeof(tcm->cmd)-1] = '\0';
 	tcm->cmd_len = strlen(cmd);
 	tcm->critical = critical;
-	llist_add_tail(&tcm->list, &l1h->trx_ctrl_list);
-	LOGP(DTRX, LOGL_INFO, "Enqueuing TRX control command '%s'\n", tcm->cmd);
+
+	/* Avoid adding consecutive duplicate messages, eg: two consecutive POWEROFF */
+	if (!pending ||
+	    strcmp(tcm->cmd, llist_entry(l1h->trx_ctrl_list.prev, struct trx_ctrl_msg, list)->cmd)) {
+		LOGP(DTRX, LOGL_INFO, "Enqueuing TRX control command '%s'\n", tcm->cmd);
+		llist_add_tail(&tcm->list, &l1h->trx_ctrl_list);
+	}
 
 	/* send message, if we didn't already have pending messages */
 	if (!pending)

-- 
To view, visit https://gerrit.osmocom.org/5237
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib6a5e7bfac8bc5e1b372da6a1f801c07a3d5ebb7
Gerrit-PatchSet: 1
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>