Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!cmcl2!husc6!purdue!decwrl!vixie From: vixie@decwrl.dec.com (Paul Vixie) Newsgroups: comp.mail.uucp Subject: Pathalias benchmarks, and more rerouting arguments Message-ID: <11@gnome6.pa.dec.com> Date: 19 Oct 88 11:11:19 GMT References: <2947@uoregon.uoregon.edu> <295@lakart.UUCP> Organization: DEC Western Research Lab Lines: 86 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