On 03/13/2013 05:41 PM, Cory Smelosky wrote:
What are the current values in /etc/system?
That's a parameter override file; it won't be in there unless someone
wants to change it from the default.
Is it okay if I wait a day or so to add those? It requires a reboot
to do that and i'm planning on taking the system down for maintenance
in a couple days when some NICs get here. I like not having to
reboot multiple times. ;)
Your NICs are on the way; I'd expect you should have them tomorrow or
Friday.
Most Solaris folk aren't really accustomed to just rebooting their
machines.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 13 Mar 2013, at 17:45, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 2:41 PM, Cory Smelosky wrote:
On 13 Mar 2013, at 17:38, "Mark Pizzolato - Info Comm"
<Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 1:09 PM, Cory Smelosky wrote:
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.
OK. So, now it is time to try and adjust the system clock tick.
What are the current values in /etc/system?
What happens if you change /etc/system to have:
set hires_tick=1
set hires_hz=1000
Reboot and try the simh vax again....
Is it okay if I wait a day or so to add those? It requires a reboot to do that and
i'm planning on taking the system down for maintenance in a couple days
when some NICs get here. I like not having to reboot multiple times. ;)
Sure, but what are the current values in /etc/system?
The keys mentioned above are not currently in /etc/system.
Meanwhile, I've changed the makefile so that it should work on your platform without any modification. Please test the latest from github.
Builds fine now. Thank you.
Thanks.
- Mark
On Wednesday, March 13, 2013 at 2:41 PM, Cory Smelosky wrote:
On 13 Mar 2013, at 17:38, "Mark Pizzolato - Info Comm"
<Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 1:09 PM, Cory Smelosky wrote:
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.
OK. So, now it is time to try and adjust the system clock tick.
What are the current values in /etc/system?
What happens if you change /etc/system to have:
set hires_tick=1
set hires_hz=1000
Reboot and try the simh vax again....
Is it okay if I wait a day or so to add those? It requires a reboot to do that and
i'm planning on taking the system down for maintenance in a couple days
when some NICs get here. I like not having to reboot multiple times. ;)
Sure, but what are the current values in /etc/system?
Meanwhile, I've changed the makefile so that it should work on your platform without any modification. Please test the latest from github.
Thanks.
- Mark
On 13 Mar 2013, at 17:38, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 1:09 PM, Cory Smelosky wrote:
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.
OK. So, now it is time to try and adjust the system clock tick.
What are the current values in /etc/system?
What happens if you change /etc/system to have:
set hires_tick=1
set hires_hz=1000
Reboot and try the simh vax again .
Is it okay if I wait a day or so to add those? It requires a reboot to do that and i'm planning on taking the system down for maintenance in a couple days when some NICs get here. I like not having to reboot multiple times. ;)
- Mark
On Wednesday, March 13, 2013 at 1:09 PM, Cory Smelosky wrote:
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.
OK. So, now it is time to try and adjust the system clock tick.
What are the current values in /etc/system?
What happens if you change /etc/system to have:
set hires_tick=1
set hires_hz=1000
Reboot and try the simh vax again....
- Mark
On Wednesday, March 13, 2013 at 1:42 PM, Dave McGuire wrote:
On 03/13/2013 04:21 PM, Cory Smelosky wrote:
mkdir -p BIN
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions
-fgcse-after-reload -fpredictive-commoning -fipa-cp-clone
-fno-unsafe-loop-optimizations -fno-strict-overflow -flto
-fwhole-program -Wno-unused-result -I . -D_GNU_SOURCE
-DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so
sim_BuildROMs.c
-o BIN/BuildROMs
ld: fatal: auxiliary filter option (-f, --auxiliary) is only available
when building a shared object
First of all, Cory...have you tried using Sun's compiler? It kicks the snot out
of GCC for SPARC code generation. I did give you a copy.
I would suggest that this would be a good idea.
I have an old SparcStation which I fire up once every few years to test simh on a Big Endian platform. It has a Linux disk and a Solaris disk (I don't recall the version). I do not have a sun C compiler. The last time I fired it up (more than a year ago) the basic testing worked out fine but I noticed that some things were so slow it was practically unusable. I isolated some slow behavior down to an operation which walked across a 64MB chunk of VAX memory one byte at a time. The 64MB array is stored in a single malloc'ed area. This walk across the 64MB took some 20 seconds, while the same operation on my Windows desktop takes far less than any time I could measure on my watch. My theory was that it was spending all of its time in the alignment trap handler, but I didn't have enough knowledge to dig into the details.
The test case is demonstrated by the following commands:
$ BIN/vax
MicroVAX 3900 simulator V4.0-0 Beta
sim> set cpu 64m
sim> save somefile
The save operation writes the current simulator state to a file.
- Mark
On 13 Mar 2013, at 16:58, "Mark Pizzolato - Info Comm" <Mark at infocomm.com> wrote:
On Wednesday, March 13, 2013 at 1:21 PM, Cory Smelosky wrote:
bash-3.2$ gmake 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/local/lib/libpcap.a /usr/local/include/pcap.h
*** Warning ***
*** Warning *** vax Simulator being built with networking support using
*** Warning *** libpcap components from www.tcpdump.org.
*** Warning *** Some users have had problems using the
www.tcpdump.org libpcap
*** Warning *** components for simh networking. For best results, with
*** Warning *** simh networking, it is recommended that you install the
*** Warning *** libpcap-dev package from your Solaris distribution
*** Warning ***
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 4.6.3..
*** - networking support using libpcap components from
www.tcpdump.org.
***
mkdir -p BIN
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload -
fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-
strict-overflow -flto -fwhole-program -Wno-unused-result -I . -
D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -
DHAVE_DLOPEN=so sim_BuildROMs.c -o BIN/BuildROMs
ld: fatal: auxiliary filter option (-f, --auxiliary) is only available when building a
shared object
ld: fatal: flags processing errors
Modification to makefile is to remove -flto -fwhole-program. Then it builds
fine. ;)
I'd like to get this to work without any modifications to the makefile.
Can you send the output of the following:
$ gcc --help=optimizers
$ gcc -v --help
$ gcc -v /dev/null
Thanks.
http://pastebin.com/ijqnUajq
- Mark
On 03/13/2013 05:02 PM, Mark Pizzolato - Info Comm wrote:
You'll also have to change any GCC-specific options ("-f<xxx") in
the Makefile.
I don't think gcc specific options are used if the compiler isn't gcc. That is
why I'd like to know 'how things work out'....
I seem to recall that they were, the last time I did it, but it has been awhile
since I did that build.
The makefile was drastically rewritten in simh v3.9 (last May) and even more so since then.
Ahh ok, excellent.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Wednesday, March 13, 2013 at 1:57 PM, Dave McGuire wrote:
On 03/13/2013 04:50 PM, Mark Pizzolato - Info Comm wrote:
On Wednesday, March 13, 2013 at 1:48 PM, Dave McGuire wrote:
On 03/13/2013 04:46 PM, Mark Pizzolato - Info Comm wrote:
On Wednesday, March 13, 2013 at 1:42 PM. Dave McGuire wrote:
On 03/13/2013 04:21 PM, Cory Smelosky wrote:
mkdir -p BIN
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions
-fgcse-after-reload -fpredictive-commoning -fipa-cp-clone
-fno-unsafe-loop-optimizations -fno-strict-overflow -flto
-fwhole-program -Wno-unused-result -I . -D_GNU_SOURCE
-DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so
sim_BuildROMs.c
-o BIN/BuildROMs
ld: fatal: auxiliary filter option (-f, --auxiliary) is only
available when building a shared object
First of all, Cory...have you tried using Sun's compiler? It
kicks the snot out of GCC for SPARC code generation. I did give you a
copy.
In case it isn't obvious, using this makefile with a different
compiler (called
suncc for instance) is done by:
$ make GCC=suncc vax
Let me know how things work out....
You'll also have to change any GCC-specific options ("-f<xxx") in
the Makefile.
I don't think gcc specific options are used if the compiler isn't gcc. That is
why I'd like to know 'how things work out'....
I seem to recall that they were, the last time I did it, but it has been awhile
since I did that build.
The makefile was drastically rewritten in simh v3.9 (last May) and even more so since then.
- Mark
On Wednesday, March 13, 2013 at 1:21 PM, Cory Smelosky wrote:
bash-3.2$ gmake 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/local/lib/libpcap.a /usr/local/include/pcap.h
*** Warning ***
*** Warning *** vax Simulator being built with networking support using
*** Warning *** libpcap components from www.tcpdump.org.
*** Warning *** Some users have had problems using the
www.tcpdump.org libpcap
*** Warning *** components for simh networking. For best results, with
*** Warning *** simh networking, it is recommended that you install the
*** Warning *** libpcap-dev package from your Solaris distribution
*** Warning ***
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 4.6.3.
*** - networking support using libpcap components from
www.tcpdump.org.
***
mkdir -p BIN
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload -
fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-
strict-overflow -flto -fwhole-program -Wno-unused-result -I . -
D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -
DHAVE_DLOPEN=so sim_BuildROMs.c -o BIN/BuildROMs
ld: fatal: auxiliary filter option (-f, --auxiliary) is only available when building a
shared object
ld: fatal: flags processing errors
Modification to makefile is to remove -flto -fwhole-program. Then it builds
fine. ;)
I'd like to get this to work without any modifications to the makefile.
Can you send the output of the following:
$ gcc --help=optimizers
$ gcc -v --help
$ gcc -v /dev/null
Thanks.
- Mark
