[PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much

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

Peter Stuge peter at stuge.se
Thu Jan 30 15:43:05 UTC 2014


Jacob Erlbeck wrote:
> > +/* add sec,usec to tv */
> > +static void tv_add(struct timeval *tv, int sec, int usec)
> > +{
> > +
> > +	while (usec < 0) {
> > +		usec += USEC_1S;
> > +		sec--;
> > +	}
> > +	tv->tv_sec += sec;
> > +	tv->tv_usec += usec;
> > +	while (tv->tv_usec >= USEC_1S) {
> > +		tv->tv_sec++;
> > +		tv->tv_usec -= USEC_1S;
> > +	}
> > +}
> 
> I'm not sure whether it is a good idea to use while loops in this case
> since CPU usage is O(N) of the usec value.

Remember that N>1 only with very small or very large usec values,
which I guess will be a corner case since it wasn't handled before?


> Wouldn't it be more convenient to have a function tv_add_us(tv, usec)
> instead that does the div/mod stuff to a temporary timeval and then
> just calls timeradd()?

Is there a machine where div/mod is actually more efficient than a
small number of iterations around a loop? :)

Is this a hot path? Then I think it makes sense to optimize harder
for performance rather than for readability. But compilers are good
at that too..


//Peter




More information about the OpenBSC mailing list