Fast Timer's?

[Knowl Paine]

In my Advanced (develop) menu are Fast Timer's. Does anyone have any information or links explaining the Fast Timer's?

Some of the functions being monitored are self-explanatory but a few are not. I'm interested in the function Sleep.

There are times when it appears that the Sleep function is hanging and won't let go. What is sleeping, why is it sleeping; any help would be great.

[Knowl Paine]

I've found this so far, not entirely helpful. Maybe the problem will go away with V2.

 

Suspends the execution of the current thread until the time-out interval elapses .
The sleep() function shall cause the calling thread to be suspended from execution until either the number of realtime seconds specified by the argument ...
The function sleep gives a simple way to make the program wait for a short interval. If your program doesn't use signals (except to terminate), ...
The problem is this : if the scripter calls the sleep function with a high value , let's say : sleep(1500000) then your program will hang for 1500 seconds or ...
Jun 12, 2010 ... Re: Any way from stopping a recursive function from hanging up the application? This System.Threading.Thread.Sleep(100);

The time interval for which execution is to be suspended, in milliseconds.

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution.

This function causes a thread to relinquish the remainder of its time slice and become unrunnable for an interval based on the value of dwMilliseconds. The system clock "ticks" at a constant rate. If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on. To increase the accuracy of the sleep interval, call the timeGetDevCaps function to determine the supported minimum timer resolution and the timeBeginPeriod function to set the timer resolution to its minimum. Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock, system power usage, and the scheduler. If you call timeBeginPeriod, call it one time early in the application and be sure to call the timeEndPeriod function at the very end of the application.

After the sleep interval has passed, the thread is ready to run. If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. For more information, see Scheduling Priorities.

Be careful when using Sleep in the following scenarios:

•Code that directly or indirectly creates windows (for example, DDE and COM CoInitialize). If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock.
•Threads that are under concurrency control. For example, an I/O completion port or thread pool limits the number of associated threads that can run. If the maximum number of threads is already running, no additional associated thread can run until a running thread finishes. If a thread uses Sleep with an interval of zero to wait for one of the additional associated threads to accomplish some work, the process might deadlock.

sleep() (lower-case 's') is a unix/linux function and has an argument in seconds, and is defined in unistd.h (I think). Sleep() (upper-case 'S') is a Micro$oft Window$ function, and has an argument in milliseconds, and is defined in windows.h. Both versions of sleep allow other processes to gain CPU time while the calling process is idle. In 16-bit MS-DOS this isn't necessary because the calling function is the ONLY processing running on the computer, hence no implementation of sleep. Turbo C has delay(), which is similar to sleep, but that is a complier-specific function and probably not implemented by any other 16-bit MS-DOS compiler.

sleep() is one of the compiler specific functions, so it may not be available to you. For dos based compilers try #include <dos.h> As long as you use an ANSI compliant compiler, you can make your own timer function by adding time.h or ctime depending on C or C++

: The "DOS window" is not really a MS-DOS window at all -- its just another Win32 Window very similar to all other Win32 windows and shares the OS time exactly like all other windows -- regardless of what compiler you use. if you include windows.h in your program you can use Sleep(int milliseconds). Timing loops are of little use because (1) it depends on specific computer processor speed and (2) consums too much CPU time which is not very nice for other processes running on the same computer.

all those 16-bit functions are not supported by any 32-bit compiler. Its a whole new way of programming. If you are attempting to port a 16-bit program to windows console, you will probably wind up rewring all the screen i/o stuff and direct hardware reads/writes. You can't use inp() and outp() functions because they are not available. you have to go through the win32 device drivers.

Puts the script to sleep for sec seconds. The script will not do anything during this time.

> Fast timers fail on non i386 systems
> ------------------------------------
>
>                 Key: SNOW-108
>                 URL: http://jira.secondlife.com/browse/SNOW-108
>             Project: 6. Second Life Snowglobe - SNOW
>          Issue Type: Bug
>          Components: Source Code
>    Affects Versions: Snowglobe mysterious future
>         Environment: non i386 processors (with code compiled for that processor)
>            Reporter:  ************
>            Assignee: ************
>             Fix For: Snowglobe 1.1
>
>         Attachments: BrokenFastTimer.png, fix_fast_timers_amd64_less_intrusive.patch, fixfasttimers.diff, SNOW-108_Better_Fast_Timers_on_Unixoids.patch
>
>
> Fast timers do not us a universal method for getting accurate time
> linux and mac should use gettimeofday() no matter what processor
> Patch attached, fast timers work once again on amd64 (64 bit builds)

[Cerise1488303085]

Hi Knowl. The fast timer display is a developer tool for profiling. I don't think it is generally useful unless you have the viewer source in front of you, and are trying to hunt down a particular performance problem.  This page explains how to set them up in the code, but you would have to search a specific version's source for LLFastTimer() calls to see what is exactly being done in each of those states.

FTM_SLEEP in the SL viewer can spend time based on a few settings. YieldTime adds a sleep of that many milliseconds if it is not -1 and the viewer is in the foreground. BackgroundYieldTime is similar but used when the viewer is minimized. In the Debug/Develop menu there are also "Randomize Framerate" and "Periodic Slow Frame", these will act inside the FTM_SLEEP period too.

I probably added more confision than clarity there, but you can dig into your version's newview/llappviewer.cpp if you want to hunt for other sleep contributors that might affect you.

[Knowl Paine]

Thank you Cerise, this sleep function is a lot more complicated than I thought. :smileyhappy: