Extremely slow console/Graphics program [SOLVED]

[Trinity]

My console programs run *extremely slow" at the moment on my Windows (Win 7 , 64 bit).
It worked just fine earlier today.
Not at all sure if it is related but the only thing I have done is to try to put FXM's Nth time compiler switch (-exx option) into the FBIDE and try to run three times but got compile error every time because I could not find out how to use switch in IDE, then I deleted the switch from settings and then tried to quick compile/run program as before and then it suddenly runs very slow. An inkey example with some Dodicat help that used to "flash" more times per second now takes about *three* seconds to shift from cursor to no cursor - meaning 6 seconds for a whole flash. Please see code below for reference.
I have already tried to reboot more times and also restored Windows using a restore point and reinstalled FB on top of the old installation but nothing has helped. Tried compiling using WinFBE and tried also running the fully compiled program but same behavior. What can FreeBasic or IDE have changed in Windows to cause this behavior ? And how do I fix it ?

(The code below now takes six seconds to perform one full flash cycle !!!)

Code: Select all

#include "fbgfx.bi"
Using FB ' namespace

dim as integer W,H
screeninfo W,H 
W=W-100 : H = H-100
screenres W,H,,, GFX_NO_FRAME   
Width W\8, H\16
declare function Getflash() as integer
Dim As Integer foo

Do

    locate 8,20   :                                 foo=Getflash
    Locate (10,20,1) :     Print "total return: " & foo
   
      If( foo > 255 ) Then
        Locate (12,20,1) : Print "extended code: " & (foo And &hff)
        Locate (14,20,1) : Print "regular code: " & (foo Shr 8)
    Else
        Locate (12,20,1) : Print "regular code: " & (foo)
    End If
    Print
Loop Until foo = 27


function Getflash() as integer
      #define mk(a,b) a or b shl 8
    dim as string s,c,i
    static as long ctr
    dim as integer p=pos,cl=csrlin
    while len(inkey):wend
    do
        i=inkey
        ctr+=1
        locate cl,p
       if ctr mod 200=0 then c ="__"
       if ctr mod 400=0 then c= "  ":ctr=0
       print c
       if len(i) then cls: return mk(i[0],i[1])
        sleep 1,1
    loop
    end function  

----------------------------------------------------
Update :
For best solution to this problem please look at the code for the light version of my CallInkey function for key input with flashing cursor on graphics screen : viewtopic.php?f=7&t=26018&p=237707#p237707

[dodicat]

Hi Trinity.
use frac(timer) and 1
= frac(timer) mod 2
which will flash every 1 seconds
or
(timer) and 1
which will flash every 2 seconds.

Code: Select all

#include "fbgfx.bi"
Using FB ' namespace

dim as integer W,H
screeninfo W,H 
W=W-100 : H = H-100
screenres W,H,,, GFX_NO_FRAME   
Width W\8, H\16
declare function Getflash() as integer
Dim As Integer foo

Do

    locate 8,20   :                                 foo=Getflash
    Locate (10,20,1) :     Print "total return: " & foo
   
      If( foo > 255 ) Then
        Locate (12,20,1) : Print "extended code: " & (foo And &hff)
        Locate (14,20,1) : Print "regular code: " & (foo Shr 8)
    Else
        Locate (12,20,1) : Print "regular code: " & (foo)
    End If
    Print
Loop Until foo = 27


function Getflash() as integer
      #define mk(a,b) a or b shl 8
    dim as string s,c,i
    static as long ctr
    dim as integer p=pos,cl=csrlin
    while len(inkey):wend
    do
        i=inkey
        ctr+=1
        locate cl,p
        if frac(timer) and 1 then c="__" else c="  "
      
       print c
       if len(i) then cls: return mk(i[0],i[1])
        sleep 1,1
    loop
    end function  

[Trinity]

use frac(timer)

Thank you , but there seem to be a misunderstanding. Problem is that program suddenly runs far too slow which it did not do before (also stuff should not flash one time per seconds but more) .
Earlier today everything worked fine .
Problem is that it does not work as should all of a sudden.

(But you are right frac(timer) works where the loop suddenly do not)

[dodicat]

