On 27 September 2018 at 15:16, Philippe Mouawad <[email protected]> wrote: > Hello, > What do you think of increasing timestamp precision up to micro or nano > seconds ?
We looked at this a few years ago. There is already some code in SampleResult. There were quite a few issues with getNanoTime, e,g, significant drift on some systems, which is why there is the thread to keep the offset updated. Also nanoTime is only designed for elapsed time, not wall-clock time, so has to be used in conjunction with getTimeMillis for timestamps. > For example: > - When sending data to TimeSeries DB like InfluxDB, with current precision > of millis, we can end up overwriting some value if user wants to send data > to InfluxDB as in the same MS you can trigger many same Transactions. > > If we go up to Nanos we would be able to handle such cases without issues. That would help, but there is still the possibility of multiple transactions with the same timestamp. (Many OSes don't support nano-second granularity) In any case, if duplicate times are a problem for databases such as InfluxDB, then it seems to me that is a separate issue which needs a different solution. > With improvement in performances and systems being more able to handle very > high throughput I think we should consider this. And if the systems get fast enough they may be able to send multiple requests in a nanosecond, thus causing problems for InfluxDB again. So whilst it should help, it's not a complete solution, and I think it is orthogonal to the issue of JMeter timestamp precision. I'm not saying we should not consider increasing the timer resolution. > And this should also probably include updating Response time precision to > nanos. However any solution needs to be backward compatible. AFAIK it's not possible to support microseconds without using getNanoTime, so I don't see the point of limiting the resolution to microseconds. One possible approach would be to add another method to return the nano second remainder. > > -- > Regards > Philippe M
