That commit was done as a fix, because the previous solution didn't work in most of the cases. It relied on the internal track of time, but in case of blocking, the signal to update the value didn't happen, so my tests with latency for action (which used the same mechanism as for db) was most of the time 0, even I explicitly used sleep(few seconds). The unit ms -- not sure if previously was still expected to be micro-seconds or mili-seconds. The origin was somehow related to benchmark module which has micro-seconds accuracy (or nano-seconds if compiled with librt), but to make the measurements internally, not in config file, so I had in mind micro-seconds. If people consider it to be something breaking what they expected or they were used to (but again, it was not actually working), we can think of some option to add for time unit.

It is no regression as it was not working and it was expected to print what benchmark does when used in config file.

This features was added not to enclose each action in kamailio confg between a bm_start_time() and bm_log_time(), extended for db queries for better way to identify the slow operations.

So the actually expectation was to print micro-seconds as benchmakr does. Therefore multiplying with 1000 is not a proper fix here, it must stay microseconds in its base, with option to change if people want (or they expected) a different unit. That can be made default to miliseconds for old editions and let to microseconds for master branch. But I would go and ask in the community and see what most of them expected there as time unit.

@miconda - did we reached any conclusion here? Should the code be fixed or the documentation?

Just tested the upgrade to kamailio 5.2.3 and in fact now both the parameters (latency_limit_db and latency_limit_action) expect a micro-seconds value. I suggest to leave the code as is and instead fix the documentation, currently it suggesting to use milli-seconds.

Thanks

fixed in wiki for devel, 5.2 and 5.1.