Discussion:
NetBSD/vax current
(too old to reply)
emanuel stiebler
2014-04-13 14:04:50 UTC
Permalink
Raw Message
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.

Thanks again!
Dave McGuire
2014-04-13 16:27:33 UTC
Permalink
Raw Message
Post by emanuel stiebler
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.
Thanks again!
Seconded. I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work. I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!) and plan to do much
NetBSD/vax hacking in the not too distant future.

Let's keep this port alive!

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave McGuire
2014-04-13 18:59:33 UTC
Permalink
Raw Message
Post by Dave McGuire
I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work.
I know how that goes. Paying bills :(
Yep.
Anyway, I wanted to finally go back to the graphics on the 4000/90,
but only managed it to a point of having a build able system.
And some head scratching about the wscon ;-)
Well that's a start, anyway!
Post by Dave McGuire
I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!)
Please, don't tell me you it really is a PAIR?
Yup! They arrived a little over a week ago. Pics here:

http://www.neurotica.com/misc/VAXen/
Post by Dave McGuire
and plan to do much
NetBSD/vax hacking in the not too distant future.
Same here ...
:-)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Anders Magnusson
2014-04-13 20:03:43 UTC
Permalink
Raw Message
Please, don't tell me you it really is a PAIR?
http://www.neurotica.com/misc/VAXen/
Wow, I'm impressed! It must have been 15 years ago since I last saw a
11/785 :-)

I didn't see any I/O cabinets on the pictures, were they just left out
of the pictures or are you missing them?
The CPU will feel quite lonely without them I assume.

If you look at this picture:
http://www.netbsd.org/ports/vax/picture.html you can see a cabinet
between the TU78 and the CPU in the middle which is the I/O cabinet.

-- Ragge
Dave McGuire
2014-04-13 20:05:29 UTC
Permalink
Raw Message
Post by Anders Magnusson
Please, don't tell me you it really is a PAIR?
http://www.neurotica.com/misc/VAXen/
Wow, I'm impressed! It must have been 15 years ago since I last saw a
11/785 :-)
I didn't see any I/O cabinets on the pictures, were they just left out
of the pictures or are you missing them?
The CPU will feel quite lonely without them I assume.
I have two I/O racks each containing a Unibus expansion chassis.
There are also two HSC90s, one rack of RA92s, and one rack of RA72s, and
the TA78.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave McGuire
2014-04-13 20:28:53 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by Anders Magnusson
Please, don't tell me you it really is a PAIR?
http://www.neurotica.com/misc/VAXen/
Wow, I'm impressed! It must have been 15 years ago since I last saw a
11/785 :-)
I didn't see any I/O cabinets on the pictures, were they just left out
of the pictures or are you missing them?
The CPU will feel quite lonely without them I assume.
I have two I/O racks each containing a Unibus expansion chassis.
There are also two HSC90s, one rack of RA92s, and one rack of RA72s, and
the TA78.
Now we're talking :-) Do you have UDA50's or must you go via the HSCs?
In that case I hope you have CI780's, otherwise it will be terrible
slow. If not it will be just ordinary slow.
I have a UDA50 in one of the machines, and a CI780 in one of the
machines. I have another CI780 (with backplane) that came in a pile of
spare parts for the 11/785s.
UDA50's are not the fastest creatures either, IIRC the fastest disks for
the 780's were non-interleaved RP07. That disk OTOH required 3-phase
380V 32A, even though i think it had Y-D startup.
Yeah. No RP07s here, unfortunately.

I have a number of UDA50s in other machines. They run very nicely in
PDP-11s.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Anders Magnusson
2014-04-14 05:49:41 UTC
Permalink
Raw Message
Post by Dave McGuire
UDA50's are not the fastest creatures either, IIRC the fastest disks for
the 780's were non-interleaved RP07. That disk OTOH required 3-phase
380V 32A, even though i think it had Y-D startup.
Yeah. No RP07s here, unfortunately.
I have a number of UDA50s in other machines. They run very nicely in
PDP-11s.
The controllers work OK, but you may hit the Unibus speed limit.
Also be sure that you put the DELUA in the other unibus box or they'll
compete much about the bus speed.

With DELUA it should be possible to get about 5Mbit/s (on 780) if it is
on its own unibus.

-- Ragge
Anders Magnusson
2014-04-13 20:14:50 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by Anders Magnusson
Please, don't tell me you it really is a PAIR?
http://www.neurotica.com/misc/VAXen/
Wow, I'm impressed! It must have been 15 years ago since I last saw a
11/785 :-)
I didn't see any I/O cabinets on the pictures, were they just left out
of the pictures or are you missing them?
The CPU will feel quite lonely without them I assume.
I have two I/O racks each containing a Unibus expansion chassis.
There are also two HSC90s, one rack of RA92s, and one rack of RA72s, and
the TA78.
Now we're talking :-) Do you have UDA50's or must you go via the HSCs?
In that case I hope you have CI780's, otherwise it will be terrible
slow. If not it will be just ordinary slow.

UDA50's are not the fastest creatures either, IIRC the fastest disks for
the 780's were non-interleaved RP07. That disk OTOH required 3-phase
380V 32A, even though i think it had Y-D startup.

-- Ragge
Johnny Billquist
2014-04-13 19:21:42 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by emanuel stiebler
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.
Thanks again!
Seconded. I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work. I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!) and plan to do much
NetBSD/vax hacking in the not too distant future.
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(

By the way, my comments about my 3500 a couple of weeks ago... After
firing up my 4000/90, I'm now thinking that it's partly a problem that
16M of memory just is way too little to run NetBSD as well.

However, running on a simulated 8650 at least seems to have revealed
some kind of issue if you were to have more than 64M in one 86x0.
Unfortunately, I don't have quite that much in the real machine, so I
can't verify this on real hardware, but using simh, VMS works fine with
512M while NetBSD goes wrong somewhere when you have more than 64M.
Since NetBSD works ok on my 4000/90 with more memory, it must be
something related to things early in the boot process, me thinks. I'm
going to look at it soon, unless someone beats me to it.

I also have a bunch of uncommitted 86x0 stuff that I should try to send in.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Dave McGuire
2014-04-13 19:32:07 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Dave McGuire
Post by emanuel stiebler
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.
Thanks again!
Seconded. I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work. I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!) and plan to do much
NetBSD/vax hacking in the not too distant future.
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Perhaps I should've been more specific. I plan to run VMS on the
11/785s. I have a few 4000/90s and other later machines for NetBSD.
Post by Johnny Billquist
By the way, my comments about my 3500 a couple of weeks ago... After
firing up my 4000/90, I'm now thinking that it's partly a problem that
16M of memory just is way too little to run NetBSD as well.
That figures.

