AnsweredAssumed Answered

vrf AW: CPU Usage (was: Vee program sources)

Question asked by bernhardt on Dec 3, 2003

Like • Show 0 Likes0
Comment • 4

Hi,

in an older project we used a DLL containing the function SetPriorityClass.
This DLL works fine with NT. It was no problem to set VEE to "Realtime"
before the measurement starts and set it back to "Normal" after the
measurement. But don't forget to set it back.

Best regards
M. Bernhardt

-----Ursprngliche Nachricht-----
Von:      Shawn Fessenden [mailto:shawn@testech-ltd.com]
Gesendet:     Mittwoch, 3. Dezember 2003 10:32
An:     VRF
Betreff:     [vrf] AW: RE: CPU Usage (was: Vee program sources)

> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.

Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:

int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);

REALTIME_PRIORITY_CLASS     = 0x00000100
HIGH_PRIORITY_CLASS         = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS       = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS         = 0x00000040

In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).

int __stdcall SetThreadPriority(int hThread, int iPriority);

THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST       = 2
THREAD_PRIORITY_ABOVE_NORMAL = 1
THREAD_PRIORITY_NORMAL        = 0
THREAD_PRIORITY_BELOW_NORMAL = -1
THREAD_PRIORITY_LOWEST        = -2
THREAD_PRIORITY_IDLE          = -15

In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).

Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-

---
You are currently subscribed to vrf as: Bernhardt@somatec.de
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

No one else has this question

Outcomes

VRFuser Dec 1, 2003 10:17 PM

-SNIP-
Not really- just set up the computer as the gateway. IO libraries
makes this very simple - no special code at all.

Stan
-snip-

Not Quite. When I was testing remote gateways using HP and NI GPIB cards,
only the HP/Agilent Cards supported the remote LAN feature, I go no response
from the NI Card. Could have been a function of the IO Libs(Rev G/H) at
that time. I have not revisited this since then. Otherwise, this is a
great way to share a GPIB network interface.

Mike
***********************************************************
Michael N. Asbery                (202)404-3014, DSN 754
US Naval Research Laboratory      fax (202)404-7661
Code 5733.20                    michael.asbery@nrl.navy.mil
4555 Overlook Ave SW
Washington DC 20375                                     :-)

***********************************************************

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Actions

VRFuser Dec 2, 2003 1:16 AM

Hello Georg,

no need to add more salt to my injuries! ;-)

Due to a management decision, I'm bound to w2k for applications requiring 1ms and less sytem time. No way to use any reasonable OS, so most of the applications is hard-wired. Can't argue with facts against that, so I'm leaving the company soon.
/*end of moaning*/

The 'Delay' was added only for visualisation purposes & as far as I can see, it does eat milliseconds very well, while the Kernel.sleep(A*1000) behaves like a microsecond sleep timer(?).

With w2k, the system performance using any 1GHz+ CPU is almost sufficient to meet most of the needs to come close to 1ms system time, but any interaction with the desktop or sockets will bog off the response times. Bad luck to Gonzalo and me?

When using LabVIEW, you can set directly two variables called 'execution system' and 'priority', who seem both linked to the OS. Changing the execution system for a vi shows almost the same behaviour like the Kernel.sleep, so they may do some active/passive internal/external thread switching. The Priority, as far as I can guess, is a os-variable to characterise thread-behaviour itself but will be ignored when any process is not willing to release.

Stupid physicist I am, thought - better: hoped - that there might be a way to cheat any thread-handle or whatever is inside the f*... OS to disable the graphical engine for a short period of time or to claim full system resources for VEE while executing a well-defined piece of code.

The introduced sleep-call releases only the actual running thread, but does not affect any internal thread handle - so it will not generate additional overhead to the os, right?
But I saw some kind of a 10ms discrete time base which seems to be generated by VEE when sweeping through using both 'Kernel.sleep' or 'Delay'. This is different in LabVIEW, using a simmilar application with a 1ms-step Timer sweep is almost continuos in the response.

