When running klh10 emulator with tops-10 v7.04 as the guest OS, klh10 uses about 95% of the CPU of 1 of my cores.

This is a known issue with klh10 running tops-10 as documented in the klh10 distribution in the doc/dvhost.txt file.

I found a solution from Rich Alderson from a post 12 years ago at:
https://alt.sys.pdp10.narkive.com/UCpN700h/how-to-rebuild-tops10-rel#post9

where Rich mentions his tops-10 patch was successful, and he managed to get the CPU time reduced from 95% to 0.5% when klh10/tops-10 was idle.

I followed the instructions in that post as closely as possible, did all the steps, but my klh10 cpu time stays at 95% all the time.

In case Rich Alderson views this post and can respond, I'll list all the steps I did below in the hopes that he can find something I did wrong.

..LOGIN 1,2
..dir
BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
..copy prod.exe=dskb:system.exe[1,4]
..copy test.exe=dskb:system.exe[1,4]
..dir
BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
PROD EXE 1920 <057> 10-Apr-22 704(33461)
TEST EXE 1920 <057> 10-Apr-22 704(33461)
Total of 3964 blocks in 3 files on DSKB: [1,2]
..r filddt
File: test.exe/p
[Patching file DSKB:TEST.EXE[1,2]]
[36539 symbols loaded from file]
[ACs copied from CRSHAC to 0-17]
NULCOD+1/ SOJG W,P CONO 740,1
^EFile: ^C
..copy dskb:system.exe[1,4]=test.exe
..rename [1,4]*.*=test2.exe
Files renamed:
DSKB:TEST.EXE
..dir
BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
PROD EXE 1920 <057> 10-Apr-22 704(33461)
Total of 2044 blocks in 2 files on DSKB: [1,2]

and then I edited the ini file I am using to add the 2 lines:
;To keep host cpu% for kn-10, apply the patch and use this line below.
devdefine idler 740 host ; PDP-10 device 740

The full ini file is listed below.

KLH10 configuration for TOPS-10 test system

; DTE requires ackdly to avoid T10 race condition
devdef dte0 200 dte master ackdly=5
devdef rh0 540 rh20
devdef rh1 544 rh20
;devdef dsk0 rh0.0 rp type=rp06 sn=4747 format=dbd9 path=T10-RP06.0-dbd9
;devdef dsk1 rh0.1 rp type=rp06 sn=1026 format=dbd9 path=T10-RP06.1-dbd9
devdef dsk0 rh0.0 rp type=rp06 sn=4747 path=KL_dskb0.rp6
devdef dsk1 rh0.1 rp type=rp06 sn=1026 path=KL_dskb1.rp6
devdef mta0 rh1.0 tm03 type=TU77

;To keep host cpu% for kn-10, apply the patch and use this line below.
devdefine idler 740 host ; PDP-10 device 740

; NI: param "c3dly" to avoid T10 race.
; NI: param "rdtmo" to avoid system hangups with OSF/1 V3.0
; ; Decnet node TWONKY, 9.429
;devdef ni0 564 ni20 dedic=0 decnet=1 doarp=0 enaddr=aa:00:04:00:ad:25 dpdelay=12 c3dly=2 rdtmo=3

load klboot.exe

William Sternbach <wgs777@gmail.com> writes:

> When running klh10 emulator with tops-10 v7.04 as the guest OS, klh10 uses
> about 95% of the CPU of 1 of my cores.

> This is a known issue with klh10 running tops-10 as documented in the klh10
> distribution in the doc/dvhost.txt file.

> I found a solution from Rich Alderson from a post 12 years ago at:
> https://alt.sys.pdp10.narkive.com/UCpN700h/how-to-rebuild-tops10-rel#post9

Holy crap.

> where Rich mentions his tops-10 patch was successful, and he managed to get
> the CPU time reduced from 95% to 0.5% when klh10/tops-10 was idle.