NetBSD really has turned into a bloated pig over the past decade or
so. Maybe even a little earlier than that.
Post by Johnny Billquist
However, running on a simulated 8650 at least seems to have revealed
some kind of issue if you were to have more than 64M in one 86x0.
Unfortunately, I don't have quite that much in the real machine, so I
can't verify this on real hardware, but using simh, VMS works fine with
512M while NetBSD goes wrong somewhere when you have more than 64M.
Since NetBSD works ok on my 4000/90 with more memory, it must be
something related to things early in the boot process, me thinks. I'm
going to look at it soon, unless someone beats me to it.
I also have a bunch of uncommitted 86x0 stuff that I should try to send in.
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Johnny Billquist
2014-04-13 19:43:05 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by Johnny Billquist
Post by Dave McGuire
Post by emanuel stiebler
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.
Thanks again!
Seconded. I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work. I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!) and plan to do much
NetBSD/vax hacking in the not too distant future.
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Perhaps I should've been more specific. I plan to run VMS on the
11/785s. I have a few 4000/90s and other later machines for NetBSD.
Ah. Now, that makes more sense. VMS will move pretty nicely on those
machines.
Post by Dave McGuire
Post by Johnny Billquist
By the way, my comments about my 3500 a couple of weeks ago... After
firing up my 4000/90, I'm now thinking that it's partly a problem that
16M of memory just is way too little to run NetBSD as well.
That figures.
NetBSD really has turned into a bloated pig over the past decade or
so. Maybe even a little earlier than that.
Yeah. :-(
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the 4000/90
grabbed more than 16M before the boot was complete, so with only 16M it
is going to be paging a lot.
Post by Dave McGuire
Post by Johnny Billquist
However, running on a simulated 8650 at least seems to have revealed
some kind of issue if you were to have more than 64M in one 86x0.
Unfortunately, I don't have quite that much in the real machine, so I
can't verify this on real hardware, but using simh, VMS works fine with
512M while NetBSD goes wrong somewhere when you have more than 64M.
Since NetBSD works ok on my 4000/90 with more memory, it must be
something related to things early in the boot process, me thinks. I'm
going to look at it soon, unless someone beats me to it.
I also have a bunch of uncommitted 86x0 stuff that I should try to send in.
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
John Klos
2014-04-13 20:35:17 UTC
Permalink
Raw Message
I'm going to try and do some more testing, but I really can't see many other
explanations. I noticed that just booting NetBSD up on the 4000/90 grabbed
more than 16M before the boot was complete, so with only 16M it is going to
be paging a lot.
NetBSD 6 runs OK on a VAXstation 4000/30 with 24 megs. Not great, but OK.

http://vax.zia.io/

The hardware isn't as cool as an 11/785, but it's a bit more affordable
to run :)
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much fat
and take way too long to do anything. And I wonder how much better an
entirely crunchgen'd NetBSD would be on a very low memory machine...

John
Toby Thain
2014-04-13 21:12:07 UTC
Permalink
Raw Message
Post by John Klos
Post by Johnny Billquist
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the
4000/90 grabbed more than 16M before the boot was complete, so with
only 16M it is going to be paging a lot.
NetBSD 6 runs OK on a VAXstation 4000/30 with 24 megs. Not great, but OK.
Any recommendations for a MicroVAX II with 9MB? I have 1.4.1 netbooting
on it right now and it's pretty happy - was able to compile Apache
1.3.x, etc.

Is 1.5 okay for such a small system? I've read conflicting opinions.
Post by John Klos
http://vax.zia.io/
The hardware isn't as cool as an 11/785, but it's a bit more affordable
to run :)
Post by Johnny Billquist
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much fat
and take way too long to do anything. And I wonder how much better an
entirely crunchgen'd NetBSD would be on a very low memory machine...
I wonder if lcc does a better job than pcc. lcc is ANSI and has a VAX
code generator, that's fairly easy to modify.

https://sites.google.com/site/lccretargetablecompiler/

--Toby
Post by John Klos
John
Johnny Billquist
2014-04-13 21:23:33 UTC
Permalink
Raw Message
Post by Toby Thain
Post by John Klos
Post by Johnny Billquist
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the
4000/90 grabbed more than 16M before the boot was complete, so with
only 16M it is going to be paging a lot.
NetBSD 6 runs OK on a VAXstation 4000/30 with 24 megs. Not great, but OK.
Any recommendations for a MicroVAX II with 9MB? I have 1.4.1 netbooting
on it right now and it's pretty happy - was able to compile Apache
1.3.x, etc.
Is 1.5 okay for such a small system? I've read conflicting opinions.
If you ask me, 1.6 is just fine as well. 2.0 is still also pretty ok.
I'm not sure exactly when things became horrible, but back in those
versions, NetBSD was still pretty snappy, as far as I can remember.
(Used to run a VAX-11/750 with it, and still thought it was acceptable.)

On another side note, NetBSD/vax (but I sortof notice something similar
on other architectures) are hitting the namei sys-cache a lot. And when
that happens, the system is spending the majority of the time in system,
and are not making much progress on anything.
There seems to be a very clear correspondence between the namei calls
and the amount of time spent in system. With gcc just chugging along
trying to compile a file, I see maybe 1000 namei calls in 5s (looking at
system). With this, I have about 10% system time. When namei calls jumps
to above 6000 I have more than 50% time in system, sometimes going up to
over 80%. The correlation is not absolute, but there definitely seems to
be some connection between them.

I recently fired up an Alpha with current, and sometimes the namei calls
jumps up to over 100.000, which I found rather impressive. (Although
maybe also depressing.) And of course, that machine also spent large
chunks of time in system.
Post by Toby Thain
Post by John Klos
http://vax.zia.io/
The hardware isn't as cool as an 11/785, but it's a bit more affordable
to run :)
Post by Johnny Billquist
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much fat
and take way too long to do anything. And I wonder how much better an
entirely crunchgen'd NetBSD would be on a very low memory machine...
I wonder if lcc does a better job than pcc. lcc is ANSI and has a VAX
code generator, that's fairly easy to modify.
https://sites.google.com/site/lccretargetablecompiler/
I think that Ragge have gotten pcc more or less to compile most of
NetBSD, so ANSI is not a problem.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David Brownlee
2014-04-14 13:04:34 UTC
Permalink
Raw Message
It would be nice if there were numbers for the relative performance of
NetBSD versions.
I've alluded to this before, and I'd be happy to collect them, but the
only machines supported by 1.2 were the uVAXII and 11/750, and I only
have a 4000 and a VS2000. (*)

I think the idea test box would be a 16M uVAXII, though a smaller RAM
size would also be helpful.

Since NetBSD (usually) provides excellent backwards compatibility it
should be possible to install NetBSD 1.2, run some timings, and then
retest the same install with a kernel from 1.3, 1.4, 1.5...
(There may be a version which requires new boot blocks, but the
principle applies).

That first pass would determine how kernel code bloat has affected the
system over time.

The second pass would be be similar, but reinstalling the entire
system rather than kernel each time.

