On Wednesday, March 13, 2013 at 1:06 PM, Cory Smelosky wrote:
"Solaris timing uses a real-time clock that can generate interrupts
at a resolution bound by the processor speed. For scheduling
purposes, it fires every 10 milliseconds. As in Linux, this is a
clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as
opposed to the 100-tick/second clock used by Solaris and by previous
versions of Linux. User-level programs on Solaris can program the real
time clock to fire at nanosecond granularity, rounded up by processor time--
much finer than the clock tick granularity of ten or one milliseconds.
However, the program interface to use the high-resolution timers is
not visible in the DDI/DKI. See clock_settime(3rt) for user-level
details andusr/src/uts/common/os/cyclic.c for details on high-resolution
timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock
ticks/second by setting hires_tick to 1 and hires_hz to the desired
time in the /etc/system file. The default is
1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
This 'documented' tick rate would seem to meet simh's requirements
without any adjustments.
Does the current simh code work? If not, what does it think the tick size is?
I will tell you once I work around ld: fatal: auxiliary filter option (-f, --auxiliary)
is only available when building a shared object
ld: fatal: flags processing errors
;)
Are you getting this problem while building the simh vax?
You are just typing:
$ make vax
Right?
Please supply the output make produces while building.
- Mark
On 13 Mar 2013, at 16:05, "Cory Smelosky" <b4 at gewt.net> wrote:
On 13 Mar 2013, at 15:43, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 12:11 PM, Cory Smelosky wrote:
On 13 Mar 2013, at 15:04, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
[...]
Idling for any simulator requires that the host system's clock tick be <= the size of the
simulated system's clock tick. VAX systems have a clock tick of 10ms.. Idling for
simulated VAX systems works best if the host clock tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size (a facility
useful for some media playback capabilities). On Windows systems simh will set the
host's clock tick to 1ms while a simulator is running.
We haven't seen programmatically settable host clock tick sizes on other platforms.
In general, other platforms have a tick size which can be changed in some system specific
way (which might require building a kernel with a desired tick size) or not changeable at
all. This issue comes up often enough that adding how to make these system specific
adjustments would be a useful addition to the simh FAQ. Any feedback on this subject
will be welcome.
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by
the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux,
this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the
100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs
on Solaris can program the real time clock to fire at nanosecond granularity, rounded up
by processor time--much finer than the clock tick granularity of ten or one milliseconds.
However, the program interface to use the high-resolution timers is not visible in the
DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c
for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting
hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is
1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
This 'documented' tick rate would seem to meet simh's requirements without any adjustments.
Does the current simh code work? If not, what does it think the tick size is?
I will tell you once I work around ld: fatal: auxiliary filter option (-f, --auxiliary) is only available when building a shared object
ld: fatal: flags processing errors
;)
sim> SET cpu idle
Idling is not available, Minimum OS sleep time is 11ms
Command not allowed
Same result as Brian. 11ms instead of 10.
Changing the values in /etc/system may be a 'user mode' activity, but it would certainly have to be done as root, and any such changes won't take effect until after the system is rebooted, so this is a 'faq' piece of information not something we'd add to the simulator code dynamically.
If coding is necessary to get this working more cleanly, then contact me offline and we can come up with a working model and merge it into the code base.
Thanks.
- Mark Pizzolato
On 13 Mar 2013, at 15:43, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 12:11 PM, Cory Smelosky wrote:
On 13 Mar 2013, at 15:04, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
[...]
Idling for any simulator requires that the host system's clock tick be <= the size of the
simulated system's clock tick. VAX systems have a clock tick of 10ms.. Idling for
simulated VAX systems works best if the host clock tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size (a facility
useful for some media playback capabilities). On Windows systems simh will set the
host's clock tick to 1ms while a simulator is running.
We haven't seen programmatically settable host clock tick sizes on other platforms.
In general, other platforms have a tick size which can be changed in some system specific
way (which might require building a kernel with a desired tick size) or not changeable at
all. This issue comes up often enough that adding how to make these system specific
adjustments would be a useful addition to the simh FAQ. Any feedback on this subject
will be welcome.
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by
the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux,
this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the
100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs
on Solaris can program the real time clock to fire at nanosecond granularity, rounded up
by processor time--much finer than the clock tick granularity of ten or one milliseconds.
However, the program interface to use the high-resolution timers is not visible in the
DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c
for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting
hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is
1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
This 'documented' tick rate would seem to meet simh's requirements without any adjustments.
Does the current simh code work? If not, what does it think the tick size is?
I will tell you once I work around ld: fatal: auxiliary filter option (-f, --auxiliary) is only available when building a shared object
ld: fatal: flags processing errors
;)
Changing the values in /etc/system may be a 'user mode' activity, but it would certainly have to be done as root, and any such changes won't take effect until after the system is rebooted, so this is a 'faq' piece of information not something we'd add to the simulator code dynamically.
If coding is necessary to get this working more cleanly, then contact me offline and we can come up with a working model and merge it into the code base.
Thanks.
- Mark Pizzolato
On Wednesday, March 13, 2013 at 12:29 PM, Brian Hechinger wrote:
On 3/13/2013 3:10 PM, Cory Smelosky wrote:
"Solaris timing uses a real-time clock that can generate interrupts at a resolution
bound by the processor speed. For scheduling purposes, it fires every 10 milliseconds.
As in Linux, this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as
opposed to the 100-tick/second clock used by Solaris and by previous versions of
Linux. User-level programs on Solaris can program the real time clock to fire at
nanosecond granularity, rounded up by processor time--much finer than the clock
tick granularity of ten or one milliseconds. However, the program interface to use
the high-resolution timers is not visible in the DDI/DKI. See clock_settime(3rt) for
user-level details andusr/src/uts/common/os/cyclic.c for details on high-resolution
timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by
setting hires_tick to 1 and hires_hz to the desired time in the /etc/system file.
The default is 1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
Are you going to take a stab at this, Mark? If not, I will.
I don't have a platform to test on, so I'd suggest that you first try messing with the values in /etc/system and if that gets things working, then I'll add it to the FAQ. If it doesn't then messing with the mentioned APIs can be explored. Since the size of the system clock tick is system wide, you can explore this without making any changes to the simh code. Write s simple program which tries to set the tick to 1ms and then sleeps until it is interrupted. While running this program start simh and see what it thinks about idling....
- Mark
On Wednesday, March 13, 2013 at 12:11 PM, Cory Smelosky wrote:
On 13 Mar 2013, at 15:04, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
[...]
Idling for any simulator requires that the host system's clock tick be <= the size of the
simulated system's clock tick. VAX systems have a clock tick of 10ms. Idling for
simulated VAX systems works best if the host clock tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size (a facility
useful for some media playback capabilities). On Windows systems simh will set the
host's clock tick to 1ms while a simulator is running.
We haven't seen programmatically settable host clock tick sizes on other platforms.
In general, other platforms have a tick size which can be changed in some system specific
way (which might require building a kernel with a desired tick size) or not changeable at
all. This issue comes up often enough that adding how to make these system specific
adjustments would be a useful addition to the simh FAQ. Any feedback on this subject
will be welcome.
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by
the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux,
this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the
100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs
on Solaris can program the real time clock to fire at nanosecond granularity, rounded up
by processor time--much finer than the clock tick granularity of ten or one milliseconds.
However, the program interface to use the high-resolution timers is not visible in the
DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c
for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting
hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is
1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
This 'documented' tick rate would seem to meet simh's requirements without any adjustments.
Does the current simh code work? If not, what does it think the tick size is?
Changing the values in /etc/system may be a 'user mode' activity, but it would certainly have to be done as root, and any such changes won't take effect until after the system is rebooted, so this is a 'faq' piece of information not something we'd add to the simulator code dynamically.
If coding is necessary to get this working more cleanly, then contact me offline and we can come up with a working model and merge it into the code base.
Thanks.
- Mark Pizzolato
On 13 Mar 2013, at 15:29, "Brian Hechinger" <wonko at 4amlunch.net> wrote:
On 3/13/2013 3:10 PM, Cory Smelosky wrote:
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux, this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the 100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs on Solaris can program the real time clock to fire at nanosecond granularity, rounded up by processor time--much finer than the clock tick granularity of ten or one milliseconds. However, the program interface to use the high-resolution timers is not visible in the DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is 1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
Are you going to take a stab at this, Mark? If not, I will.
http://docs.oracle.com/cd/E23823_01/html/816-5171/clock-settime-3rt.htm Seems to be the documentation for clock_settime(3rt)
-brian
On 3/13/2013 3:10 PM, Cory Smelosky wrote:
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux, this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the 100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs on Solaris can program the real time clock to fire at nanosecond granularity, rounded up by processor time--much finer than the clock tick granularity of ten or one milliseconds. However, the program interface to use the high-resolution timers is not visible in the DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is 1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
Are you going to take a stab at this, Mark? If not, I will.
-brian
On 3/13/2013 2:40 PM, Mark Pizzolato - Info Comm wrote:
On Wednesday, March 13, 2013 at 11:12 AM, Brian Hechinger wrote:
Thoughts?
-brian
wonko at zaphod$ make vax
lib paths are: /lib /usr/lib
using libm: /lib/libm.so
using librt: /lib/librt.so
using libpthread: /lib/libpthread.so /usr/include/pthread.h using libdl:
/lib/libdl.so /usr/include/dlfcn.h using libpcap: /usr/include/pcap.h
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 4.3.3.
*** - dynamic networking support using Solaris provided libpcap
components.
***
Hi Brian,
Sorry about this. I checked in a change yesterday in response to someone who complained about the include guards which simh's include files were using which defined symbols starting with _. I messed up one of the new guard names which didn't matter on the platform I tested the build on.
The right change has been checked in now.
Much better, thank you!
Also, the error message from the set cpu idle command on solaris is MUCH BETTER now, thanks at least for that. :)
MicroVAX 3900 simulator V4.0-0 Beta
sim> set cpu idle
Idling is not available, Minimum OS sleep time is 11ms
Command not allowed
sim>
Now to get it working on solaris.
-brian
On 13 Mar 2013, at 15:04, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
Well, I think I answered this yesterday on this list. I'll restate what I wrote here:
Thank you. I think the answer got lost when my mail server was bouncing all emails. ;)
Idling for any simulator requires that the host system's clock tick be <= the size of the simulated system's clock tick. VAX systems have a clock tick of 10ms. Idling for simulated VAX systems works best if the host clock tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size (a facility useful for some media playback capabilities). On Windows systems simh will set the host's clock tick to 1ms while a simulator is running.
We haven't seen programmatically settable host clock tick sizes on other platforms. In general, other platforms have a tick size which can be changed in some system specific way (which might require building a kernel with a desired tick size) or not changeable at all. This issue comes up often enough that adding how to make these system specific adjustments would be a useful addition to the simh FAQ. Any feedback on this subject will be welcome.
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a resolution bound by the processor speed. For scheduling purposes, it fires every 10 milliseconds. As in Linux, this is a clock "tick." Note that 2.6 Linux uses a 1000-tick/second clock, as opposed to the 100-tick/second clock used by Solaris and by previous versions of Linux. User-level programs on Solaris can program the real time clock to fire at nanosecond granularity, rounded up by processor time--much finer than the clock tick granularity of ten or one milliseconds. However, the program interface to use the high-resolution timers is not visible in the DDI/DKI. See clock_settime(3rt) for user-level details andusr/src/uts/common/os/cyclic.c for details on high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock ticks/second by setting hires_tick to 1 and hires_hz to the desired time in the /etc/system file. The default is 1000 ticks per second. Here's an example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
Recent simh code will display what it has determined to be the host's clock size if simh believes the host's clock tick is too small to support idling when you attempt to enable idling.
Recent simh code can always display host system's tick size with the 'EXAMINE TIMER OS_SLEEP_MIN_MS' command.
The latest simh code is available from https://github.com/simh/simh/archive/master.zip.
Gregg Levine wrote:
Idle on some items that are not Linux or FreeBSD or NetBSD may not
work because of how they interpret the timer. Same goes for trying to
get the idle function to work on Windows.
I haven't heard from anyone who's had issues getting idling to work on Windows. If you know of such a case, I would be interested to explore what may be happening in this case.
Thanks.
- Mark Pizzolato
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
Well, I think I answered this yesterday on this list. I'll restate what I wrote here:
Idling for any simulator requires that the host system's clock tick be <= the size of the simulated system's clock tick. VAX systems have a clock tick of 10ms. Idling for simulated VAX systems works best if the host clock tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size (a facility useful for some media playback capabilities). On Windows systems simh will set the host's clock tick to 1ms while a simulator is running.
We haven't seen programmatically settable host clock tick sizes on other platforms. In general, other platforms have a tick size which can be changed in some system specific way (which might require building a kernel with a desired tick size) or not changeable at all. This issue comes up often enough that adding how to make these system specific adjustments would be a useful addition to the simh FAQ. Any feedback on this subject will be welcome.
Recent simh code will display what it has determined to be the host's clock size if simh believes the host's clock tick is too small to support idling when you attempt to enable idling.
Recent simh code can always display host system's tick size with the 'EXAMINE TIMER OS_SLEEP_MIN_MS' command.
The latest simh code is available from https://github.com/simh/simh/archive/master.zip.
Gregg Levine wrote:
Idle on some items that are not Linux or FreeBSD or NetBSD may not
work because of how they interpret the timer. Same goes for trying to
get the idle function to work on Windows.
I haven't heard from anyone who's had issues getting idling to work on Windows. If you know of such a case, I would be interested to explore what may be happening in this case.
Thanks.
- Mark Pizzolato
