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/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgNeels Hofmeyr has posted comments on this change. ( https://gerrit.osmocom.org/11119 ) Change subject: make SCCP timers configurable ...................................................................... Patch Set 2: the related ticket was a sysmocom internal one, so let me copy the remark here: " we have plenty of other timers already configurable in the osmocom universe, and we never suffix them with the unit. Rather, we document the unit in the help so that if you press tab, you will get some information as to what the unit is. I don't argue the existing behavior is better than your implemented one, but for the sake of consistency I would think it makes sense to align with the existing behavior. See for example the various tXXXX that are configurable in BSC an MSC. " I even tried to just copy the T... implementation from osmo-bsc, but it doesn't match. These timers here have names, not numbers. The T timers sometimes have really convoluted units that the user needs to familiarize with anyway, while all of these SCCP timers are a plain duration in "real time". A less important aspect: they are specified in ITU-T, not 3GPP. I see the consistency POV, and actually also considered making everything one unit. That would be seconds then. After contemplating back and forth I ended up with this implementation instead. If all are seconds, users then need to multiply/divide by 60 in the head for most timers, which are in the range of minutes. For the few shorter timers of about 10 seconds, I lose the ability to set sub-second timers. Not sure if it's relevant in practice, but for a value of a few seconds I thought it better to also allow higher resolution. But I definitely don't want to supply a timer of 11 minutes in milliseconds, UI wise. A timer as low as 20 minutes would already surpass a million. If we defined longer-specified timers as in-seconds, and shorter ones as in-milliseconds. If you really want that I can do it, but I don't like the inconsistency/non-readability between the individual sccp timers then. sccp-timer ias 300 sccp-timer iar 660 sccp-timer rel 10000 That really reads like "wtf". For me the best fixed unit choice then would be seconds for all timers, and losing the sub-second value range. I agree that consistency is good, yet it doesn't really match / help here IMHO. How about optional units? All default to seconds, but for convenience a 'm' or 'ms' can be added to spare the factor of 60 / to allow sub-second values? -- To view, visit https://gerrit.osmocom.org/11119 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmo-sccp Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65 Gerrit-Change-Number: 11119 Gerrit-PatchSet: 2 Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder (1000002) Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Comment-Date: Thu, 27 Sep 2018 12:35:03 +0000 Gerrit-HasComments: No Gerrit-HasLabels: No -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180927/32d2dfef/attachment.htm>