> I followed the instructions in that post as closely as possible, did all the
> steps, but my klh10 cpu time stays at 95% all the time.

Well, no, you didn't. I don't think that you have done what you think you have
done...

> In case Rich Alderson views this post and can respond, I'll list all the
> steps I did below in the hopes that he can find something I did wrong.

> .LOGIN 1,2
> .dir
> BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> .copy prod.exe=dskb:system.exe[1,4]
> .copy test.exe=dskb:system.exe[1,4]
> .dir
> BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> PROD EXE 1920 <057> 10-Apr-22 704(33461)
> TEST EXE 1920 <057> 10-Apr-22 704(33461)
> Total of 3964 blocks in 3 files on DSKB: [1,2]
> .r filddt
> File: test.exe/p
> [Patching file DSKB:TEST.EXE[1,2]]
> [36539 symbols loaded from file]
> [ACs copied from CRSHAC to 0-17]
> NULCOD+1/ SOJG W,P CONO 740,1
> ^EFile: ^C
> .copy dskb:system.exe[1,4]=test.exe

If you really did this, you have copied your patched monitor over the default
system monitor. Probably not what you wanted to do.

> .rename [1,4]*.*=test2.exe

Umm, I don't see a TEST2.EXE in your directory listing. What did you actually
do here?

> Files renamed:
> DSKB:TEST.EXE

Something's lying to one of us.

> .dir
> BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> PROD EXE 1920 <057> 10-Apr-22 704(33461)
> Total of 2044 blocks in 2 files on DSKB: [1,2]

> and then I edited the ini file I am using to add the 2 lines:
> ;To keep host cpu% for kn-10, apply the patch and use this line below.
> devdefine idler 740 host ; PDP-10 device 740

> The full ini file is listed below.

> KLH10 configuration for TOPS-10 test system

> ; DTE requires ackdly to avoid T10 race condition
> devdef dte0 200 dte master ackdly=5
> devdef rh0 540 rh20
> devdef rh1 544 rh20
> ;devdef dsk0 rh0.0 rp type=rp06 sn=4747 format=dbd9 path=T10-RP06.0-dbd9
> ;devdef dsk1 rh0.1 rp type=rp06 sn=1026 format=dbd9 path=T10-RP06.1-dbd9
> devdef dsk0 rh0.0 rp type=rp06 sn=4747 path=KL_dskb0.rp6
> devdef dsk1 rh0.1 rp type=rp06 sn=1026 path=KL_dskb1.rp6
> devdef mta0 rh1.0 tm03 type=TU77

> ;To keep host cpu% for kn-10, apply the patch and use this line below.
> devdefine idler 740 host ; PDP-10 device 740

> ; NI: param "c3dly" to avoid T10 race.
> ; NI: param "rdtmo" to avoid system hangups with OSF/1 V3.0
> ;
> ; Decnet node TWONKY, 9.429
> ;devdef ni0 564 ni20 dedic=0 decnet=1 doarp=0 enaddr=aa:00:04:00:ad:25 dpdelay=12 c3dly=2 rdtmo=3

> load klboot.exe

OK, the configuration looks reasonable (ignoring the use of DECnet, which has
always sucked).

So let's review what my 2010 instructions actually said to do.

| Boot Tops-10 on KLH10. Make a copy of DSKB:SYSTEM.EXE[1,4] as any other name,
| such as TOPS10.EXE. Run FILDDT, and change the single location you want to
| patch:

| .copy tops10.exe=dskb:system.exe[1,4]

This puts a copy of the system monitor in your connected directory, presumably
the one you logged in to. Above, you have 2 copies TEST.EXE and PROD.EXE; fine.

| .r filddt
| File name: tops10.exe/p
| <now do your patching>
| ^Z

^E in theory does the same things as ^Z then prompts for another file to read
into FILDDT. Use ^Z to be certain you're getting what you think you're getting.

| .rename [1,4]*.*=tops10.exe