You might find that if you are online (Freebasic forum say) it will run fast.
If you go offline then it will run slow.

I think java running in the background (online) affects the cpu.

[Trinity]

You might find that if you are online (Freebasic forum say) it will run fast.
If you go offline then it will run slow.
I think java running in the background (online) affects the cpu.

Thank you for the tip , I will investigate , but I doubt that it has bearing on it as we are talking about a very small console application and I uses an Intel i7-6700 CPU on a board with Skylake chips set and 16 GB of RAM - so not some weak PC. Also I almost never program without having a browser running as I participate in forum in-between so nothing should have changed there.

Anyway , I tried closing browser and even to kill the AV but same result , the program suddenly runs very slow in the loop , I have to set loop times to less than a tenth of before + remove the "sleep 1,1" completely for it to work properly now. I simply do not understand this erratic behavior of the FB programs....
Also PC does anything else as fast as usual , it is just the FB console programs with Inkey loops that acts up ! (?)
(or I can just not register the slow down other places in FB programs - which is also entirely possible)

[grindstone]

I can confirm the flashing period of ~6s so it's most likely not a matter of your system.

It's generally not a good idea to do timing stuff by a counting loop. Use

Code: Select all

If Frac(Timer) > .5 Then
	c = "__"
Else
	c = "  "
EndIf

instead of

Code: Select all

If ctr Mod 200 = 0 Then c = "__"
If ctr Mod 400 = 0 Then c = "  ":ctr=0

so the flashing rate won't be affected by the CPU load or the optimization methods of the compiler.

[dodicat]

The code you posted was graphical, not console.
This box is Intel 3 g.Hz.
I get much faster fb graphics when online.
My last machine was the same
2 x 3 G.hz Pentium.
I had a little java pendulum program, which when I was offline I ran, and that gave me the speed.
That is why I made my little speed regulator.

Others on this forum have the same problem.
Only recently:
viewtopic.php?f=15&t=25353&p=230680&hil ... 2A#p230680
leopardpm, about six posts from the top.

By the way you should always include a sleep in a graphics loop.
sleep 1,1 is OK

[Trinity]

It's generally not a good idea to do timing stuff by a counting loop. Use

Code: Select all

If Frac(Timer) 
<Snip>
so the flashing rate won't be affected by the CPU load or the optimization methods of the compiler.[/quote]
Thank you for the info.   
While I do not consider that a proper solution to a very erratic behavior or extreme slow down of FB programs then I will see if I , as a temporary mending , can implement a similar solution in my programs which are different in some ways...

[Trinity]

The code you posted was graphical, not console. Others on this forum have the same problem. Only recently:

Thank you for the tips .

By the way you should always include a sleep in a graphics loop.sleep 1,1 is OK

Yes , I noticed the other day, if I did not include sleep 1,1 then I had to set loop numbers a factor 1000 or 10000 up to get flash time OK . But I understand the concept of load so I put in the sleep 1,1 . instead .

[dodicat]

Here is my regulator.
Set your framerate at line 14 (MySpeed)

Code: Select all

Function Regulate(Byval MyFps As long,Byref fps As long) As long
    Static As Double timervalue,_lastsleeptime,t3,frames
    frames+=1
    If (Timer-t3)>=1 Then t3=Timer:fps=frames:frames=0
    Var sleeptime=_lastsleeptime+((1/myfps)-Timer+timervalue)*1000
    If sleeptime<1 Then sleeptime=1
    _lastsleeptime=sleeptime
    timervalue=Timer
    Return sleeptime
End Function

dim as long MySpeed=40 '< ---------------- Here 

screen 18
dim as long fps,x=10,y=10,dx=1,dy=1
do
    x+=dx
    y+=dy
    if x<10 or x>630 then dx=-dx
    if y<10 or y>470 then dy=-dy
    screenlock
    cls
    print "FrameRate ";fps
    circle(x,y),10
    screenunlock
    sleep regulate(MySpeed,fps) '<------------ Used here
    loop until len(inkey)
    

     

[Trinity]

Here is my regulator.

