Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Emulated VAX build done!



>> I've actually had two such runs going; I started a second build of
>> the same world on different host hardware.  One of them is still
>> going, but the other finished last night.

>> Still going: running on NetBSD/i386 on
> How'd that one turn out?

It completed, a day or two sooner than I was expecting, apparently
fine.  I didn't wait for a full compare to finish, but after looking at
bin, distrib, etc, and much of games, the differences were limited to
finished executables (not sure why), .a libraries (which contain modify
timestamps), and .so and .po objects (not sure why).  In particular, I
didn't find a difference between plain .o files.

>> for a speed ratio of about 1.543.  I don't know how much of the
>> difference is NetBSD versus Linux and how much is the hardware; my
>> guess is that it's almost entirely the hardware, possibly with a
>> small admixture of compiler version.
> That doesn't make much sense.  The Linux machine is 2.6 GHz, plus
> does turbo clocking to 3.5 GHz, whereas the Pentium 4 at 1.6 GHz
> would give a ratio of 1.6 to 1, even if we didn't take in to
> consideration all of the IPC improvements.

I expect IPC to be close to irrelevant.  The emulator is
single-threaded and, while not quite single-process, does _almost_
everything in a single process; there are helpers, but they are
involved only when receiving input from the console or network, when
writing output to the console, and, possibly, when sending to the
network, though it would depend on how I ran it - one of the network
backends pushes output through the helper process, but most don't.  I'm
fairly sure I used one of the latter backends.  In any case, the
build-of-the-world doesn't do much network I/O: it sent 4534704 octets
of TCP payload in 11+ (fast run) or 16+ (slow run) days, plus, I think,
an ntpdate run once per (I think) hour; that isn't very much.

> Something is slowing down the Linux machine considerably.

Now that they've both finished, I have final time figures.  Here are
the final log lines:

 16 23:05:16.53 Build finished at: Thu Oct 12 13:12:17 EDT 2023

 11 00:37:02.09 Build finished at: Thu Oct 12 01:01:51 EDT 2023

The time difference is, thus, 146551653 to 95262209, for a factor of
about 1.538.  Lower than the 1.543 preliminary figure, below your 1.6
but not all that much below it.  (As the remark about ntpdate implies,
I don't entirely trust the VAX timekeeping, but the timestamps quoted
above don't come from the emulated VAXen.  They come from the machines
I was saving the logfiles on - which are NTP-synced and thus should
have errors on the order of milliseconds - so the VAX timekeeping isn't
a possible source of significant error there.)

I was using the Linux machine for a few other things at various times,
but nothing compute-heavy; even if half the reported 8 cores are
hyperthreads, that still leaves 4 real cores, of which the emulator is
using, at most, barely over one.

It occurs to me that it may have been doing thermal throttling.  I have
seen it said that running one, but only one, core heavily on a
multi-core chip can cause mechanical stress (due to temperature
differences) between parts of the die; if the i7 in question takes any
measures to mitigate that, they could be relevant.

The P4 machine is a single-CPU machine.  I avoided using it for
anything else; the only other things it should have been doing were NTP
and pushing copies of disk writes to its backup when the emulator wrote
to its disk (such writes end up writing to the host machine's disk,
since the emulator disk is backed by a host-filesystem file).

Now, I'm chasing a different issue.  If I start the emulator and just
boot, it boots fine, but if I boot, halt, and then, without restarting
the emulator, boot again, it panics:

...
	booted from type 17 unit 0 controller 0 adapter 0
	boot device: ra0
	root on ra0a dumps on ra0b
	rronline: d_secperunit=4194304 from onle_unitsize
(the previous line is some debugging I added for an MSCP issue.)
	ra0: size 4194304 sectors
	mountroot: trying nfs...
	mountroot: trying ffs...
	root file system type: ffs
	init: copying out flags `-s' 3
	init: copying out path `/sbin/init' 11
	Enter pathname of shell or RETURN for sh: 
	# halt -q
	syncing disks... done
	unmounting / (root_device)...
	uvm_vnp_terminate(0x80410414): terminating active vnode (refs=2)
	uvm_vnp_terminate(0x80379a90): terminating active vnode (refs=2)
	uvm_vnp_terminate(0x803794e0): terminating active vnode (refs=2)
	
	?06 HLT INST
	    PC = 80028358
	>>> b dua0
	
	  2..1..0..
	
	
	>> NetBSD/vax boot [Oct  7 2023 20:58:07] <<
	>> Press any key to abort autoboot 4
	Press '?' for help
	> boot -s
	687240+36464+214948+[52836+59690] total=0x100a32
	avail 00000000-00ffe000
	physmem=00000ffe
	sysptsize=0003e588
	virtual avail=80ffe000 end=87cb1000
	ISP=801fdc00, RZ=801fcc00
	[ preserving 112532 bytes of netbsd a.out symbol table ]
	Copyright (c) 1996, 1997, 1998, 1999, 2000
	    The NetBSD Foundation, Inc.  All rights reserved.
	Copyright (c) 1982, 1986, 1989, 1991, 1993
	    The Regents of the University of California.  All rights reserved.
	
	NetBSD 1.4T (UVAXII) #1: Thu Oct 12 21:57:09 EDT 2023
	    root@:/root/kbuild/UVAXII
	
	MicroVAX II
	total memory = 16372 KB
	panic: ptelen fault in system space: addr 6c pc 80018730
	panic: ptelen fault in system space: addr 70 pc 8001878a
	Stopped in  at  _arithflt+0x22a:        movl    $5, r0
	db> 

I don't have a real KA630 set up to try this on, so I don't know
whether it's a bug in the emulator or a bug in the kernel I'm booting.
I did instruction traces and the only differences are ignorable right
up to the point at which it finds the message buffer already set up; I
haven't yet followed my traces past that point.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index