And yes set cpu idle was specified on both, in fact the ini files are identical except for network adapter name changes.
sampsa
On 31 Dec 2012, at 21:41, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 14:40, sampsa at mac.com wrote:
On 31 Dec 2012, at 20:46, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 08:26, sampsa at mac.com wrote:
I noticed that Linux SIMH is about twice as fast on OS X.
KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird.
Really? I've gotten 20 VUPS on both.
Which version of OS X?
10.7.5 (Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64)
and
10.6.8 (10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
Interesting.
Which version of SIMH and do you remember to SET CPU IDLE?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
3.7-1 on OS X, 3.9 on the Linux ones - might explain the difference.
Ohhhh, just did a 'file' on the binary I've been using (it worked so didn't feel the need to compile a new one):
bash-3.2$ file simh-vax
simh-vax: Mach-O executable i386
In any case, I don't mind the overhead of the small Linux VM underneath them and they will soon all be on a large-ish server in a colo rack as I sell my apartment. Sampsa might leave London, but SAMPSACOM stays behind :)
sampsa
On 31 Dec 2012, at 21:41, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 14:40, sampsa at mac.com wrote:
On 31 Dec 2012, at 20:46, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 08:26, sampsa at mac.com wrote:
I noticed that Linux SIMH is about twice as fast on OS X.
KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird.
Really? I've gotten 20 VUPS on both.
Which version of OS X?
10.7.5 (Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64)
and
10.6.8 (10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
Interesting.
Which version of SIMH and do you remember to SET CPU IDLE?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On 31 Dec 2012, at 14:40, sampsa at mac.com wrote:
On 31 Dec 2012, at 20:46, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 08:26, sampsa at mac.com wrote:
I noticed that Linux SIMH is about twice as fast on OS X.
KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird.
Really? I've gotten 20 VUPS on both.
Which version of OS X?
10.7.5 (Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64)
and
10.6.8 (10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
Interesting.
Which version of SIMH and do you remember to SET CPU IDLE?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On 31 Dec 2012, at 20:46, Cory Smelosky <b4 at gewt.net> wrote:
On 31 Dec 2012, at 08:26, sampsa at mac.com wrote:
I noticed that Linux SIMH is about twice as fast on OS X.
KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird.
Really? I've gotten 20 VUPS on both.
Which version of OS X?
10.7.5 (Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64)
and
10.6.8 (10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
On 31 Dec 2012, at 08:26, sampsa at mac.com wrote:
I noticed that Linux SIMH is about twice as fast on OS X.
KUHAVX got about 12 VUPS when running natively on a Core i5 iMac, 24 when in a Linux VM on the same hardware. Pretty weird.
Really? I've gotten 20 VUPS on both.
Which version of OS X?
sampsa
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
There s something else going on here. I m not sure who originally analyzed the file to decide that the format was Stream-CR (although given that the analysis was done on RSX, we can probably guess :-)
>On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote:
>> Johnny Billquist <bqt at softjar.se> writes:
>>
>>> On 2012-12-31 08:08, sampsa at mac.com wrote:
>>>> Funny thing about LEGATO's INFO.TXT - my parser looks for the .BEGIN-HECNET-INFO tag and deletes all text after that.
>>>>
>>>> I should probably make a manual HLP file for LEGATO, Bob you OK with that?
>>>
>>> LEGATO's INFO.TXT have real yucky file attributes and a real yucky
>>> file format. :-) (What on earth was used to produce it???)
>>
>> Stream_CR typically surfaces with files coming from WEENDOZE.
>
>Ah. Yes, that would be a possible, source, I guess. But I find Stream_CR a but surprising.
> Maybe I'm just too ignorant of VMS formats here. But isn't there a plain Stream as well
> (which also exists in RSX), in which records are terminated by CR+LF, and which is what
> I would expect a Windows machine to produce...
>
>>> Directory LEGATO::SYS$SPECIFIC:[FAL$SERVER]
>>> 31-DEC-12 13:59:07
>>>
>>> INFO.TXT;1
>>> Size: 8./35. Created: 08-JUL-10 10:54:52
>>> Owner: [000376,000373] Revised:
>>> 27-DEC-12 19:24:34(6.)
>>> Expires: <none_specified>
>>> File protection: System:RE, Owner:RE, Group:RE, World:RE
>>> File organization: Sequential
>>> File attributes: Allocation=0
>>> Record format: Stream-CR, no maximum defined
>>> Record attributes: Carriage return
>>
The thing is, the file isn t Stream-CR it s Stream-LF
$ dir info.txt;1
Directory SYS$SPECIFIC:[FAL$SERVER]
INFO.TXT;1
8/35 8-JUL-2010 10:54:52.34 [DECNET,FA (RE,RE,RE,RE)
$ analyze/rms info.txt;1
...
RMS FILE ATTRIBUTES
File Organization: sequential
Record Format: stream-LF
Record Attributes: carriage-return
Maximum Record Size: 0
Longest Record: 174
...
The analysis uncovered NO errors.
ANA/RMS INFO.TXT;1
So the stuff about Stream-CR is bogus and a red herring, and I don t know why Sampsa had trouble.
Bob
"Bob Armstrong" <bob at jfcl.com> writes:
I'm not convinced that a '$ CONVERT/FDL="record; format stream_lf"'
would handle that file's contents correctly.
I'm pretty sure it will. Bob, could you try?
Yes, CONVERT on VMS is perfectly happy to convert the original file.
FWIW, that's how I created the "conventional" variable record length version
that RSX likes too.
Then, it *WAS* a Stream_CR file!
And FWIW, on VMS even EDT has no issues editing the original file.
And also, ANALYZE/RMS finds no errors in the original file's format or
contents.
DUMP/RECORD on the original file shows this
Dump of file SYS$SPECIFIC:[FAL$SERVER]INFO.TXT;1 on 31-DEC-2012 09:58:05.44
File ID (2388,686,0) End of file block 8 / Allocated 35
Record number 1 (00000001), 31 (001F) bytes, RFA(0001,0000,0000)
20532745 45424544 20444E41 20424F42 BOB AND DEBEE'S 000000
454741 52414720 52455455 504D4F43 COMPUTER GARAGE. 000010
OK. This record is runs from RFA 1,0,0 to 1,0,1E.
Record number 2 (00000002), 31 (001F) bytes, RFA(0001,0000,0020)
This record startes at RFA 1,0,20. Thus, there's a byte amiss. That'd be
the <CR>.
This record goes from 1,0,20 to 1,0,3E.
2D2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------- 000000
2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------. 000010
Record number 3 (00000003), 0 (0000) bytes, RFA(0001,0000,0040)
Record 3 starts at 1,0,40. So, it looks like 1,0,3F is a <CR>.
Record number 4 (00000004), 79 (004F) bytes, RFA(0001,0000,0041)
6F6E2065 68742073 69207369 68542020 This is the no 000000
65727275 63202C4F 54414745 4C206564 de LEGATO, curre 000010
6F697461 74735841 56206120 796C746E ntly a VAXstatio 000020
696E6E75 7220434C 562F3030 30342D6E n-4000/VLC runni 000030
6E6920 2C312E37 20534D56 4F20676E ng OVMS 7.1, in. 000040
Record number 5 (00000005), 78 (004E) bytes, RFA(0001,0000,0091)
20732765 65626544 20646E61 20626F42 Bob and Debee's 000000
20656761 72614720 72657475 706D6F43 Computer Garage 000010
4820746E 656D6572 69746552 20646E61 and Retirement H 000020
20434544 20646C6F 20726F66 20656D6F ome for old DEC 000030
7449 20202E73 72657475 706D6F63 computers. It.. 000040
... which doesn't show any extra LFs or CRs in the file, but I guess that
doesn't prove anything if you believe that RMS is silently eating them.
Although, ... you can see from the RFAs that there's only one "overhead"
byte between the records, so whatever the end of record character is,
there's only one.
Correct.
I thought there was a way to get DUMP to dump the raw blocks in the file
and bypass RMS completely, but I can't find it anymore.
$ DUMP/BLOCKS
If you do, I'll wager you'll see a 0D at the locations I've indicated.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
I'm not convinced that a '$ CONVERT/FDL="record; format stream_lf"'
would handle that file's contents correctly.
I'm pretty sure it will. Bob, could you try?
Yes, CONVERT on VMS is perfectly happy to convert the original file.
FWIW, that's how I created the "conventional" variable record length version
that RSX likes too.
And FWIW, on VMS even EDT has no issues editing the original file.
And also, ANALYZE/RMS finds no errors in the original file's format or
contents.
DUMP/RECORD on the original file shows this
Dump of file SYS$SPECIFIC:[FAL$SERVER]INFO.TXT;1 on 31-DEC-2012 09:58:05.44
File ID (2388,686,0) End of file block 8 / Allocated 35
Record number 1 (00000001), 31 (001F) bytes, RFA(0001,0000,0000)
20532745 45424544 20444E41 20424F42 BOB AND DEBEE'S 000000
454741 52414720 52455455 504D4F43 COMPUTER GARAGE. 000010
Record number 2 (00000002), 31 (001F) bytes, RFA(0001,0000,0020)
2D2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------- 000000
2D2D2D 2D2D2D2D 2D2D2D2D 2D2D2D2D ---------------. 000010
Record number 3 (00000003), 0 (0000) bytes, RFA(0001,0000,0040)
Record number 4 (00000004), 79 (004F) bytes, RFA(0001,0000,0041)
6F6E2065 68742073 69207369 68542020 This is the no 000000
65727275 63202C4F 54414745 4C206564 de LEGATO, curre 000010
6F697461 74735841 56206120 796C746E ntly a VAXstatio 000020
696E6E75 7220434C 562F3030 30342D6E n-4000/VLC runni 000030
6E6920 2C312E37 20534D56 4F20676E ng OVMS 7.1, in. 000040
Record number 5 (00000005), 78 (004E) bytes, RFA(0001,0000,0091)
20732765 65626544 20646E61 20626F42 Bob and Debee's 000000
20656761 72614720 72657475 706D6F43 Computer Garage 000010
4820746E 656D6572 69746552 20646E61 and Retirement H 000020
20434544 20646C6F 20726F66 20656D6F ome for old DEC 000030
7449 20202E73 72657475 706D6F63 computers. It.. 000040
... which doesn't show any extra LFs or CRs in the file, but I guess that
doesn't prove anything if you believe that RMS is silently eating them.
Although, ... you can see from the RFAs that there's only one "overhead"
byte between the records, so whatever the end of record character is,
there's only one.
I thought there was a way to get DUMP to dump the raw blocks in the file
and bypass RMS completely, but I can't find it anymore.
As I remember, on RSX it's fairly easy to bypass RMS and read the raw
blocks in a file. In fact, RMS is technically optional on RSX, so it's not
uncommon to do so. On VMS, however, RMS is always there and it's not that
easy to read a file without it. Vaxman can tell me if I'm wrong, but I think
you have to resort to logical I/O in order to bypass RMS, which would
require LOG_IO privilege. The default DECnet account doesn't have that, so
I'm not sure how the FALSERVER would even be sending raw blocks from the
file to RSX.
Bob
Thanks for trying Johnny!
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Mon, 31 Dec 2012 18:02:41
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SE
Cc: <hvlems at zonnet.nl>
Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems
On 2012-12-31 17:56, hvlems at zonnet.nl wrote:
Yes, I meant the original.
Did you try it or predict the outcome?
Just predicted. But here you go:
..nft x.y=legato::info.txt;1
.dsp x.y
DU4:[DECNET]X.Y;1
Size: 8./35. Created: 31-DEC-2012 17:58
Owner: [007,014] Revised: 31-DEC-2012 17:58
File ID: (124,21,0) Expires: <none_specified>
File protection: System:RWED, Owner:RWED, Group:R, World:R
File organization: Sequential
File attributes: Allocation=35, Extend=0
Record format: Stream, no maximum defined
Record attributes: Carriage return
..edt x.y
Input file could not be opened
File name:DU4:[DECNET]X.Y;1
IE.BTP - Bad record type
EDT don't understand Stream either. Very few tools in RSX do, since most
things use FCS, and FCS don't have the stream format. It's only RMS that do.
In order to get it manageable in RSX, I do:
..nft x.y=legato::info.txt;1/as
.dsp x.y
DU4:[DECNET]X.Y;2
Size: 8./8. Created: 31-DEC-2012 18:01
Owner: [007,014] Revised: 31-DEC-2012 18:01
File ID: (126,7,0) Expires: <none_specified>
File protection: System:RWED, Owner:RWED, Group:R, World:R
File organization: Sequential
File attributes: Allocation=8, Extend=0
Record format: Variable length, no maximum defined
Record attributes: Carriage return
And then I can edit it, or play with it in any form. However, each line
ends with a LF.
Johnny
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Mon, 31 Dec 2012 17:52:55
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SE
Cc: <hvlems at zonnet.nl>
Subject: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems
On 2012-12-31 17:46, hvlems at zonnet.nl wrote:
Johnny, what happens if you feed the file to EDT ?
You mean the original, Stream_CR file?
EDT will be totally unimpressed, and refuse.
Johnny
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Cc: Brian Schenkenberger, VAXman-
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems
Verzonden: 31 december 2012 17:39
On 2012-12-31 17:20, Brian Schenkenberger, VAXman- wrote:
"Bob Armstrong" <bob at jfcl.com> writes:
It's been a few years since I edited that file, but there's about a
95% probability that it was created and edited with Gnu EMACS for VMS.
The only other possibilities are EDT or EVE, and I'm pretty sure those
both create VFC text files rather than stream.
Looking around at other stuff that I've edited with EMACS on LEGATO, I
see that they also have similar record formats. I've never had a
problem using text files that I edited with EMACS with any VMS utility,
so I'm not sure why you've got issues.
VMS can process of of the RMS file formats is support. It would appear
that this one format is one that RSX does not.
I think that VMS is lying to itself in this case, and VMS is buying it.
A file with Stream_CR, and not a single CR in the file... What would you
expect the result to be?
(Or rather, Emacs is lying to VMS, and VMS is buying it.)
However, when feeding that file over DECnet, the result looks ugly, so
the FAL in VMS isn't totally falling for the lie. :-)
Johnny