Thank you very much Dodicat for both your kindness and your code sharing/suggestions :-)
It looks as if it require some studying , plus I also need to look at how I want to proceed, and also I am simply so tired now and need to rest , So it will have to wait for now.
I have been thinking about the problem and it's rather difficult because of so many features on modern PCs where both CPUs and GPUs can change speed. But it looks to me as maybe FB relies on some internal clock frequency or something for execution of the graphics programs or something else. But only the brains that made FB has knowledge of that. And maybe that is what is the matter , I don't know , simply guessing....

[dodicat]

Ok Trinity.
I am off also.

In my regulate snippet.
set the speed to say 150.
Test while on this forum page.
Do you get 150 framerate?

now click off your browser and test again.

Do you still get 150 framerate?

[deltarho[1859]]

Browsers used to have a bad habit of changing the timer interval, usually at 15.625ms (64Hz), to 1ms (1000Hz) for various jobs and forgot to restore to the default. Laptop batteries used to drain much quicker and the computing press made a ruckus about it. Things have changed and browsers are much better behaved.

If you want to see if a graphics program is affected by the timer interval go to YouTube - that sets the timer interval to 1ms as soon as we walk in the door.

I have two applications, one for Win10 and one for older versions of Windows, which can change the timer interval on the fly and reports on the current resolution. Win10 uses a continuous function and older versions of Windows uses a discrete function. There is no mention of the Win10 behaviour at Microsoft. I came across it by accident and wrote an app to leverage it.

I ran the non Win10 version whilst the opening post code was running and am getting about 12 flashes per 10 seconds. Without my interference I am getting about one flash per three seconds.

I won't give links to my apps just yet - try YouTube first.

Added

Dodicat's code in the link above regarding leopardpm is filling frames at about 6 to 7 seconds. With my app running at the same time the frames are taking less than one second to fill.

But it looks to me as maybe FB relies on some internal clock frequency or something for execution of the graphics programs

I would not be surprised.

[deltarho[1859]]

Blimey, in Windows a lot of you guys are using something like 'Sleep 1,1' in loops and are expecting a 1ms Sleep. Sleep is governed by the System clock which defaults to a resolution of 15.625ms.

See this post back in March 2017.

Later on fxm mentioned that

Code: Select all

#include "windows.bi"
#include "win/mmsystem.bi"

should be included at the top of the program.

I wrote "If we forget to employ StopHiResSleep, Windows will do it for us at the end of the application session." Best practice is to employ StartHiResSleep just before needed and employ StopHiResSleep just after it is needed. In practice, I never use StopHiresSleep because it would be employed just before the code finishes.

In a nutshell, For Trinty's opening post code then:

Add

Code: Select all

#include "windows.bi"
#include "win/mmsystem.bi"

at top of code.

Add somewhere at the top of code:

Code: Select all

#Macro StartHiResSleep
  Scope
    Dim As TIMECAPS tc
    TimeGetDevCaps( @tc, SizeOf(tc) )
    TimeBeginPeriod(tc.wPeriodMin)
  End Scope
  Sleep (16,1) ' Tests have shown that the new resolution will not 'bite' until next 'old' tick
#EndMacro
 
StartHiResSleep

Use the above method for any graphics program which uses 'Sleep 1' in a loop.

[Trinity]

If you want to see if a graphics program is affected by the timer interval go to YouTube - that sets the timer interval to 1ms as soon as we walk in the door.

Thanks for the tip - but didn't work

Browsers used to have a bad habit of changing the timer interval, usually at 15.625ms (64Hz), to 1ms (1000Hz) for various jobs and forgot to restore to the default.

Apparently it's the other way around at my PC stuff at the moment, the timer loop works best (OK compared to when first programmed) at 1.000 and the number were 15.600 when problem were experienced.
I have no idea what's correct and I will have to carry my code to other PCs and experiment with it there to determine what seem right in my end and to establish some frame of reference , unfortunately my present setup (*very poor* dwelling, poor living arrangement , being relatively poor and what not) is far from ideal so it will be hard for me to setup my other computers (older stuff)

I have two applications, one for Win10 and one for older versions of Windows, which can change the timer interval on the fly and reports on the current resolution. Win10 uses a continuous function and older versions of Windows uses a discrete function. There is no mention of the Win10 behaviour at Microsoft. I came across it by accident and wrote an app to leverage it.

