Attention is currently required from: arehbein, daniel.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-netif/+/34224 )
Change subject: stream tests: Eliminate timestamps from output
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
> I didn't see any reason as to why it should be my patch introducing the differing behavior, because […]
Simply and plain for me: I just submitted a test patch based on libosmo-netif master and it's passing tests fine:
https://gerrit.osmocom.org/c/libosmo-netif/+/34231
which means whatever problem you are having, it may be a local problem or something related to your patch.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/34224
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-netif
Gerrit-Branch: master
Gerrit-Change-Id: I7faed932927d4f6e328a28c7f30a647a7272e89c
Gerrit-Change-Number: 34224
Gerrit-PatchSet: 2
Gerrit-Owner: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: arehbein <arehbein(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 29 Aug 2023 08:49:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: arehbein <arehbein(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: pespin, daniel.
arehbein has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-netif/+/34224 )
Change subject: stream tests: Eliminate timestamps from output
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
> I'm sorry but I just have the feeling that you are now just simply giving an excuse saying they are […]
I didn't see any reason as to why it should be my patch introducing the differing behavior, because I didn't change any of the patch logic in between leaving for vacation and working on it again now without 'random' times.
I tried resetting libosmocore to an older patch (pre-'my vacation'), but that didn't fix it.
So I looked around a bit and isolated the only other changes have been made to libosmo-netif recently. I eliminated those changes and it works now. The result can be found on the branch `arehbein/stream_tests_timestamp_behavior`.
It's a result of resetting `master` to `8355b65d` and applying the patch for client-side IPA segm. support as well as IPA-mode for sending messages.
```
$ git branch
arehbein/libosmo-netif_segm_cb_changes
arehbein/osmo_io_ipa
arehbein/stream_tests_no_timestamps
* arehbein/stream_tests_timestamp_behavior
```
```
$ git log --pretty=format:"%h %an %x09%s" arehbein/stream_tests_timestamp_behavior..master # Commits on master, but not on ...
aede0106 arehbein stream test: Fix test output check
f990b307 arehbein stream: Add server-side (segmentation) support for IPA
74b62628 Pau Espin Pedrol stream: Use new flag OSMO_SOCK_F_SCTP_ASCONF_SUPPORTED for SCTP sockets
18c160a0 Pau Espin Pedrol stream_cli: Forward SCTP MSG_NOTIFICATION to upper layers
deafe50c Pau Espin Pedrol stream: Refactor sctp_recvmsg_wrapper() logging
a49a2b4d Pau Espin Pedrol stream_srv: Log SCTP REMOTE_ERROR events
bcfa37ad Pau Espin Pedrol stream_srv: sctp: Log error cause of COMM_LOST event
7d143015 Pau Espin Pedrol sctp: Document relevant RFC specs
48f9a3c2 Pau Espin Pedrol stream_cli: Proper handling of send() socket errors
3ee52742 Pau Espin Pedrol stream_srv: Handle ESHUTDOWN and other write() errors destroying the socket
a69a958a Pau Espin Pedrol stream: Append data to current tail of message upon recv()
b8fb6954 Pau Espin Pedrol stream_srv: Improve logging lines accepting new connections
7e68ac2c Pau Espin Pedrol stream_srv: call setsockopt(SO_NOSIGPIPE) also in srv sockets
f42d4c3b Pau Espin Pedrol stream_srv: Use LOGSLNK() to print log line
1f7c44a1 Pau Espin Pedrol stream_cli: Increase log level of established conn to INFO
```
```
$ git log --pretty=format:"%h %an %x09%s" master..arehbein/stream_tests_timestamp_behavior # Commits on ..., but not on master
b4caa60f arehbein stream: Add and use IPA send function
7dc6be89 arehbein stream: Add client-side (segmentation) support for IPA
4d7172fa arehbein stream: Add server-side (segmentation) support for IPA
```
The commits titled `stream: Add server-side (segmentation) support for IPA` only differ in positional data in one spot as well as in reference hashes pertaining to git data.
The last commit on `arehbein/stream_tests....` doesn't make a difference (tried that with `git rebase` and breaking before the patch is applied).
There are a couple of changes one could look at, is it really worth going through them all with git bisect, adding my commits on top (including resolving merge conflicts) and checking if timestamps go 'random' to find out what causes a minor fluctuation in select-loop iterations that are needed to achieve the same end result?
Especially considering that the reason is most likely some logic running over variable amounts of select loop iterations. What difference does it make, or what would the consequential action be?
I have stated a reason why we shouldn't need timestamps, as well.
--
To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/34224
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-netif
Gerrit-Branch: master
Gerrit-Change-Id: I7faed932927d4f6e328a28c7f30a647a7272e89c
Gerrit-Change-Number: 34224
Gerrit-PatchSet: 2
Gerrit-Owner: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 28 Aug 2023 20:10:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment