🚀 go-pugleaf

<brydon@dsny25.sinet.slb.com> writes:

>(2) Yes it takes ethernet processing, but even on a slow VMS system, this will
>be on the order of a few microseconds.  Okay, say it is 100 microseconds.  One
>millisecond of disk controller latency (or any other delay) is 1000
>microseconds.  Access times on disks are typically 20000 to 50000 microseconds
>(remember the difference between 'average access time' and 'maximum access
>time' and 'typical access time').
>
>(3) In many cases, the hardware technology on the boot node is much better
>(eg. faster) than that on the satellite node.  This goes back to the birth of
>the technology with 45 msec RD53/RD54s on VAXstation 2000's and 25 msec DSA
>drives on an 86xx boot node.  Assume 1 millisecond for ethernet overhead and
>processing.  With this configuration, 25 + 1 is much less than 45.  The access
>time numbers for boot nodes versus satellites is getting closer but a
>difference (based on technology) still seems to be the case.

"In many cases."  Yes, this is true.  However, when I was conducting my tests
our boot node was a 3600 with an RA81.  The satellites were VSIIs using RD54s
(and occasionally a lonely VS2000 with an RD53 stuffed in).  Our tests still
showed that the diskless satellites were slower.  This may change with the
newer disks (esp the HP2247 with 9ms access time!), but I think it's still
better to test rather than rely on theory, which is what you're doing in (3)
above.  Adding up the milliseconds is fine, but you've missed some bits.
Try this:

Local delays                           Remote delays
-----------------------------------------------------------------
QIO to controller                      QIO thru cluster s/w
disk latency, seek, etc                assemble ethernet packet
process polling by VMS                 transmit packet to server
QIO returned from disk                 disassembly of packet by server
process polling by VMS                 QIO to server disk
return to calling process              disk latency, seek, etc.
                                       process polling by VMS
                                       QIO returned from disk
                                       assemble ethernet packet
                                       even more process polling
                                       transmit ethernet packet to satellite
                                       [potential delays on the wire...]
                                       satellite disassembles ethernet packet
                                       yet more process polling
                                       return to calling process

Some of my steps and nomenclature may be debatable (I'm trying to illustrate
the difference in number of steps, not teach how it's done) but my point is
fairly clear.  In the case of the local disk you're relying only on the h/w
and local VMS overhead.  With LAVC traffic, there are many additional steps
required to perform the same task.  With only one or two satellites there
won't be too much delay at the server (but still an appreciable amount, esp.
if the server isn't just doing disk accesses), but as the number of satellites
grows, so does resource contention.

Sure, there will be case-by-case variations (like the example of an RF35-
equipped server talking to RD-based satellites), but overall I still think
it's better to keep as much processing as possible local to the satellite.
Disks are cheap, overall.  Performance tuning on systems that have gone to
production work is more expensive, IMHO, in lost time and user frustration.

Polemic ended...hopefully helpful!

--------------------------------------------------------------------------------
Dick Joltes						joltes@husc.harvard.edu
Hardware & Networking Manager, Computer Services 	joltes@husc.bitnet 
Harvard University Science Center

"Mind you, not as bad as the night Archie Pettigrew ate some
sheep's testicles for a bet...God, that bloody sheep kicked him..."