Nice :-)

I won't give links to my apps just yet - try YouTube first.

Luckily you don't have to - that's the beauty of the internet for you :-)

timer interval, usually at 15.625ms (64Hz)

Now we are getting somewhere. ;-)
As I expressed yesterday , then it looked to me as "FB relies on some internal clock frequency or something for execution of the graphics programs". And with your snippet of information we got a little closer. My problem was indeed connected with that timer thing.
I first got the Sysinternals "ClockRes" gizmo and :
Seeing the current timer frequency is easy – just run the clockres tool by sysinternals :
https://docs.microsoft.com/en-us/sysint ... s/clockres
From there I explored more and found the :
(To explore more get) the Windows Timestamp Project! : http://www.windowstimestamp.com
Download : http://www.windowstimestamp.com/download
And read the G_HowTo : http://www.windowstimestamp.com/G_HowTo_0260.pdf
Warning , free license for program per email is rather short and run out in less than three months
(as it says in the email with license then the license can be prolonged upon request.)

So I ran the Windows Timestamp Project! G_Kernel which set the timer to 1.000 ms

Problem solved - at least for a little time :

I here give the Windows Timestamp Project! log from my PC to the developer brainiacs of FB for their meditation (someone please notify the brainiacs) (and please use Google translate to define word brainiac if need be) :

Code: Select all

2017-10-10 11:38:20.719000.0 (ftime)[006696.009352.003.08]: 
                                                            
                                                            Welcome to G_Kernel (x64) Version 2.60 (Feb 15 2017) [Mode: GUI], 
                                                            (c) (2012-2016) windowstimestamp.com
                                                            
2017-10-10 11:38:20.719000.0 (ftime)[006696.009352.003.08]: Kernel: Cannot open license file G_LicenseKey.glk, setting max. process runtime limited to 1800 seconds.
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Microsoft Windows 7 Ultimate N , Version 6.1.1.0, Service Pack 1 (build 7601), GUID: <REMOVED>
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: ProcessorArchitecture: x64 (AMD or Intel), ProcessorType: 8664
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Operating on a native CPU.
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Processor system consists of 1 NUMA node(s) with 1 physical processor package(s) and 4 processor core(s)
                                                            8 logical processor(s) share 8MB L1, 4MB L2, and 1MB L3 cache(s)
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Kernel: ProcessorMask for NUMA Node  0:  0xFF
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Kernel: System Process Affinity Mask:    0xFF
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: VERSION INFORMATION: G_Kernel.cpp, compiled: Feb 15 2017 17:23:39
                                                            (source last modified:  Wed Feb 15 15:36:51 2017), MSC version 1900
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Library Version 2.60 (x64)
                                                            VERSION INFORMATION: G_Lib.cpp, compiled: Feb 15 2017 17:23:37
                                                            (source last modified:  Tue Feb 14 13:11:14 2017), MSC version 1900
2017-10-10 11:38:20.797000.0 (ftime)[006696.009352.003.24]: Kernel: Starting process C:\MyDirectory\Windows Time\windowstimestamp_0260\x64\G_IO_Service.exe...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting KernelServiceInstanceGenerator...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting TimeService on logical processor 7 ...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting ClientWatchdog...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting NTP_ServiceMaster...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting BatchTimer...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Establishing kernel parameter...
2017-10-10 11:38:20.812000.0 (ftime)[006696.004876.007.24]: KernelServiceInstance: Kernel instance.
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting qfprintfQueueServer...
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.24]: Kernel: Starting C:\MyDirectory\Windows Time\windowstimestamp_0260\x64\G_GUI.exe...
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: Kernel is up, starting time services...
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: CPU supports invariant TSC.
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: CPU supports serialized TSC calls (RDTSCP).
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: Performance counter frequency: 3328349 ticks/s.
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: Current timer resolution: 15.60000 ms
2017-10-10 11:38:20.812000.0 (ftime)[006696.008412.007.31]: TimeService: Link to TimerRequestSemaphore established.
2017-10-10 11:38:20.812000.0 (ftime)[006696.009352.003.16]: Kernel: Entering handler loop ...
2017-10-10 11:38:20.812000.0 (ftime)[008476.009128.000.08]: G_IO_Service (x64) Version 2.60 started.
2017-10-10 11:38:20.812000.0 (ftime)[008476.009128.000.08]: VERSION INFORMATION: G_IO_Service.cpp, compiled: Feb 15 2017 17:23:39
                                                            (source last modified:  Tue Oct 25 14:22:05 2016)