One key point would be to determine a useful set of tests - lmbench,
apachebench against a simple http server, and a nasty shell script?

I know that gcc bloat makes it effectively unusable on anything but
the largest memory/fastest VAXes now day, but it would be helpful to
determine what has happened to baseline NetBSD performance...

David

(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
Post by Toby Thain
Post by John Klos
Post by Johnny Billquist
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the
4000/90 grabbed more than 16M before the boot was complete, so with
only 16M it is going to be paging a lot.
NetBSD 6 runs OK on a VAXstation 4000/30 with 24 megs. Not great, but OK.
Any recommendations for a MicroVAX II with 9MB? I have 1.4.1 netbooting
on it right now and it's pretty happy - was able to compile Apache
1.3.x, etc.
Is 1.5 okay for such a small system? I've read conflicting opinions.
If you ask me, 1.6 is just fine as well. 2.0 is still also pretty ok. I'm
not sure exactly when things became horrible, but back in those versions,
NetBSD was still pretty snappy, as far as I can remember. (Used to run a
VAX-11/750 with it, and still thought it was acceptable.)
On another side note, NetBSD/vax (but I sortof notice something similar on
other architectures) are hitting the namei sys-cache a lot. And when that
happens, the system is spending the majority of the time in system, and are
not making much progress on anything.
There seems to be a very clear correspondence between the namei calls and
the amount of time spent in system. With gcc just chugging along trying to
compile a file, I see maybe 1000 namei calls in 5s (looking at system). With
this, I have about 10% system time. When namei calls jumps to above 6000 I
have more than 50% time in system, sometimes going up to over 80%. The
correlation is not absolute, but there definitely seems to be some
connection between them.
I recently fired up an Alpha with current, and sometimes the namei calls
jumps up to over 100.000, which I found rather impressive. (Although maybe
also depressing.) And of course, that machine also spent large chunks of
time in system.
Post by Toby Thain
Post by John Klos
http://vax.zia.io/
The hardware isn't as cool as an 11/785, but it's a bit more affordable
to run :)
Post by Johnny Billquist
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much fat
and take way too long to do anything. And I wonder how much better an
entirely crunchgen'd NetBSD would be on a very low memory machine...
I wonder if lcc does a better job than pcc. lcc is ANSI and has a VAX
code generator, that's fairly easy to modify.
https://sites.google.com/site/lccretargetablecompiler/
I think that Ragge have gotten pcc more or less to compile most of NetBSD,
so ANSI is not a problem.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
Anders Magnusson
2014-04-14 14:10:00 UTC
Permalink
Raw Message
Post by David Brownlee
It would be nice if there were numbers for the relative performance of
NetBSD versions.
I've alluded to this before, and I'd be happy to collect them, but the
only machines supported by 1.2 were the uVAXII and 11/750, and I only
have a 4000 and a VS2000. (*)
I'm quite sure the 11/780 was supported, since I generated the 1.2
release on a 780 :-)

And now when Dave has two of them we may ask him nicely (785, but it's
the same, just a little faster) if he can install and test some old
NetBSD, just to get the performance figures.

-- Ragge
Post by David Brownlee
uname -a
NetBSD skorpan 1.4ZA NetBSD 1.4ZA (SKORPAN) #0: Tue Jun 6 21:06:11 CEST
2000
Post by David Brownlee
uptime
10:04PM up 242 days, 21:04, 1 user, load averages: 0.39, 0.16, 0.11
Post by David Brownlee
/sbin/dmesg
NetBSD 1.4ZA (SKORPAN) #0: Tue Jun 6 21:06:11 CEST 2000
***@bakfull:/usr/home/ragge/work/nbsd/sys/arch/vax/compile/SKORPAN