Anyway, both VEE and LabVIEW loose between 100ms to 300ms+ on a simple window minimise/maximise command which is from my point of view far away to be acceptable, even for a non-realtime os in these days.

Best Regards,
Stefan

P.S: 'kudos' translates to 'Ruhm' or 'Ehre' & I'll promise never again to use 'Delay' :-)

))

-----Ursprngliche Nachricht-----
Von: g.nied@gn-software.de [mailto:g.nied@gn-software.de]
Gesendet: Dienstag, 2. Dezember 2003 15:01
An: VRF
Betreff: [vrf] RE: CPU Usage (was: Vee program sources)

Stefan,

No, No, I'm shaking my head ..

Three things:

1) 'Delay' object is 'Bah' (I mean: obsolete :-)

) now
   use the sleep function instead (but remember that 'delay'
   has seconds as input parameter whereas 'sleep' uses milliseconds.
   I changed your prog accordingly.

2) It makes no sense to decrease the sleep time too much. Less than 10 ms
   is rarely useful because of the overhead.

3) Windows - even NT - is no realtime OS. There is and will be no chance.

Georg

-------- Original Message --------
Subject: [vrf] AW: RE: CPU Usage (was: Vee program sources) (02-Dez-2003 14:17)
From:    Stefan.Paulick.extern@brose.net
To:      vrf@agilent.com

> Hello Aglient,
>
> would be more than useful to find such kind of informations provided
> either
> in the Advanced Programming Techniques Manual or on any official VEE
> webpage.
>
> ... and one more, to ... Georg ;-)

)):
>
> is there a simmilar way to decouple the execution of a VEE program
> from the
> window management to achieve an almost equidistant execution time? Any
> change at the desktop will suspend VEE execution for some 100 milliseconds
> or even seconds (please see attached code)
>
>
> Best Regards,
> Stefan
>
>
> -----Ursprngliche Nachricht-----
> Von: kirk_reed@agilent.com [mailto:kirk_reed@agilent.com]
> Gesendet: Dienstag, 2. Dezember 2003 13:06
> An: VRF
> Betreff: [vrf] RE: CPU Usage (was: Vee program sources)
>
>
> Georg,
>
> This is exactly what I was asking for. I did not realize how dramatic
> of
> an improvement it would be. I went from 100% cpu time to 0%, and the your
> vee program was still running.
>
> Kudos to you!
>
> Where do you think this is best used? Should it be used sparingly and
> only
> when there are cpu hogging threads?
>
> Kirk
>
> -----Original Message-----
> From: g.nied@gn-software.de [mailto:g.nied@gn-software.de]
> Sent: Tuesday, December 02, 2003 6:47 AM
> To: PDL-LISTS,VRF (A-Lists,unix1)
> Subject: [vrf] CPU Usage (was: Vee program sources)
>
> Although Shawn was addressed here I will put in my answer 'cause I
> think It
> might take a while till Shawn will be awake :-)

>
>
> As Kirk said you must call a windows API call to release the lock on
> the
> cpu while in a loop. It is
> long __stdcall Sleep (long dwMilliseconds) from Kernel32.dll
>
> This function does NOT put the CPU to sleep :-)

but only the current
> thread. But in contrast to the VEE 'Delay' object it gives back
> control over the cpu to windows and therefore your cpu is 'free'
> again. This is also called yielding (if I remember correctly). So, if
> you are in a loop that eats up your cpu performance just insert a call
> to sleep (it might be a very, very short pause, maybe only 10 ms) and
> you're fine.
>
> I give you an example that checks the contents of a global variable
> and
> lists it if it was changed. This is my typical case to insert the sleep-
> command. Look at the formula box named 'sleep'. The call is disabled if the
> double backslash is in front of the call. In this case, running the program
> leads to a high cpu usage. If you now remove the "\" and start it again
> you have no such problems any more.
>
>
> best regards,
>
> G. Nied
>
> ----------------------------------------------------------------------
> --
> -
> Georg Nied - Software-Development - Hansestr.7 - 51149 Cologne - Germany
> Tel: +49 2203 9770915 - Fax: +49 2203 9770924 - eMail:info@gn-software.de
> ------------------------------------------------------------------------
> -
>
>
> ---
> You are currently subscribed to vrf as:
> Stefan.Paulick.extern@brose.net To
> subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email "vrf@agilent.com".
> If you need help with the mailing list send a message to "owner-vrf@it.
> lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Actions