This moves your patched monitor (in your case, TEST.EXE instead of TOPS10.EXE)
into the SYS: directory, AND LEAVES THE SYSTEM MONITOR TF ALONE.

| At your next boot, type TOPS10.EXE at the BOOT> prompt, and you;ll be running
| your patched monitor.

You don't show what happens when you boot. Is klboot.exe giving you a BOOT>
prompt? How are you responding to that, given that you appear to have
clobbered the monitor?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Monday, April 11, 2022 at 10:39:45 PM UTC-4, Rich Alderson wrote:
> William Sternbach <wgs...@no-spam.com> writes:
>
> > When running klh10 emulator with tops-10 v7.04 as the guest OS, klh10 uses
> > about 95% of the CPU of 1 of my cores.
>
> > This is a known issue with klh10 running tops-10 as documented in the klh10
> > distribution in the doc/dvhost.txt file.
>
> > I found a solution from Rich Alderson from a post 12 years ago at:
> > https://alt.sys.pdp10.narkive.com/UCpN700h/how-to-rebuild-tops10-rel#post9
> Holy crap.
> > where Rich mentions his tops-10 patch was successful, and he managed to get
> > the CPU time reduced from 95% to 0.5% when klh10/tops-10 was idle.
>
> > I followed the instructions in that post as closely as possible, did all the
> > steps, but my klh10 cpu time stays at 95% all the time.
> Well, no, you didn't. I don't think that you have done what you think you have
> done...
> > In case Rich Alderson views this post and can respond, I'll list all the
> > steps I did below in the hopes that he can find something I did wrong.
>
> > .LOGIN 1,2
> > .dir
> > BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> > .copy prod.exe=dskb:system.exe[1,4]
> > .copy test.exe=dskb:system.exe[1,4]
> > .dir
> > BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> > PROD EXE 1920 <057> 10-Apr-22 704(33461)
> > TEST EXE 1920 <057> 10-Apr-22 704(33461)
> > Total of 3964 blocks in 3 files on DSKB: [1,2]
> > .r filddt
> > File: test.exe/p
> > [Patching file DSKB:TEST.EXE[1,2]]
> > [36539 symbols loaded from file]
> > [ACs copied from CRSHAC to 0-17]
> > NULCOD+1/ SOJG W,P CONO 740,1
> > ^EFile: ^C
> > .copy dskb:system.exe[1,4]=test.exe
> If you really did this, you have copied your patched monitor over the default
> system monitor. Probably not what you wanted to do.
>
> > .rename [1,4]*.*=test2.exe
>
> Umm, I don't see a TEST2.EXE in your directory listing. What did you actually
> do here?
>
> > Files renamed:
> > DSKB:TEST.EXE
>
> Something's lying to one of us.
> > .dir
> > BACKUP EXE 124 <057> 19-Dec-88 5(614) DSKB: [1,2]
> > PROD EXE 1920 <057> 10-Apr-22 704(33461)
> > Total of 2044 blocks in 2 files on DSKB: [1,2]
>
> > and then I edited the ini file I am using to add the 2 lines:
> > ;To keep host cpu% for kn-10, apply the patch and use this line below.
> > devdefine idler 740 host ; PDP-10 device 740
>
> > The full ini file is listed below.
>
> > KLH10 configuration for TOPS-10 test system
>
> > ; DTE requires ackdly to avoid T10 race condition
> > devdef dte0 200 dte master ackdly=5
> > devdef rh0 540 rh20
> > devdef rh1 544 rh20
> > ;devdef dsk0 rh0.0 rp type=rp06 sn=4747 format=dbd9 path=T10-RP06.0-dbd9
> > ;devdef dsk1 rh0.1 rp type=rp06 sn=1026 format=dbd9 path=T10-RP06.1-dbd9
> > devdef dsk0 rh0.0 rp type=rp06 sn=4747 path=KL_dskb0.rp6
> > devdef dsk1 rh0.1 rp type=rp06 sn=1026 path=KL_dskb1.rp6
> > devdef mta0 rh1.0 tm03 type=TU77
>
> > ;To keep host cpu% for kn-10, apply the patch and use this line below.
> > devdefine idler 740 host ; PDP-10 device 740
>
> > ; NI: param "c3dly" to avoid T10 race.
> > ; NI: param "rdtmo" to avoid system hangups with OSF/1 V3.0
> > ;
> > ; Decnet node TWONKY, 9.429
> > ;devdef ni0 564 ni20 dedic=0 decnet=1 doarp=0 enaddr=aa:00:04:00:ad:25 dpdelay=12 c3dly=2 rdtmo=3
>
> > load klboot.exe
> OK, the configuration looks reasonable (ignoring the use of DECnet, which has
> always sucked).
>
> So let's review what my 2010 instructions actually said to do.
>
> | Boot Tops-10 on KLH10. Make a copy of DSKB:SYSTEM.EXE[1,4] as any other name,
> | such as TOPS10.EXE. Run FILDDT, and change the single location you want to
> | patch:
>
> | .copy tops10.exe=dskb:system.exe[1,4]
>
> This puts a copy of the system monitor in your connected directory, presumably
> the one you logged in to. Above, you have 2 copies TEST.EXE and PROD.EXE; fine.
>
> | .r filddt
> | File name: tops10.exe/p
> | <now do your patching>
> | ^Z
>
> ^E in theory does the same things as ^Z then prompts for another file to read
> into FILDDT. Use ^Z to be certain you're getting what you think you're getting.
>
> | .rename [1,4]*.*=tops10.exe
>
> This moves your patched monitor (in your case, TEST.EXE instead of TOPS10.EXE)
> into the SYS: directory, AND LEAVES THE SYSTEM MONITOR TF ALONE.
>
> | At your next boot, type TOPS10.EXE at the BOOT> prompt, and you;ll be running
> | your patched monitor.
>
> You don't show what happens when you boot. Is klboot.exe giving you a BOOT>
> prompt? How are you responding to that, given that you appear to have
> clobbered the monitor?
>
> --
> Rich Alderson ne...@no-spam.com
> Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
> --Galen