MicroVAX II
total memory = 13300 KB
avail memory = 10228 KB
using 191 buffers containing 764 KB of memory
mainbus0 (root)
ibus0 at mainbus0
uba0 at ibus0: Q22
dhu0 at uba0 csr 160440 vec 320 ipl 17
dhu0: rom(1) version 2 rom(0) version 2
dhu0: DHV-11
dhu1 at uba0 csr 160040 vec 300 ipl 17
dhu1: rom(1) version 2 rom(0) version 2
dhu1: DHV-11
mtc0 at uba0 csr 174500 vec 774 ipl 17
mscpbus0 at mtc0: version 5 model 3
mscpbus0: DMA burst size set to 4
mt0 at mscpbus0 drive 0: TK50
uda0 at uba0 csr 172150 vec 770 ipl 17
mscpbus1 at uda0: version 4 model 3
mscpbus1: DMA burst size set to 4
ra0 at mscpbus1 drive 0: RD54
ra1 at mscpbus1 drive 1: RD54
rx0 at mscpbus1 drive 2: RX50
rx1 at mscpbus1 drive 3: RX50
qe0 at uba0 csr 174440 vec 764 ipl 17
qe0: delqa, hardware address 08:00:2b:03:b6:32
boot device: ra0
root on ra0a dumps on ra0b
ra0: size 312375 sectors
Clock has lost 397 day(s) - CHECK AND RESET THE DATE.
root file system type: ffs
Dave McGuire
2014-04-14 16:12:21 UTC
Permalink
Raw Message
Post by Anders Magnusson
And now when Dave has two of them we may ask him nicely (785, but it's
the same, just a little faster) if he can install and test some old
NetBSD, just to get the performance figures.
Of course, I'm always up for stuff like this. These machines have
been powered off for a very long time, so it'll be awhile, but they will
be available (assuming I can get at least one of them running) for
anything anyone wants to do.
:-)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave McGuire
2014-04-14 16:11:01 UTC
Permalink
Raw Message
Post by David Brownlee
(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
If you strike out on that, and want to shell out the bucks for
shipping from the USA, I will happily give you one.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave McGuire
2014-04-14 18:36:19 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by David Brownlee
(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
If you strike out on that, and want to shell out the bucks for
shipping from the USA, I will happily give you one.
-Dave
But then you can't run a shared memory config with MS780 :-)
(or at least I think it was the MS780)
I'm offering him a MicroVAX-II, not one of my 11/785s! ;)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
David Brownlee
2014-04-15 20:50:08 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by Dave McGuire
Post by David Brownlee
(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
If you strike out on that, and want to shell out the bucks for
shipping from the USA, I will happily give you one.
But then you can't run a shared memory config with MS780 :-)
(or at least I think it was the MS780)
I'm offering him a MicroVAX-II, not one of my 11/785s! ;)
-Dave
In the London - for a fully configured 11/785 it would probably be
easier to put by house in the machine than the machine in my house :)

Dave - many thanks for the offer. I'm hoping one might float by
eventually this end - I started looking for a VS2000 a little while
ago and one just dropped into my lap, so I might get lucky again :)
Dave McGuire
2014-04-16 20:12:04 UTC
Permalink
Raw Message
Post by David Brownlee
Post by Dave McGuire
I'm offering him a MicroVAX-II, not one of my 11/785s! ;)
In the London - for a fully configured 11/785 it would probably be
easier to put by house in the machine than the machine in my house :)
:-)
Post by David Brownlee
Dave - many thanks for the offer. I'm hoping one might float by
eventually this end - I started looking for a VS2000 a little while
ago and one just dropped into my lap, so I might get lucky again :)
Sounds good. Good luck!

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Antonio Carlini
2014-04-14 18:35:12 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by David Brownlee
(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
If you strike out on that, and want to shell out the bucks for
shipping from the USA, I will happily give you one.
-Dave
But then you can't run a shared memory config with MS780 :-)

(or at least I think it was the MS780)

Antonio
John D. Peedle
2014-04-14 16:22:34 UTC
Permalink
Raw Message
Whilst not what you were looking for, I have a 3100 M10 with a disk expansion unit and a 4000VLC needing homes.

Best regards,

John
Post by David Brownlee
It would be nice if there were numbers for the relative performance of
NetBSD versions.
I've alluded to this before, and I'd be happy to collect them, but the
only machines supported by 1.2 were the uVAXII and 11/750, and I only
have a 4000 and a VS2000. (*)
I think the idea test box would be a 16M uVAXII, though a smaller RAM
size would also be helpful.
Since NetBSD (usually) provides excellent backwards compatibility it
should be possible to install NetBSD 1.2, run some timings, and then
retest the same install with a kernel from 1.3, 1.4, 1.5...
(There may be a version which requires new boot blocks, but the
principle applies).
That first pass would determine how kernel code bloat has affected the
system over time.
The second pass would be be similar, but reinstalling the entire
system rather than kernel each time.
One key point would be to determine a useful set of tests - lmbench,
apachebench against a simple http server, and a nasty shell script?
I know that gcc bloat makes it effectively unusable on anything but
the largest memory/fastest VAXes now day, but it would be helpful to
determine what has happened to baseline NetBSD performance...
David
(* If someone has a spare uVAXII in the UK I'd be delighted to give it
a loving home, but I'm not trying to use the above as an excuse to pry
one out of an existing home.... well, not really :)
Post by Toby Thain
Post by John Klos
Post by Johnny Billquist
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the
4000/90 grabbed more than 16M before the boot was complete, so with
only 16M it is going to be paging a lot.
NetBSD 6 runs OK on a VAXstation 4000/30 with 24 megs. Not great, but OK.
Any recommendations for a MicroVAX II with 9MB? I have 1.4.1 netbooting
on it right now and it's pretty happy - was able to compile Apache
1.3.x, etc.
Is 1.5 okay for such a small system? I've read conflicting opinions.
If you ask me, 1.6 is just fine as well. 2.0 is still also pretty ok. I'm
not sure exactly when things became horrible, but back in those versions,
NetBSD was still pretty snappy, as far as I can remember. (Used to run a
VAX-11/750 with it, and still thought it was acceptable.)
On another side note, NetBSD/vax (but I sortof notice something similar on
other architectures) are hitting the namei sys-cache a lot. And when that
happens, the system is spending the majority of the time in system, and are
not making much progress on anything.
There seems to be a very clear correspondence between the namei calls and
the amount of time spent in system. With gcc just chugging along trying to
compile a file, I see maybe 1000 namei calls in 5s (looking at system). With
this, I have about 10% system time. When namei calls jumps to above 6000 I
have more than 50% time in system, sometimes going up to over 80%. The
correlation is not absolute, but there definitely seems to be some
connection between them.
I recently fired up an Alpha with current, and sometimes the namei calls
jumps up to over 100.000, which I found rather impressive. (Although maybe
also depressing.) And of course, that machine also spent large chunks of
time in system.
Post by Toby Thain
Post by John Klos
http://vax.zia.io/
The hardware isn't as cool as an 11/785, but it's a bit more affordable
to run :)
Post by Johnny Billquist
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much fat
and take way too long to do anything. And I wonder how much better an
entirely crunchgen'd NetBSD would be on a very low memory machine...
I wonder if lcc does a better job than pcc. lcc is ANSI and has a VAX
code generator, that's fairly easy to modify.
https://sites.google.com/site/lccretargetablecompiler/
I think that Ragge have gotten pcc more or less to compile most of NetBSD,
so ANSI is not a problem.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
Anders Magnusson
2014-04-14 05:53:15 UTC
Permalink
Raw Message
Post by John Klos
Post by Johnny Billquist
Post by Dave McGuire
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
It'd be nice to see pcc for VAX instead of gcc. gcc has way too much
fat and take way too long to do anything. And I wonder how much better
an entirely crunchgen'd NetBSD would be on a very low memory machine...
Please go ahead, pcc should work reasonably well on vax. Not all
possible optimizations added yet, though.

I have noted while recently porting pcc to 68k that gcc is very fond of
unwindling branches in a way that is quite memory-consuming.
I think this is one of the reason that binaries has grown a little too
much lately.

-- Ragge
Dave McGuire
2014-04-13 22:57:36 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Dave McGuire
Post by Johnny Billquist
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Perhaps I should've been more specific. I plan to run VMS on the
11/785s. I have a few 4000/90s and other later machines for NetBSD.
Ah. Now, that makes more sense. VMS will move pretty nicely on those
machines.
Yes. I run it (v7.3) regularly on XEROX, a MicroVAX-II that serves as
a media translation machine between RL and RA drives, and disk images
for same.
Post by Johnny Billquist
I'm going to try and do some more testing, but I really can't see many
other explanations. I noticed that just booting NetBSD up on the 4000/90
grabbed more than 16M before the boot was complete, so with only 16M it
is going to be paging a lot.
Oh yes, ouch.

I remember putting twenty users in 16MB regularly under SunOS, on a
68020. (Sun 3/180s) I was a NetBSD user at the time, as well, but this
was the 0.9/1.0 days. My how things have changed.
Post by Johnny Billquist
Post by Dave McGuire
Post by Johnny Billquist
However, running on a simulated 8650 at least seems to have revealed
some kind of issue if you were to have more than 64M in one 86x0.
Unfortunately, I don't have quite that much in the real machine, so I
can't verify this on real hardware, but using simh, VMS works fine with
512M while NetBSD goes wrong somewhere when you have more than 64M.
Since NetBSD works ok on my 4000/90 with more memory, it must be
something related to things early in the boot process, me thinks. I'm
going to look at it soon, unless someone beats me to it.
I also have a bunch of uncommitted 86x0 stuff that I should try to send in.
Well, get to it, man! ;) I expect there will eventually be a fork of
NetBSD that will trim the fat and make it more usable. Testing on
older, slower hardware would go a long way toward "keeping it honest".
Question is if anyone have the time, energy and money for that to happen?
Well, we'll see. Enough people want it. It's not like it actually
costs any money...just time and motivation. Money can just free up time
and generate motivation. ;)

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Mouse
2014-04-17 19:17:19 UTC
Permalink
Raw Message
[bqt]
Trying to just build a kernel on the 11/785 will take an estimated
two weeks. Really.
What version? -current? I'm not surprised. I remember how
disappointed I was back around 4.something, I think it was, that i386
couldn't practically self-host in (IIRC) 32MB because it paged itself
to death building the compiler.