VRFuser Dec 2, 2003 11:32 AM

> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.

Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:

int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);

REALTIME_PRIORITY_CLASS     = 0x00000100
HIGH_PRIORITY_CLASS         = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS       = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS         = 0x00000040

In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).

int __stdcall SetThreadPriority(int hThread, int iPriority);

THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST       = 2
THREAD_PRIORITY_ABOVE_NORMAL = 1
THREAD_PRIORITY_NORMAL        = 0
THREAD_PRIORITY_BELOW_NORMAL = -1
THREAD_PRIORITY_LOWEST        = -2
THREAD_PRIORITY_IDLE          = -15

In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).

Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Actions

VRFuser Dec 2, 2003 11:15 PM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><META content="MSHTML 6.00.2800.1276" name=GENERATOR><STYLE></STYLE></HEAD><BODY bgColor=#ffffff><DIV><FONT face=Arial size=2>Hi all,</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>How do I represent an integer in the range of 0 to 4294967295 (2^32 - 1)?</FONT></DIV><DIV><FONT face=Arial size=2>I'm calculating IP numbers from dotted IP address. The formula to convert an IP Address of the form A.B.C.D to an IP Number is:</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>IP Number = A x 16777216 + B x 65536 + C x 256 + D<BR>When I use a formula box, it returns error 514 (overflow). How can I indicate to give the result in UInt32 or Real?</FONT></DIV><DIV><FONT face=Arial size=2> </DIV></FONT><DIV><FONT face=Arial size=2>Thanks and regards,</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>Nelson Mambre <BR>Ingeniero de Desarrollo<BR>Seebeck C.A.<BR>Caracas, Venezuela<BR>Tel. +58-212-906-4276<BR>Fax +58-212-962-0871<BR><A href="http://www.seebeck.com.ve">www.seebeck.com.ve</A></FONT></DIV></BODY>---<BR>You are currently subscribed to vrf as: rsb@soco.agilent.com<BR>To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".<BR>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".<BR>To send messages to this mailing list, email "vrf@agilent.com". <BR>If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".</html>

Actions

4 Replies

VRFuser Dec 1, 2003 10:17 PM
Mark Correct
Correct Answer
-SNIP-
Not really- just set up the computer as the gateway. IO libraries
makes this very simple - no special code at all.

Stan
-snip-

Not Quite. When I was testing remote gateways using HP and NI GPIB cards,
only the HP/Agilent Cards supported the remote LAN feature, I go no response
from the NI Card. Could have been a function of the IO Libs(Rev G/H) at
that time. I have not revisited this since then. Otherwise, this is a
great way to share a GPIB network interface.

Mike
***********************************************************
Michael N. Asbery                (202)404-3014, DSN 754
US Naval Research Laboratory      fax (202)404-7661
Code 5733.20                    michael.asbery@nrl.navy.mil
4555 Overlook Ave SW
Washington DC 20375
***********************************************************

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Dec 2, 2003 1:16 AM
Mark Correct
Correct Answer
Hello Georg,

no need to add more salt to my injuries! Due to a management decision, I'm bound to w2k for applications requiring 1ms and less sytem time. No way to use any reasonable OS, so most of the applications is hard-wired. Can't argue with facts against that, so I'm leaving the company soon.
/*end of moaning*/

