[comp.mail.uucp] Pathalias benchmarks, and more rerouting arguments

vixie@decwrl.dec.com (Paul Vixie) (10/19/88)

I've always thought that pathalias would make a good all-around CPU-bound
benchmark for a compiler and computer system.  Goodenough is running on a
10MHz 68020; I'm running on a DEC Titan (14 Vax MIPS, and no, it never was
a product)...

In article <295@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes:
# Let's look at a script:
# 
# lakart!dg(work/lk/src)[61]-> cat /usr/lib/uucp/uumap/[ud].* | wc
#   109269  426979 2783156

bacchus 177 #cat [ud].* | wc
   88809  359334 2341301

Hmmm.  I wonder what I'm missing this time -- I grabbed the latest uumap.tar.Z
from uunet before I installed my comp.mail.maps unpacker; I should have it all.
Okay, so I'm starting with ~442K less data.

# lakart!dg(work/lk/src)[62]-> wc /usr/lib/uucp/uumap/UUPATH
#    16147   32294  840512 /usr/lib/uucp/uumap/UUPATH

bacchus 180 #wc paths
   15036   30072  611023 paths

# lakart!dg(work/lk/src)[65]-> time /usr/local/dopath
# 245.9u 43.7s 7:22 65% 3+79k 1775+2268io 6pf+1w

bacchus 181 #(pathalias path.local glue.local [du].* | lcasep | sort > paths)
25.4u 4.7s 1:22 36% 320+3084k 568+314io 0pf+0w

It looks like the DEC Titan does its IO in bigger chunks, as well as being
about 10X faster.  I sure wish they'd sold this machine to the public when
it was new -- three years ago.  Might've made quite a splash.  But then that
was before RISC was "in".

(Note that I am not speaking as a DEC employee, am not a company spokesman,
etc, etc, etc.  Don't quote the above without quoting this as well.)

Anybody else?  Somebody with a MIPSco box, maybe?  Or an Pyramid?

Oh no -- it's the R e r o u t i n g discussion again.  Here we go some more:

# However on the subject of routing I would ask the following: when you drop a
# letter in a mailbox, you just put the address on it. You don't really give a
# wet slap how the Post Office gets it there, as long as it arrives.  Hence,
# by all means provide a bang path, but what is the paranoia about someone
# else looking at and saying "I know a better way". As long as your letter
# gets there what do you care?

When I have an address, I use one.  I'll gladly send to a domainized address,
which is analagous to your "post office" example -- it's unambiguous and as
with the post office I do not really care how it gets there.

That's if we're talking about an A d d r e s s.  Addresses aren't routes.
Some people are not reachable with a nice, unambiguous route.  Some people
are on a moldy machine in a wet basement that is completely unknown to the
UUCP map.  I want to be able to send mail to these people, too.  Telling me
I have to get them registered before I can send them mail will _not_ win you
any brownie points.

Then there's the occasional case where I know that the official route will
work but take longer.  Or I know of a temporary wormhole.  Or I know of a
secret connection.  In none of these cases will the UUCP map or any 
rerouting program know a darned thing about the routes I want to use.
Telling me I have to inform the UUCP Project of every connection I use
will not go over well.  I might even start yelling again.

Then there's AT&T.  They recently published a completely bogus map entry
in that it showed lots of juicy connections to sites they were not willing 
to forward mail to.  The active rerouters on the net sent several of my
mail messages that'a'way, while I had instructed my "glue.local" file that
site "att" was dead and should be avoided.  Telling me that I have to trust
the UUCP project and all active rerouters to avoid or deprecate all the same
hosts and links I do will be met with a long, resigned sigh.

In answer, though: why do active rerouters care?  If I want someone to pick
a route for me, I'll send them a partial route: something like
		pyramid!ubvax!crash!bblue
Now, I know that ubvax doesn't talk to crash.  But I also know that ubvax
will see this non-local next-hop and find a route to it.

All very nice.  Works fine.  I get what I expect.  Never "more".
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013