I somehow doubt it's gotten any better (though for all I know VAX might
not be as bad as i386 in that regard).

[mcguire]
NetBSD really has turned into a bloated pig over the past decade or
so. Maybe even a little earlier than that.
It has. Some of that is functionality - but a lot isn't.
I expect there will eventually be a fork of NetBSD that will trim the
fat and make it more usable. Testing on older, slower hardware would
go a long way toward "keeping it honest".
It would. It did with NetBSD, for a while.

[mcguire replying to someone else, if I'm reading things right]
Post by Johnny Billquist
Question is if anyone have the time, energy and money for that to happen?
Well, we'll see. Enough people want it. It's not like it actually
costs any money...just time and motivation. Money can just free up
time and generate motivation. ;)
Mostly true. (Running VAXen does cost money, the more for the larger
machines, unless the electricity is somehow free - which can happen, eg
during the heating season for those who heat with electricity.)

I've got the desire, certainly, and have a git repo with my fork of
1.4T (git://git.rodents-montreal.org/Mouse/netbsd-fork/1.4T/src), but
haven't put any of my VAXen back together after my latest move, and my
KA630 emulator is still stuck failing to POST because I need to make
sending characters to the console take time.

And now, between the new job and the new gf, my spare time budget is
completely shot anyway. Not that I'd give either one up - well, maybe
the job - but even if I consider them worth the price, it's still a
price.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Thor Lancelot Simon
2014-04-18 16:46:54 UTC
Permalink
Raw Message
Post by Mouse
[bqt]
Trying to just build a kernel on the 11/785 will take an estimated
two weeks. Really.
What version? -current? I'm not surprised. I remember how
disappointed I was back around 4.something, I think it was, that i386
couldn't practically self-host in (IIRC) 32MB because it paged itself
to death building the compiler.
Blaming NetBSD for the increase in size and runtime of GCC seems a
little disingenuous to me. If you guys are determined to play this
game, at the very least turn GCC's newer and more expensive optimizations
off, or use PCC.

Thor
Mouse
2014-04-18 22:08:27 UTC
Permalink
Raw Message
Post by Thor Lancelot Simon
Blaming NetBSD for the increase in size and runtime of GCC seems a
little disingenuous to me.
It would to me too, except that NetBSD chose to ship the affected
(afflicted?) gcc with the system.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Johnny Billquist
2014-04-13 20:20:36 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Dave McGuire
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel
on the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Probably much longer. Generating NetBSD 1.2 release took two weeks (on
an 780). 11 days to compile the system and 2 days to gzip the tarballs.
Building the world? Oh yes. I expect that to take many months.
I'm just talking about the *kernel*.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Anders Magnusson
2014-04-13 20:07:05 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Dave McGuire
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel
on the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Probably much longer. Generating NetBSD 1.2 release took two weeks (on
an 780). 11 days to compile the system and 2 days to gzip the tarballs.

-- Ragge
Thor Lancelot Simon
2014-04-18 17:07:18 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Dave McGuire
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Probably much longer. Generating NetBSD 1.2 release took two weeks (on an
780). 11 days to compile the system and 2 days to gzip the tarballs.
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.

When we ran 4.3BSD on our VAXen there was no "gzip". There was barely
a GCC compiler at all, and it did not perform most of the optimizations
it performs today, *particularly* not the ones that consume tens or
hundreds of megabytes of memory per source file. I could go on.

The systems seemed faster in large part because we were not asking them
to do some of the very expensive tasks we ask them to do now.

In around 1991 I was responsible for a 11/750, very much on its last
legs, which handled news and email for a small academic campus, plus
some interactive login (though this had largely been replaced by labs
full of Macintoshes, and one lab of Sun workstations).

News volumes increased dramaticaly and though we had the space to store them,
we got to where we could not transfer a day's worth of Usenet news in a
day with the best modems we could buy.

So, we switched from compress(1) to squeeze(1) which implemented Miller-Wegman
compression. Now, since we were transmitting and receiving news all day long,
we could not handle the CPU load from squeeze(1) while keeping up with the TTY
data!

I did not complain that 4.3BSD had gotten slower and was a bloated pig; I
accepted that we were asking the machine to do more than it had been doing
before and that I needed to find a way to speed it up. And that there was a
going to be a practical limit to this process, which I would hit presently.

The next step was Taylor UUCP, to reduce the workload of actually moving the
data. We also bought new modems, reorganized our UUCP and Usenet feed
structure so we took different groups from different sources. Of course
this increased the workload on the kernel -- now we had to sustain high
data rates on several serial lines at the same time.

We began to look for replacement hardware, though our budget was crushingly
tight (buying four new, faster modems didn't help with that any). But while
we looked we were clearly near the tipping point. I spent my free time for
a week slicing and dicing the kernel and crucial application software into
parts that looked safe to compile with GCC -- 1.45 at the time -- and parts
that clearly did not.

Over spring break that year I rebuilt everything I could with GCC. We're
not talking about a full software distribution, and we're not talking
about GCC 4.8 with its propensity to use hundreds of megs of RAM to do
fancy new optimizations. My clear memory of this is that the kernel,
the userland binaries germane to UUCP and Usenet, and a few key libraries
(most of libc not among them) took most of the week with the compiler
running full-time. I recall very well that I went to bed one night
after launching a build of Taylor UUCP and that it had just finished
in the morning -- at least 6 hours later. Some of this was clearly
because the machine was still moving data; but not all of it (back then
Usenet volumes used to drop dramatically when colleges were on break).

Of course, I blamed 4.3BSD, because the increased workload was clearly the
operating system's fault. I also blamed GCC for taking so long to compile
the software I'd decided to try to speed up with the fancy new compiler.
That was the rational thing to do, right?

Eventualy we found a failed hedge fund that was selling off a pile
of 4/330s and picked on up as a replacement Usenet/UUCP box. It held
us another 2 years or so...

Thor
Johnny Billquist
2014-04-19 06:27:57 UTC
Permalink
Raw Message
Post by Thor Lancelot Simon
Post by Johnny Billquist
Post by Dave McGuire
Let's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Probably much longer. Generating NetBSD 1.2 release took two weeks (on an
780). 11 days to compile the system and 2 days to gzip the tarballs.
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David Brownlee
2014-04-19 15:56:01 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Thor Lancelot Simon
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.
The system now processes through all the PAM infrastructure, which
provides a bunch of additional functionality. Whether that
functionality is worthwhile is certainly a valid discussion.

It makes heavy use of shared objects, which I believe is also a
significant performance hit on current VAX.

It would be interesting to see what profiling might report for a login sequence.

The sun2 port builds with NOPIC= so everything is static linked. It
would also be nice to compare the performance for a NOPIC= build of
NetBSD/vax (I'm just started a netbsd-6 static vax build to see if it
completes, but I don't really have an ideal machine on which to test)
Thor Lancelot Simon
2014-04-19 19:26:56 UTC
Permalink
Raw Message
Post by David Brownlee
Post by Johnny Billquist
Post by Thor Lancelot Simon
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.
The system now processes through all the PAM infrastructure, which
provides a bunch of additional functionality. Whether that
functionality is worthwhile is certainly a valid discussion.
However, the simple fact that it can be turned off is not. It's just a
fact. If you want a build of NetBSD without PAM, you can make one (on
your VAX or elsewhere). If you want a build without PIC and shared
libraries -- which, actually, seems more likely to impact the Dhrystone
question we were originally discussing than anything else -- you can make
one of those, too.

You can strip away functionality piece by piece to turn the workload into
what it used to be, and then you will approach the performance you used
to get. Unless there is some fundamental problem with the kernel, which
I consider unlikely but not impossible.

A good way to figure out, though, would be to run the exact same executable
for your benchmark on a legacy operating system and on NetBSD on your VAX.

Unfortunately, DEC probably generated their Dhrystone number using VAX C
on VMS, so you can't do just what they did; but you could certainly build
a static executable in 4.3 or Ultrix and run it in both environments -- if
you can still get those operating systems to boot on your hardware.

Thor
David Brownlee
2014-04-19 20:19:45 UTC
Permalink
Raw Message
Post by Thor Lancelot Simon
Post by David Brownlee
Post by Johnny Billquist
Post by Thor Lancelot Simon
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.
The system now processes through all the PAM infrastructure, which
provides a bunch of additional functionality. Whether that
functionality is worthwhile is certainly a valid discussion.
However, the simple fact that it can be turned off is not. It's just a
fact. If you want a build of NetBSD without PAM, you can make one (on
your VAX or elsewhere). If you want a build without PIC and shared
libraries -- which, actually, seems more likely to impact the Dhrystone
question we were originally discussing than anything else -- you can make
one of those, too.
You can strip away functionality piece by piece to turn the workload into
what it used to be, and then you will approach the performance you used
to get. Unless there is some fundamental problem with the kernel, which
I consider unlikely but not impossible.
Its unfortunate the rest of my reply was stripped - I suggested
building without shared libraries, or running some profiling to
determine where time was being taken.

(Earlier I also made the suggestion timing booting an old NetBSD
install with its original kernel against a modern kernel to determine
exactly what if any difference kernel changes have made).

There have been a lot of comments regarding modern NetBSD being much
slower on slow hardware compared to older versions. Your point that
there is a lot more functionality is absolutely valid, but presented
as something of: "Thats It... Just Move On".

For someone who just wants to run a passable *nix to play with on a
slow VAX, finds the latest NetBSD too slow, the question: "So what
older version would be fast enough for me", could be perfectly
reasonable, and only takes someone with a uVAXII and some spare time
to run some timings and generate a list.

For someone who would prefer to run the latest NetBSD on a VAX and is
happy to invest some time to see if they could find a way to make it
faster for their use then the question could be more "is there a
specific feature or features which I could trade off to hit a
performance I am happy with", with a possible side order of "is there
possibly an unintentional change with a performance regression". The
latter might be an unlikely happenstance, but it doesn't hurt for
someone to have a look.

Maybe there are a set of (currently unhappy) users for whom an answer
is "build a current NetBSD with static linking and disable PAM for
'fast enough...'"

I definitely agree that that current state of recurring unhappy email
threads regarding modern NetBSD performance on VAX is helping noone.
Either people need to accept the reasons and move on (or back to a
preferred earlier version), or someone needs to try to see if there is
anything which can help in specific cases.

Either way, if someone could run some tests to find out what specific
features and or versions cost performance-wise that would help people
make informed choices

By this point I'm starting to get extremely tempted to take Dave up on
his offer of a uVAXII from the other side of the Altantic...
Toby Thain
2014-04-19 22:10:00 UTC
Permalink
Raw Message
Post by David Brownlee
...
There have been a lot of comments regarding modern NetBSD being much
slower on slow hardware compared to older versions. Your point that
there is a lot more functionality is absolutely valid, but presented
as something of: "Thats It... Just Move On".
For someone who just wants to run a passable *nix to play with on a
slow VAX,
That's why I started the thread, yes.
Post by David Brownlee
finds the latest NetBSD too slow, the question: "So what
older version would be fast enough for me", could be perfectly
reasonable, and only takes someone with a uVAXII and some spare time
to run some timings and generate a list.
I might get organised to do some comparisons on my 9MB MVII, as I wrote
earlier, it currently netboots 1.4.1 and runs that quite well.
Post by David Brownlee
...
I definitely agree that that current state of recurring unhappy email
threads regarding modern NetBSD performance on VAX is helping noone.
At the moment I don't have any fact or opinion to say that 1.5+ is not
going to work well on my MicroVAXes, I was just asking for information
from people who might have some.
Post by David Brownlee
...
--Toby
Martin Husemann
2014-04-20 07:44:28 UTC
Permalink
Raw Message
Post by Toby Thain
At the moment I don't have any fact or opinion to say that 1.5+ is not
going to work well on my MicroVAXes, I was just asking for information
from people who might have some.
I don't have any MV myself, but I tested it in SIMH when fixing bootblocks
some time ago (as well as an emulated 780).

A 5.2 release on an emulated MicroVAX 3900 takes ~6 seconds between
pressing enter after the login name untill the password: prompt
appears for the fist time. Later login attempts are faster (probably
only as long as caches last.)

Of course I have no idea how that correlates to real devices.

David: this should be a good option for you to do the timings - as long as
you keep the host system constant, statistics should be ok (relatively).

Martin
David Brownlee
2014-04-20 08:38:29 UTC
Permalink
Raw Message
Post by Martin Husemann
Post by Toby Thain
At the moment I don't have any fact or opinion to say that 1.5+ is not
going to work well on my MicroVAXes, I was just asking for information
from people who might have some.
I don't have any MV myself, but I tested it in SIMH when fixing bootblocks
some time ago (as well as an emulated 780).
A 5.2 release on an emulated MicroVAX 3900 takes ~6 seconds between
pressing enter after the login name untill the password: prompt
appears for the fist time. Later login attempts are faster (probably
only as long as caches last.)
Of course I have no idea how that correlates to real devices.
David: this should be a good option for you to do the timings - as long as
you keep the host system constant, statistics should be ok (relatively).
I had thought about using simh - timings from it would be much better
than no timings :), but it would be nice to give the absolute timings
on a real VAX (I think most people interested would find a uVAXII a
pretty ideal baseline), and there may be some artifacts (interrupt
latency, relative instruction speed for 64 bit multiply, or similar)
which only show up on real hardware.

Still, it would be much easier to repeat the tests across any
combination of os versions :)
Charles Dickman
2014-04-21 15:08:53 UTC
Permalink
Raw Message
Not a new subject, check this thread out from quite a while back.