The 'Delay' was added only for visualisation purposes & as far as I can see, it does eat milliseconds very well, while the Kernel.sleep(A*1000) behaves like a microsecond sleep timer(?).

With w2k, the system performance using any 1GHz+ CPU is almost sufficient to meet most of the needs to come close to 1ms system time, but any interaction with the desktop or sockets will bog off the response times. Bad luck to Gonzalo and me?

When using LabVIEW, you can set directly two variables called 'execution system' and 'priority', who seem both linked to the OS. Changing the execution system for a vi shows almost the same behaviour like the Kernel.sleep, so they may do some active/passive internal/external thread switching. The Priority, as far as I can guess, is a os-variable to characterise thread-behaviour itself but will be ignored when any process is not willing to release.

Stupid physicist I am, thought - better: hoped - that there might be a way to cheat any thread-handle or whatever is inside the f*... OS to disable the graphical engine for a short period of time or to claim full system resources for VEE while executing a well-defined piece of code.

The introduced sleep-call releases only the actual running thread, but does not affect any internal thread handle - so it will not generate additional overhead to the os, right?
But I saw some kind of a 10ms discrete time base which seems to be generated by VEE when sweeping through using both 'Kernel.sleep' or 'Delay'. This is different in LabVIEW, using a simmilar application with a 1ms-step Timer sweep is almost continuos in the response.

Anyway, both VEE and LabVIEW loose between 100ms to 300ms+ on a simple window minimise/maximise command which is from my point of view far away to be acceptable, even for a non-realtime os in these days.

Best Regards,
Stefan

P.S: 'kudos' translates to 'Ruhm' or 'Ehre' & I'll promise never again to use 'Delay' ))

-----Ursprngliche Nachricht-----
Von: g.nied@gn-software.de [mailto:g.nied@gn-software.de]
Gesendet: Dienstag, 2. Dezember 2003 15:01
An: VRF
Betreff: [vrf] RE: CPU Usage (was: Vee program sources)

Stefan,

No, No, I'm shaking my head ..

Three things:

1) 'Delay' object is 'Bah' (I mean: obsolete ) now
   use the sleep function instead (but remember that 'delay'
   has seconds as input parameter whereas 'sleep' uses milliseconds.
   I changed your prog accordingly.

2) It makes no sense to decrease the sleep time too much. Less than 10 ms
   is rarely useful because of the overhead.

3) Windows - even NT - is no realtime OS. There is and will be no chance.

Georg

-------- Original Message --------
Subject: [vrf] AW: RE: CPU Usage (was: Vee program sources) (02-Dez-2003 14:17)
From:    Stefan.Paulick.extern@brose.net
To:      vrf@agilent.com

