In message <3.0.5.32.19980620171842.00936be0&#167;alpha.ah.net>, Adam Todd writes:
>Funny, I don't know too many people that actually use the majority of these
>caching servers.  Most people do at first but they get slow and painful.
>Anyway Rick doesn't use ANY CACHING SERVER!  All his users use his sole
>server!

there you go again -- speaking for 'most people' again.  you _personally_
know the 150K+ Big Pond Home customers, and the 150K+ OzEMail customers?
of course you do ...

i'd say that 'most people' don't actually know what those entries called
'primary nameserver' and 'secondary nameserver' actually mean.
in fact, i'd say that "most people" just leave it set at whatever the CD
they used to install their provider's software.  (and any provider who knows
a thing or two will be setting the customer's settings using rfc1877).

>There you go again.  Limited with the amount of knowledge you have.
..

here we are again, limited to personal attacks.
i guess discussing some of the facts (australian take-up of AURSC) hurts.

>>located off two (seemingly not-particularly-well-connected) links?
>
>Now that's a worry.  I guess the same reason you use the "seemingly
>not-particularly-well-connected) telstra caching servers.
>
>Oh or are they suddenly well connected, and if so, why is there a difference?

i don't use telstra internet's caching nameserver 'uneeda.telstra.net' for
other reasons, however i do use those referenced in 
ftp://ftp.rs.internic.net/domain/named.root

as far as talking about YOUR seemingly-not-particularly-well-connected
nameservers, one word sums it up: "bandwidth" (or should i say, lack-of-it).

>Your telling me Telstra are not delivering the service they are contracted
>to.  Well this I'd like to see.  Please - yet again - put up the "losss"
>stats you seem so proud of.

you seem to be proud about your network knowledge.  Q & A time:

Q. what are the 3 properties that can cause delay?
A. 1 propogation delay (speed-of-light thing, distance-dependant, cannot be 
     changed).
   2 switching delay (minimal)
   3 queueing delay (where the amount of packets to be sent out an interface
     exceeds that interface's ability to send them)

   you seem to be getting #3.  i wonder why?

Q. what is the primary cause of packet loss?
A. when the number of packets queued on an interface reaches a predetermined
   threshold, additional packets are dropped.

   you seem to be getting this too . . .

what can one do, when you're experiencing queueing delay / packet loss?
well, you can try some other queueing strategies, but these won't really help
you much with the loss -- main solution is to 'add more bandwidth'.

go figure.

cheers,

lincoln.

NB. this is now getting pointless.  maybe you'll claim that you've won, if
only because i tire of reading this stuff.  however, any way you look at it,
the takeup of AURSC seems extremely minimal.