Re: NetBSD/vax current

[David Brownlee <abs%netbsd.org@localhost>]

On 19 April 2014 20:26, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> On Sat, Apr 19, 2014 at 04:56:01PM +0100, David Brownlee wrote:
>> On 19 April 2014 07:27, Johnny Billquist <bqt%update.uu.se@localhost> wrote:
>> > On 2014-04-18 19:07, Thor Lancelot Simon wrote:
>> >> 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...