Hi Rich,
Thank you so much for your time on this. With your help, I got it working.
My CPU time is now very low: 0.08% when running kn10-kl. I am very grateful. Thank you.

The missing steps were the correct rename command, typing TOPS10.EXE at first BOOT>, and an ini same line comment that was causing devdefine idler statement to fail.

One question. It appears that the patch must be applied at every bootup.
BOOT>TOPS10.EXE

Would you know the command to automate the BOOT>TOPS10.EXE step (perhaps in the startup ini for for ./kn10-kl)?

I wanted to post everything I did here (which was successful), so it could benefit others who face the same issue.
#Patch of :system.exe[1,4] Info at: https://alt.sys.pdp10.narkive.com/UCpN700h/how-to-rebuild-tops10-rel
#Replace "SOJG 6,1" to "CONO 740,1"
LOGIN 1,2
SET TTY VT100
..copy tops10.exe=dskb:system.exe[1,4]
..r filddt
File: tops10.exe/p
[Patching file DSKB:TOPS10.EXE[1,2]]
[36539 symbols loaded from file]
[ACs copied from CRSHAC to 0-17]
NULCOD+1/ SOJG W,P CONO 740,1
^Z
..rename [1,4]*.*=tops10.exe
Files renamed:
DSKB:TOPS10.EXE
..kjob
^\
quit

Notes on the above r filddt edit:
While on same line, after it displays: SOJG W,P
type in on same line without pressing spacebar: CONO 740,1
hit enter, CTRL Z to save, and CTRL C to exit.

Add this to your klh10 startup ini:
vi twonky2.ini, and add this line after the last devdef:
;To keep host cpu% for kn-10, apply the patch and use this line below.
devdefine idler 740 host

