O$: #FT - Hundredths

Sun May 11 05:24:38 EDT 2008

Hi Geir,

Thanks, hope your well.

What I want to do is measure any degree of jitter / freeze in the execution of a method.  So from a 100 iterations of executing the method I can "time" each one and then measure, min, max, avg and std from the sample data I rather.

It is going to be used for testing the response time from an Omnis Server across a LAN to a set of Omnis Client load generators creating repeated HTTPGet requests to the Omnis server.  So I can try various different things on the Server and see what effect it does or doesn't have in the application performance to the client, as what I am most worried about is concurrency causing delays through queuing requests and working to minimize this.

I have a battery of tests and tweaks I have identified that I want to try and the accuracy will only be super critical when the size of the data pages returned is small - which is when queuing should also be small and so any glitching also small.  As the data payload increases in size the client elapse duration will increase and so the relative accuracy will improve at the same time that the potential, depending on how it is done, for queuing increases.

I imagine that 1/60th will be fine as this is 16ms +/- 8ms granularity and the typical RTT on broadband is 20 to 40 ms for ICMP echo request and if your squirting a 8MB file at 2Mb/s that would be 32 seconds.

Kind Regards

Ben

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com [mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Geir Fjærli
Sent: 11 May 2008 09:38
To: 'OmnisDev List - English'
Subject: RE: O$: #FT - Hundredths

Hi Ben.

I don't think(!) Omnis reports hundreths at all, while it can store dates at that resolution, at least I cannot get it to do so on Studio or Omnis 7. I might be wrong, but I believe the hundreds are there to support calculated time and time originating from systems that do reports hundreths. That may be because the Omnis isn't really capable of operating at that accuracy anyway, it is not a real time system.

You can use a #CT trick to achieve this, as suggested on the list many moons
ago:

What you do is assume that you will have #CT holding the tick count, as Peter says to 1/60th of a second. So doing a mod(#CT,60) would give you an extra bit of accuracy to store into the hundreths. Divide by 60 and multiply by 100 would then give you a number between 0 and 99, with a 1.6 hundreth accuracy. Then right justify that into two digits with a leading zero using the jst() function.

A little warning, though: There is a caveat with this approach.

While it does give you a pretty good approximate number it is not really suited for relative purposes. This is because the turning point of
mod(#CT,60) is entirely arbitrary, since you don't know when the first clock tick happened. If the system was started at a given time, #CT might have been zero halfway through a second. And so something happening .25 secs into the second might return a higher mod(#CT,60) value than something happening half a second later...

And also, if the system is running long enough, then #CT will eventually roll over and start at zero again.

So if you need to know that something happened approximately .35 second later than something else, then this will NOT work. As I said, Omnis is not a real time system. But for the purpose of comparison you don't really need a time variable, and should test #CT alone (bearing in mind that it might roll over at some point.)

But if you can live with the mentioned flaw then a variation on the following would probably do:

con(dat(#T,'H:N.S'),jst(rnd(mod(#CT,60)*100/60,0),'-2p0'))

The rnd() function may be overkill.

Geir :)

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Ben Butler
Sent: 11. mai 2008 08:13
To: OmnisDev List - English
Subject: RE: O$: #FT - Hundredths

Hi,

I am on Windows & Linux - both are doing the same thing:

Calculate #FT as 'HNSs'
Calculate #1 as tim(#T)

Is always returning 00 as the two most right hand digits.

I actually found the reference to 's' under the jst() function, but #T has 00 at the end as well.

So maybe they have taken it out again.

Was there a reference at some point the tick count of the processor #TICK or something like that or is sleep deprivation setting in and I am delusional?

Kind Regards

Ben

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Kelly Burgess
Sent: 11 May 2008 06:05
To: OmnisList
Subject: Re: O$: #FT - Hundredths

Hi Ben,

>What am I missing to get Omnis to report hundredths of a second.

Not sure about the current status, and I don't see anything in the docs about this, but back in the day, hundredths of a second worked on Windows but not on Macintosh.  I believe it was because the date/time structure for Mac OS doesn't include hundredths, while the structure for
Win23 does have a slot for it.

So if you're testing this on Mac, try the same test on Windows.

Kelly
_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com _____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com