NetBSD Bob wrote:
> >
> > NetBSD 1.0A (GENERIC) #165: Mon Dec 11 23:54:20  1995
> >
> > ttcp-t: 16777216 bytes in 109.57 real seconds = 149.53 KB/sec +++
> > ttcp-r: 16777216 bytes in 143.16 real seconds = 114.44 KB/sec +++
> 
> Where can I get a load of the 1.0A or 1.1B for the VAX?
> I have not seen that anywhere.  I would like to try those for
> comparisons, too, and keep a set around for historical reasons.

I happened to have a snapshot release of 1.0A stashed on an old account
archive of mine, and the 1.1B just happened to be where I'd left this
particular uVAX-II when I stopped having time to do development work.

But I thought it worth testing them as more sample points seem better.

Maybe it would be better to solicit official release copies?  I just
didn't have any around that I could find quickly.

> > NetBSD 1.3.2 (GENERIC) #0: Sat May 30 12:55:49 CEST 1998
> >
> > ttcp-t: 16777216 bytes in  56.15 real seconds = 291.81 KB/sec +++
> > ttcp-r: 16777216 bytes in  84.57 real seconds = 193.72 KB/sec +++

    NetBSD 1.4.2 (GENERIC) #3: Fri Mar 17 01:10:11 PST 2000

    ttcp-t: 16777216 bytes in  53.53 real seconds = 306.06 KB/sec +++
    ttcp-r: 16777216 bytes in  68.31 real seconds = 239.83 KB/sec +++

> > NetBSD 1.5_BETA (GENERIC) #0: Sun Oct 22 19:31:24 PDT 2000
> >
> > ttcp-t: 16777216 bytes in  87.45 real seconds = 187.36 KB/sec +++
> > ttcp-r: 16777216 bytes in 102.36 real seconds = 160.07 KB/sec +++
> 
> This is just about what I was getting, it would seem.  That is
> about a 35 percent slowdown difference roughly between 1.3.2 and 1.5?

Why did you drop the 1.4.x release data?  I'm confused why you didn't
instead compare 1.4.2 with 1.5_BETA?  The 1.4.2 release seemed to
continue a trend of improved performance, and in fact demonstrated
the best performance I encountered while testing.

> The CPU data all looks pretty good and even, especially after 1.3.2.

I try not to pay too much attention to the CPU times - I've found that
all the data is suspect and timing seems to be, like device statistics
(e.g. "netstat -in" with qe0 had no packet data values) often less than
solid.  The numbers for getc() looked realistic, but I'm surprised how
high the block times were.  Ah well.

> What is the exact card ordering in your machine?  I noticed some
> difference in swapping ethernet/tape/disk around, but I need to
> fiddle with that some more.

Well, a uVAX-II is a uVAX-II.  A 0.9 VUP machine.  Slow.  About all
I can offer is to say from my past recollections that DEC always advised
putting the DEQNA as close to the CPU as possible.

In your case, I'd not give a hoot about where the DHV lives as long
as you place it properly to provide grant continuity, driving a printer
is not exactly major stuff.  Presuming you're not planning to print
24 hours a day 8-)

While disk controllers, or at least the third-party kind, I think tend
to have sufficient buffering capability to survive longer interrupt
processing latencies.

Evil cards like the DJV which can totally overwhelm a CPU with interrupts
are best kept for entertainment sake 8-)  You'll want a PDP-11 CPU for
one of those as it actually has a very fine reputation for handling
the interrupts in a "timely fashion." 8-)

Cheers,

-- Ken