2017-10-10 11:38:20.812000.0 (ftime)[008476.009128.000.08]: G_IO_Service: Starting OutputserverPipeService...
2017-10-10 11:38:20.812000.0 (ftime)[008476.009128.000.08]: G_IO_Service: Starting GUIServiceInstanceGenerator...
2017-10-10 11:38:20.878000.0 (ftime)[008092.006064.005.08]: G_GUI V2.60 (x64) © 2012-2017 windowstimestamp.com (privileged)
2017-10-10 11:38:20.914000.0 (ftime)[006696.001324.000.16]: qfprintfQueueServer: Kernel mode: IO-Pipe (604) successfully opened
2017-10-10 11:38:20.914000.0 (ftime)[008476.009128.000.08]: G_IO_Service: Starting ConsoleOutputServer...
2017-10-10 11:38:20.927000.0 (ftime)[008476.009248.006.08]: ConsoleOutputServer: Console services on host US-PC
2017-10-10 11:38:20.927000.0 (ftime)[008476.009248.006.08]: ConsoleOutputServer: Opened logfile: 
                                                            C:\MyDirectory\Windows Time\windowstimestamp_0260\x64\LOG\G_on_US-PC_W6110_2017-10-10_11_38_20.log
2017-10-10 11:38:20.927000.0 (ftime)[008476.009248.006.08]: ConsoleOutputServer: Log path C:\MyDirectory\Windows Time\windowstimestamp_0260\x64\LOG created
2017-10-10 11:38:21.196000.0 (ftime)[006696.008412.007.31]: TimeService: The platform supports the following timer resolutions:
                                                            -   0.5000 ms.
                                                            -   1.0000 ms.
                                                            -   1.2500 ms.
                                                            -   2.5000 ms.
                                                            -   5.0000 ms.
                                                            -  10.0000 ms.
                                                            -  15.6000 ms.
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: File time synchronized (transition period:  1.0000 ms)
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: TimeAdjustmentDisabled: 1
                                                                         TimeAdjustment: 156001
                                                                         TimeIncrement:  156001
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: File mapping object Global\G_file_mapping created
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: Map view established.
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: License state updated.
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: Waitable timer "G_waitable_timer" created.
2017-10-10 11:38:21.244000.0 (ftime)[006696.008412.007.31]: TimeService: TSC Frequency: 3411681267.1 Hz (1025.04 times the performance counter frequency).
2017-10-10 11:38:21.349000.0 (ftime)[006696.008412.007.31]: TimeService: Minimum multimedia timer resolution:  15.60010 ms
                                                                         Maximum multimedia timer resolution:   0.50000 ms
                                                                         Current multimedia timer resolution:   1.00000 ms
                                                                         Estimated Sleep(1) delay: 1.000 ms