http://thread.gmane.org/gmane.os.netbsd.ports.vax/2204/focus=2221

From: <Robertdkeys <at> aol.com>
Subject: Observations on NetBSD VAX on old machines.....
Newsgroups: gmane.os.netbsd.ports.vax
Date: 2003-03-09 04:50:15 GMT (11 years, 6 weeks, 1 day, 16 hours and
11 minutes ago)
Post by David Brownlee
Post by Martin Husemann
Post by Toby Thain
At the moment I don't have any fact or opinion to say that 1.5+ is not
going to work well on my MicroVAXes, I was just asking for information
from people who might have some.
I don't have any MV myself, but I tested it in SIMH when fixing bootblocks
some time ago (as well as an emulated 780).
A 5.2 release on an emulated MicroVAX 3900 takes ~6 seconds between
pressing enter after the login name untill the password: prompt
appears for the fist time. Later login attempts are faster (probably
only as long as caches last.)
Of course I have no idea how that correlates to real devices.
David: this should be a good option for you to do the timings - as long as
you keep the host system constant, statistics should be ok (relatively).
I had thought about using simh - timings from it would be much better
than no timings :), but it would be nice to give the absolute timings
on a real VAX (I think most people interested would find a uVAXII a
pretty ideal baseline), and there may be some artifacts (interrupt
latency, relative instruction speed for 64 bit multiply, or similar)
which only show up on real hardware.
Still, it would be much easier to repeat the tests across any
combination of os versions :)
Anders Magnusson
2014-04-20 03:20:25 UTC
Permalink
Raw Message
[about NetBSD slowniness on vax]