Then apply patch everytime you boot up by typing TOPS10.EXE at the first BOOT>
../kn10-kl twonky2.ini
KLH10> go
Starting KN10 at loc 0703667...
BOOT V4(100)

BOOT>TOPS10.EXE
[Loading from DSKB:TOPS10.EXE[1,4]]

KL704 19-Dec-88
Why reload: SCHED
Date:
Time:
Startup option: GO
[Rebuilding the system search list from the HOM blocks]

[Rebuilding the active swapping list from the HOM blocks]

[Rebuilding the system dump list from the HOM blocks]

William Sternbach <wgs777@gmail.com> writes:

> The missing steps were the correct rename command, typing TOPS10.EXE at first
> BOOT>, and an ini same line comment that was causing devdefine idler
> statement to fail.

> One question. It appears that the patch must be applied at every bootup.
> BOOT>TOPS10.EXE

> Would you know the command to automate the BOOT>TOPS10.EXE step (perhaps in
> the startup ini for for ./kn10-kl)?

I don't think you mean "patch must be applied", but rather that you have to
type in the name of the desired (copy of the) monitor. That's a feature, not a
bug. :-)

Once you're happy with the patched monitor, do the following:

.rename system.org[1,4]=system.exe[1,4]

Reboot, and specify "system.org" to the BOOT> prompt, then

.rename system.exe[1,4]=tops10.exe[1,4]

Now you can reboot with just a carriage return at the BOOT> prompt.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Tuesday, April 12, 2022 at 6:25:59 PM UTC-7, Rich Alderson wrote:

(snip)

> Once you're happy with the patched monitor, do the following:
> .rename system.org[1,4]=system.exe[1,4]
> Reboot, and specify "system.org" to the BOOT> prompt, then
> .rename system.exe[1,4]=tops10.exe[1,4]
> Now you can reboot with just a carriage return at the BOOT> prompt.
Just wondering, what happens if you do a rename while the one being
renamed is running?

-- glen

gah4 <gah4@u.washington.edu> writes:

> On Tuesday, April 12, 2022 at 6:25:59 PM UTC-7, Rich Alderson wrote:

> (snip)

>> Once you're happy with the patched monitor, do the following:

>> .rename system.org[1,4]=system.exe[1,4]

>> Reboot, and specify "system.org" to the BOOT> prompt, then

>> .rename system.exe[1,4]=tops10.exe[1,4]

>> Now you can reboot with just a carriage return at the BOOT> prompt.

> Just wondering, what happens if you do a rename while the one being
> renamed is running?

Probably nothing, but I don't like fucking around.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Wednesday, April 13, 2022 at 6:43:37 PM UTC-7, Rich Alderson wrote:

(snip, I wrote)
> > Just wondering, what happens if you do a rename while the one being
> > renamed is running?

> Probably nothing, but I don't like fucking around.

Reminds me of some years ago with HP-UX, recompiling (and linking)
a program while the previous version was running. As soon as it wrote
out the new executable, the previous one crashed.

It seems that it uses the file itself as backing store for virtual
storage of the code. (Data is kept separate.) I believe other systems
also do something like that.

On 2022-04-14 06:48, gah4 wrote:
> On Wednesday, April 13, 2022 at 6:43:37 PM UTC-7, Rich Alderson wrote:
>
> (snip, I wrote)
>>> Just wondering, what happens if you do a rename while the one being
>>> renamed is running?
>
>> Probably nothing, but I don't like fucking around.
>
> Reminds me of some years ago with HP-UX, recompiling (and linking)
> a program while the previous version was running. As soon as it wrote
> out the new executable, the previous one crashed.
>
> It seems that it uses the file itself as backing store for virtual
> storage of the code. (Data is kept separate.) I believe other systems
> also do something like that.

Yes. That is normal. However, normally linking should really remove
(unlink) the old binary, and write a new binary to a new file, and not
rewrite the existing binary. If things are done like that, currently
running program would be fine.

