On 9 November 2011 16:26, Bruce Ide <[email protected]> wrote: > Seems like running NTP would be an easy work-around. > > From a technical perspective, the clients could just set an epoch at the > start of the test and record samples from the start of the epoch. Then you > could normalize to the server's time or whatever without too much > difficulty. It would probably just be a matter of a couple of > changes to the SampleResult generation code.
The results are generated on the individual hosts. They are then combined on the client, which is where any clock skew will cause problems. If the client/server exchanged currentTimeMillis at the start of a test, then either the client or the server could "normalise" the clocks. Probably better for the client to do it as the server would not know how "old" the client message was. Whereas the client can measure any delay in initial the server response and take appropriate action. Proper normalisation implies that JMeter somehow knows which clock is correct; I don't think that's possible. All that JMeter could do is pick one of the values - or an average - and use that. > I'm all entrenched in my current project and won't have free time until > sometime in 2012. All the source is out there, though, so if you know (or > are) a java programmer who can submit a patch, you could probably get a > feature in sooner rather than later. Indeed, patches via Bugzilla welcome. [Please don't send patches to the list; please use unified diff format] > -- > Bruce Ide > [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