For someone who is curious; some time ago (about 15 years) I noticed
that NetBSD had become very slow on 11/750; unreasonable slow compared
to other machines.

I started searching and found that quite much time were spent in
hardclock. This is an effective way to make a slow machine much more
sluggish.

Here is a simple explanation for someone not a low-level hacker:

Hardclock runs each 10ms. We can say that it takes 500 instructions to
complete. On a 1 MIPS machine we will spend 10000 instructions between
each hardclock interrupt, of which 9500 will be for user programs
(~95%). On a 1GIPS machine we have 10000000 instructions, of which
9999500 will be used for processes (~99.9%).

Suddenly something is added that makes hardclock take 5000 instructions
instead. On the 1MIPS machine we now only have 50% of the CPU left, but
on the newer machine we still have 99.9% of the CPU left (== not
noticeable). Something like this can only be seen on a really slow
machine, it's most likely not possible to find it even with fine-grain
profiling on a modern PC.

Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made
the machine just as slow as before :-)

-- Ragge
Toby Thain
2014-04-20 04:37:56 UTC
Permalink
Raw Message
Post by Anders Magnusson
[about NetBSD slowniness on vax]
For someone who is curious; some time ago (about 15 years) I noticed
that NetBSD had become very slow on 11/750; unreasonable slow compared
to other machines.
I started searching and found that quite much time were spent in
hardclock. This is an effective way to make a slow machine much more
sluggish.
Hardclock runs each 10ms. We can say that it takes 500 instructions to
complete. On a 1 MIPS machine we will spend 10000 instructions between
each hardclock interrupt, of which 9500 will be for user programs
(~95%). On a 1GIPS machine we have 10000000 instructions, of which
9999500 will be used for processes (~99.9%).
Suddenly something is added that makes hardclock take 5000 instructions
instead. On the 1MIPS machine we now only have 50% of the CPU left, but
on the newer machine we still have 99.9% of the CPU left (== not
noticeable). Something like this can only be seen on a really slow
machine, it's most likely not possible to find it even with fine-grain
profiling on a modern PC.
Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made
the machine just as slow as before :-)
-- Ragge
That's a really nice analysis, thanks.

As an 11/750 owner (and other let's say "stately" VAXes), I'm interested
to know whether you found a solution? Seems like something that could be
resolved by reducing the problematic workload (shutting off those
daemons or reducing their run rate?)

--Toby
Anders Magnusson
2014-04-20 09:00:26 UTC
Permalink
Raw Message
Post by Toby Thain
Post by Anders Magnusson
[about NetBSD slowniness on vax]
For someone who is curious; some time ago (about 15 years) I noticed
that NetBSD had become very slow on 11/750; unreasonable slow compared
to other machines.
I started searching and found that quite much time were spent in
hardclock. This is an effective way to make a slow machine much more
sluggish.
Hardclock runs each 10ms. We can say that it takes 500 instructions to
complete. On a 1 MIPS machine we will spend 10000 instructions between
each hardclock interrupt, of which 9500 will be for user programs
(~95%). On a 1GIPS machine we have 10000000 instructions, of which
9999500 will be used for processes (~99.9%).
Suddenly something is added that makes hardclock take 5000 instructions
instead. On the 1MIPS machine we now only have 50% of the CPU left, but
on the newer machine we still have 99.9% of the CPU left (== not
noticeable). Something like this can only be seen on a really slow
machine, it's most likely not possible to find it even with fine-grain
profiling on a modern PC.
Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made
the machine just as slow as before :-)
-- Ragge
That's a really nice analysis, thanks.
As an 11/750 owner (and other let's say "stately" VAXes), I'm
interested to know whether you found a solution? Seems like something
that could be resolved by reducing the problematic workload (shutting
off those daemons or reducing their run rate?)
I commented out a bunch of things and removed some options just to see
that I found the problem.

But to find what is really eating CPU the hardclock codepath should be
followed and understood, there may be things that could be handled in a
different way on old slow hardware.
And as written above, this is only a problem on old slow machines, on
newer machines it is not noticed.

-- Ragge
David Brownlee
2014-04-20 08:46:26 UTC
Permalink
Raw Message
Post by Anders Magnusson
[about NetBSD slowniness on vax]
For someone who is curious; some time ago (about 15 years) I noticed that
NetBSD had become very slow on 11/750; unreasonable slow compared to other
machines.
I started searching and found that quite much time were spent in hardclock.
This is an effective way to make a slow machine much more sluggish.
Hardclock runs each 10ms. We can say that it takes 500 instructions to
complete. On a 1 MIPS machine we will spend 10000 instructions between each
hardclock interrupt, of which 9500 will be for user programs (~95%). On a
1GIPS machine we have 10000000 instructions, of which 9999500 will be used
for processes (~99.9%).
Suddenly something is added that makes hardclock take 5000 instructions
instead. On the 1MIPS machine we now only have 50% of the CPU left, but on
the newer machine we still have 99.9% of the CPU left (== not noticeable).
Something like this can only be seen on a really slow machine, it's most
likely not possible to find it even with fine-grain profiling on a modern
PC.
Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made the
machine just as slow as before :-)
Would building a kernel with a lower HZ be a quick way to test?
Anders Magnusson
2014-04-20 09:23:42 UTC
Permalink
Raw Message
Post by David Brownlee
Post by Anders Magnusson
[about NetBSD slowniness on vax]
For someone who is curious; some time ago (about 15 years) I noticed that
NetBSD had become very slow on 11/750; unreasonable slow compared to other
machines.
I started searching and found that quite much time were spent in hardclock.
This is an effective way to make a slow machine much more sluggish.
Hardclock runs each 10ms. We can say that it takes 500 instructions to
complete. On a 1 MIPS machine we will spend 10000 instructions between each
hardclock interrupt, of which 9500 will be for user programs (~95%). On a
1GIPS machine we have 10000000 instructions, of which 9999500 will be used
for processes (~99.9%).
Suddenly something is added that makes hardclock take 5000 instructions
instead. On the 1MIPS machine we now only have 50% of the CPU left, but on
the newer machine we still have 99.9% of the CPU left (== not noticeable).
Something like this can only be seen on a really slow machine, it's most
likely not possible to find it even with fine-grain profiling on a modern
PC.
Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made the
machine just as slow as before :-)
Would building a kernel with a lower HZ be a quick way to test?
That would require other changes also. Only the big VAXen has an
adjustable clock interval (which is hardcoded to 10ms), microvax has a
fixed 10ms clock interval. But adding some assembler in
intvec.S:hardclock that only takes each fifth interrupt would be doable
just to test, yes.