2017-10-10 11:38:21.474000.0 (ftime)[006696.008412.007.31]: Collect_FFT: The filetime increment of 10000 was constant during the collection warmup phase.
2017-10-10 11:38:21.474000.0 (ftime)[006696.008412.007.31]: Collect_FFT: Monitoring 2400 filetime transitions for approx. 2.40 seconds, the current timer
                                                            resolution is 1.0000 ms...
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.31]: Collect_FFT: Collected 2400 filetime transitions
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: Analyze_FFT: Analyzing 2400 filetime transitions at resolution 1.0000 ms...
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: Analyze_FFT: Mean elapsed filetime: 10000.000000, mean elapsed ticks: 3328.071250,
                                                            MinElapsedTicks: 445 (0.133700 ms), MaxElapsedTicks: 6297 (1.891929 ms)
                                                            MinElapsedFileTime: 10000, MaxElapsedFileTime: 10000, mean delay: 0.9999166 ms
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: Analyze_FFT: Filetime increment is fixed: 10000 100 ns units
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: Analyze_FFT: Evaluating filetime transition delay hiccups (A hiccup is considered when the
                                                            filetime transition delay deviates more than 0.90130 ms from the mean delay. 
                                                            This corresponds to 0.90 interrupt periods [1.00145 ms].
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: Analyze_FFT: No hiccup periods found
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: BestTimerPeriod: Initial parameter for best timer period estimation: 
                                                            RollOver:                    0 ms
                                                            HiccupPeriod:                1 filetime increment(s)
                                                            HiccupCount:                 0
                                                            PatternPeriod:               1 filetime increment(s)
                                                            PatternCount:                0
                                                            MeanElapsedFileTime:         1.0000 ms
                                                            PatternMeanElapsedFileTime:  0.0000 ms
                                                            MeanElapsedTime:             0.9999 ms
                                                            Estimated Sleep1Delay:       1.001 ms
                                                            Min. period:                 1000.00 ms
                                                            Max. period:                 60000.00 ms
                                                            Current timer resolution:    1.0000 ms
2017-10-10 11:38:23.874000.0 (ftime)[006696.008412.007.08]: BestTimerPeriod: BestTime derived from update pattern: 1000.0000 ms (1000 x 1 x 1.000000 ms).
2017-10-10 11:38:24.654000.0 (ftime)[006696.008412.007.31]: TimeService: Current resolution: 1.0000 ms, current thread quantum approx. 32.6 ms.
2017-10-10 11:38:24.655000.0 (ftime)[006696.008412.007.31]: TimeService: Scheduled 1st service event at ~ 11:38:25.6556736 (period: 1000 ms, precise: 1000.0000 ms)
                                                            Awaiting initial calibration (approx. 13.0 s) ...
2017-10-10 11:38:39.655000.0 (ftime)[006696.008412.007.22]: TimeService: Calibration active.
2017-10-10 11:48:08.491313.8 (01.29)[008092.006064.005.08]: Status Summary:
                                                            
2017-10-10 11:48:08.491337.5 (01.29)[008092.006064.005.08]:  - G_Kernel.exe, version: 2.60 (x64), build Feb 15 2017
2017-10-10 11:48:08.491347.7 (01.29)[008092.006064.005.08]:  - G_Lib.lib, version 2.60 (x64), build Feb 15 2017
2017-10-10 11:48:08.491356.7 (01.29)[008092.006064.005.08]:  - Startup mode: GUI - flags: log=ON, csv=OFF, csv=OFF, csv=OFF, 
2017-10-10 11:48:08.491388.9 (01.29)[008092.006064.005.08]:  - Windows 7, Version 6.1.1.0, Service Pack 1 (build 7601), Architecture: x64 (AMD or Intel) (8664)
                                                                 1 NUMA node(s) with 1 physical processor package(s) and 4 processor core(s)
                                                                 8 logical processor(s) share 8MB L1, 4MB L2, and 1MB L3 cache(s)
                                                                 Current Timer Resolution: 1.0000 ms
                                                                 FileTime granularity: 1.0000 ms
                                                                 Thread quantum approx. 32.6 ms
                                                                 Invariant TSC: Supported
2017-10-10 11:48:08.491406.0 (01.29)[008092.006064.005.08]:  - License information:
                                                                 Process runtime limited to 1800 seconds
                                                                 License expiry:  N/A
                                                                 License state:   Active
2017-10-10 11:48:08.491412.9 (01.29)[008092.006064.005.08]:  - NTP details:
2017-10-10 11:48:08.491421.3 (01.29)[008092.006064.005.08]:      No NTP server configured.
2017-10-10 11:48:08.491437.3 (01.29)[008092.006064.005.08]:      Windows socket DLL: Off, 
                                                                 Configured update period: 2500 ms
                                                                 Current mode: NTP OFF
                                                                 Current status: NTP INACTIVE (locked=0)
2017-10-10 11:48:08.491448.4 (01.29)[008092.006064.005.08]:  - List of 2 clients:
                                                                 G_GUI.exe (privileged)
                                                                 G_IO_Service.exe (privileged)
                                                            
2017-10-10 11:48:08.491470.9 (01.29)[008092.006064.005.08]: End of Summary.