Also, if NFS is involved, things could get a bit funny, since NFS don't
really handle this in a good way.

And it's not that data is any different. It's just that if you modify
memory, then the original image can't be used for the backing store
anymore, but space have to be taken from swap for it. But unmodified
data can be taken from the original image as the backing store.

Johnny

You can rename, delete, copy the Tops 10 monitor while the system is running. The monitor
is kept totally in memory or swap space when running.

Rich

> >> Once you're happy with the patched monitor, do the following:
>
> >> .rename system.org[1,4]=system.exe[1,4]
>
> >> Reboot, and specify "system.org" to the BOOT> prompt, then
>
> >> .rename system.exe[1,4]=tops10.exe[1,4]
>
> >> Now you can reboot with just a carriage return at the BOOT> prompt.
>
> > Just wondering, what happens if you do a rename while the one being
> > renamed is running?
> Probably nothing, but I don't like fucking around.
> --
> Rich Alderson ne...@alderson.users.panix.com
> Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
> --Galen

On Thursday, April 14, 2022 at 2:03:11 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)
> > Reminds me of some years ago with HP-UX, recompiling (and linking)
> > a program while the previous version was running. As soon as it wrote
> > out the new executable, the previous one crashed.
> > It seems that it uses the file itself as backing store for virtual
> > storage of the code. (Data is kept separate.) I believe other systems
> > also do something like that.

> Yes. That is normal. However, normally linking should really remove
> (unlink) the old binary, and write a new binary to a new file, and not
> rewrite the existing binary. If things are done like that, currently
> running program would be fine.
Yes, Unix tradition is that if you unlink an open file, it stays around
without a name until it is closed. It seems that it doesn't do that,
and it did surprise me when it happened. If instead of unlink, it just
truncates it to size zero, then it doesn't keep the old one around.

> Also, if NFS is involved, things could get a bit funny, since NFS don't
> really handle this in a good way.
I suspect it was NFS. NFS knows about open files, and instead renames
them to a hidden internal name, to delete later. But if the client crashes
with the file still open, the server doesn't know to delete it. (Part of
the stateless operation of NFS.). Some run a cron job to search for
those and delete them.

> And it's not that data is any different. It's just that if you modify
> memory, then the original image can't be used for the backing store
> anymore, but space have to be taken from swap for it. But unmodified
> data can be taken from the original image as the backing store.

I remember the early days of OS/2, (and probably later). I had OS/2 1.0
running on an AT clone, much more fun than DOS. OS/2 uses the
EXE file for backing store on hard disks, but not for floppy disks.
(Also, I don't think it has the Unix convention for unlink.)

gah4 <gah4@u.washington.edu> writes:
>On Thursday, April 14, 2022 at 2:03:11 AM UTC-7, Johnny Billquist wrote:
>
>(snip, I wrote)
>> > Reminds me of some years ago with HP-UX, recompiling (and linking)
>> > a program while the previous version was running. As soon as it wrote
>> > out the new executable, the previous one crashed.
>
>> > It seems that it uses the file itself as backing store for virtual
>> > storage of the code. (Data is kept separate.) I believe other systems
>> > also do something like that.
>
>> Yes. That is normal. However, normally linking should really remove
>> (unlink) the old binary, and write a new binary to a new file, and not
>> rewrite the existing binary. If things are done like that, currently
>> running program would be fine.
>
>Yes, Unix tradition is that if you unlink an open file, it stays around
>without a name until it is closed. It seems that it doesn't do that,
>and it did surprise me when it happened. If instead of unlink, it just
>truncates it to size zero, then it doesn't keep the old one around.

That just means the tool (ld(1) or whatever) didn't remove the old file,
it just opened it read/write and overwrote it.

If you manually unlink(2)/rm(1) the file before the linker opens it,
then the old inode will hang around until the process(es) using it
all exit, and any new use of the executable will use the new code.