Another thing to be noted is that calls on vax might be quite slow, a
vague memory tells me that average it takes about 10us for one calls
(depending on how many regs to be saved). So if hardclock code path
contains many calls it will affect the execution speed unreasonably much.

-- Ragge
David Brownlee
2014-04-20 14:27:06 UTC
Permalink
Raw Message
Post by David Brownlee
Post by Anders Magnusson
Post by Anders Magnusson
[about NetBSD slowniness on vax]
Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock. Just commenting out this made
the machine just as slow as before :-)
Would building a kernel with a lower HZ be a quick way to test?
That would require other changes also. Only the big VAXen has an adjustable
clock interval (which is hardcoded to 10ms), microvax has a fixed 10ms clock
interval. But adding some assembler in intvec.S:hardclock that only takes
each fifth interrupt would be doable just to test, yes.
If it worked it could even be ifdefed to allow HZ to be set to
divisors of 100...
Another thing to be noted is that calls on vax might be quite slow, a vague
memory tells me that average it takes about 10us for one calls (depending on
how many regs to be saved). So if hardclock code path contains many calls
it will affect the execution speed unreasonably much.
Presumably on vax its calling out to statclock() and schedclock() as well as
callout_hardclock() each tick. I know a lot of counters have moved
from 32bit to 64bit since early NetBSD which might also have affected
things...

It looks like there is definitely enough possibilities for someone
with the time and right machines to investigate.

I'd be very happy to contribute beer money ($100) towards someone
looking into this, and/or help pay to get a machine to someone who is
interested but doesn't have the right kit. Would anyone else be
interested in putting into a pot (or drinking the pot :)

David
Dave McGuire
2014-04-23 23:40:20 UTC
Permalink
Raw Message
Post by David Brownlee
Post by Johnny Billquist
Post by Thor Lancelot Simon
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.
The system now processes through all the PAM infrastructure, which
provides a bunch of additional functionality. Whether that
functionality is worthwhile is certainly a valid discussion.
[sorry, I fell behind on email due to a trip]

If the PAM infrastructure is so poorly-written as to incur THAT much
overhead, then I consider that in itself to be a bug. I realize that it
brings a great deal of functionality to the table, but man, at some
point one just has to admit that something is "overdone". PAM
definitely falls into that category as far as I'm concerned.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
David Brownlee
2014-04-24 07:51:32 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by David Brownlee
Post by Johnny Billquist
Post by Thor Lancelot Simon
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
Ayup. 30 seconds from entering username until I get a password prompt is
clearly asking the system to do much more today than in the past, so
obviously it is just as expected, and nothing to even talk about.
The system now processes through all the PAM infrastructure, which
provides a bunch of additional functionality. Whether that
functionality is worthwhile is certainly a valid discussion.
[sorry, I fell behind on email due to a trip]
If the PAM infrastructure is so poorly-written as to incur THAT much
overhead, then I consider that in itself to be a bug. I realize that it
brings a great deal of functionality to the table, but man, at some
point one just has to admit that something is "overdone". PAM
definitely falls into that category as far as I'm concerned.
Lets find out - is there anyone with a slow vax interested in timing
login on a normal vs MKPAM=no system? I'm happy to build a MKPAM=no
for a specified version if it helps. If not I can do it under simh,
but the numbers will be less useful...

Dave McGuire
2014-04-13 20:24:34 UTC
Permalink
Raw Message
You guys inspire me to be a better VAX owner.
Step 1: Wire up a serial cable from MVII console port to COMM on this
VT320.
Cool! Get that done yet?

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Johnny Billquist
2014-04-13 20:30:43 UTC
Permalink
Raw Message
Post by Dave McGuire
You guys inspire me to be a better VAX owner.
Step 1: Wire up a serial cable from MVII console port to COMM on this
VT320.
Cool! Get that done yet?
That is a really simple task:
DE9 - DB25

2 - 3
3 - 2
7 - 7

Done.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
emanuel stiebler
2014-04-13 18:32:49 UTC
Permalink
Raw Message
Post by Dave McGuire
I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work.
I know how that goes. Paying bills :(

Anyway, I wanted to finally go back to the graphics on the 4000/90,
but only managed it to a point of having a build able system.
And some head scratching about the wscon ;-)
Post by Dave McGuire
I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!)
Please, don't tell me you it really is a PAIR?
Post by Dave McGuire
and plan to do much
NetBSD/vax hacking in the not too distant future.
Same here ...

Cheers
Toby Thain
2014-04-13 19:43:08 UTC
Permalink
Raw Message
Post by Dave McGuire
Post by emanuel stiebler
Just a "thanks" to all the people, who still keep this port working.
I actually managed it to build a KERNEL & DISTRIBUTION
on a VAX.
Thanks again!
Seconded. I'm not doing much with it just lately, but I did a few
months ago, and then things got busy with work. I've gotten a gaggle of
new VAXen here (including a pair of VAX-11/785s!) and plan to do much
NetBSD/vax hacking in the not too distant future.
Let's keep this port alive!
Activity on this list!

You guys inspire me to be a better VAX owner.

Step 1: Wire up a serial cable from MVII console port to COMM on this
VT320.

--T
Post by Dave McGuire
-Dave
Loading...