> Hello Aglient,
>
> would be more than useful to find such kind of informations provided
> either
> in the Advanced Programming Techniques Manual or on any official VEE
> webpage.
>
> ... and one more, to ... Georg )):
>
> is there a simmilar way to decouple the execution of a VEE program
> from the
> window management to achieve an almost equidistant execution time? Any
> change at the desktop will suspend VEE execution for some 100 milliseconds
> or even seconds (please see attached code)
>
>
> Best Regards,
> Stefan
>
>
> -----Ursprngliche Nachricht-----
> Von: kirk_reed@agilent.com [mailto:kirk_reed@agilent.com]
> Gesendet: Dienstag, 2. Dezember 2003 13:06
> An: VRF
> Betreff: [vrf] RE: CPU Usage (was: Vee program sources)
>
>
> Georg,
>
> This is exactly what I was asking for. I did not realize how dramatic
> of
> an improvement it would be. I went from 100% cpu time to 0%, and the your
> vee program was still running.
>
> Kudos to you!
>
> Where do you think this is best used? Should it be used sparingly and
> only
> when there are cpu hogging threads?
>
> Kirk
>
> -----Original Message-----
> From: g.nied@gn-software.de [mailto:g.nied@gn-software.de]
> Sent: Tuesday, December 02, 2003 6:47 AM
> To: PDL-LISTS,VRF (A-Lists,unix1)
> Subject: [vrf] CPU Usage (was: Vee program sources)
>
> Although Shawn was addressed here I will put in my answer 'cause I
> think It
> might take a while till Shawn will be awake
>
>
> As Kirk said you must call a windows API call to release the lock on
> the
> cpu while in a loop. It is
>          long __stdcall Sleep (long dwMilliseconds) from Kernel32.dll
>
> This function does NOT put the CPU to sleep but only the current
> thread. But in contrast to the VEE 'Delay' object it gives back
> control over the cpu to windows and therefore your cpu is 'free'
> again. This is also called yielding (if I remember correctly). So, if
> you are in a loop that eats up your cpu performance just insert a call
> to sleep (it might be a very, very short pause, maybe only 10 ms) and
> you're fine.
>
> I give you an example that checks the contents of a global variable
> and
> lists it if it was changed. This is my typical case to insert the sleep-
> command. Look at the formula box named 'sleep'. The call is disabled if the
> double backslash is in front of the call. In this case, running the program
> leads to a high cpu usage. If you now remove the "\" and start it again
> you have no such problems any more.
>
>
> best regards,
>
> G. Nied
>
> ----------------------------------------------------------------------
> --
> -
> Georg Nied - Software-Development - Hansestr.7 - 51149 Cologne - Germany
> Tel: +49 2203 9770915 - Fax: +49 2203 9770924 - eMail:info@gn-software.de
> ------------------------------------------------------------------------
> -
>
>
> ---
> You are currently subscribed to vrf as:
> Stefan.Paulick.extern@brose.net To
> subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email "vrf@agilent.com".
> If you need help with the mailing list send a message to "owner-vrf@it.
> lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Dec 2, 2003 11:32 AM
Mark Correct
Correct Answer
> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.

Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:

int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);

REALTIME_PRIORITY_CLASS     = 0x00000100
HIGH_PRIORITY_CLASS         = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS       = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS         = 0x00000040

In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).

int __stdcall SetThreadPriority(int hThread, int iPriority);

THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST       = 2
THREAD_PRIORITY_ABOVE_NORMAL = 1
THREAD_PRIORITY_NORMAL        = 0
THREAD_PRIORITY_BELOW_NORMAL = -1
THREAD_PRIORITY_LOWEST        = -2
THREAD_PRIORITY_IDLE          = -15

In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).

Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Dec 2, 2003 11:15 PM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><META content="MSHTML 6.00.2800.1276" name=GENERATOR><STYLE></STYLE></HEAD><BODY bgColor=#ffffff><DIV><FONT face=Arial size=2>Hi all,</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>How do I represent an integer in the range of 0 to 4294967295 (2^32 - 1)?</FONT></DIV><DIV><FONT face=Arial size=2>I'm calculating IP numbers from dotted IP address. The formula to convert an IP Address of the form A.B.C.D to an IP Number is:</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>IP Number = A x 16777216 + B x 65536 + C x 256 + D<BR>When I use a formula box, it returns error 514 (overflow). How can I indicate to give the result in UInt32 or Real?</FONT></DIV><DIV><FONT face=Arial size=2> </DIV></FONT><DIV><FONT face=Arial size=2>Thanks and regards,</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>Nelson Mambre <BR>Ingeniero de Desarrollo<BR>Seebeck C.A.<BR>Caracas, Venezuela<BR>Tel. +58-212-906-4276<BR>Fax +58-212-962-0871<BR><A href="http://www.seebeck.com.ve">www.seebeck.com.ve</A></FONT></DIV></BODY>---<BR>You are currently subscribed to vrf as: rsb@soco.agilent.com<BR>To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".<BR>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".<BR>To send messages to this mailing list, email "vrf@agilent.com". <BR>If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".</html>
Like • Show 0 Likes0
Actions

vrf AW: CPU Usage (was: Vee program sources)

Outcomes

Related Content

Recommended Content