I have expienced similar problems... I am 13 hops away from
uc.cache.nlanr.net and have an average ping of about 100 mS or so. I am
only 6 hops away from my nearest parent, and I have problems with this one
too. I think the problem is that Squid isn't very tolerant of packet loss
but I can't be sure. I have found that enabling the ICMP pinging stuff
helps a lot, but my two nearest caches don't run it and thus aren't
queried very often.
Is there a way to use multicast for Squid without having a multicast-aware
path all the way to the other squids? Occasionally the delay from squid
can be severe enough that uses have actually noticed that direct connects
are faster (fortunatly Squid is usually faster than a direct connect). I
would like to continue to use the hierarchy but it is difficult to justify
when it results in a performance reduction during times of peak use...
-Bill kb8wyp
On Fri, 29 Aug 1997, Daniel Schroder wrote:
>
>
> I've been following this thread.
> We have a problem that when we use parents ,
> the delays become excessive. I've tried a
> multitude of configurations , and come tot the
> the conclusion because we so far away from
> nlanr.net , it is just not viable to parent
> because I suspect that packets are getting lost.
>
> The timeout is set to one second , and I find the
> only way to get a quick response is to simply
> turn off all the parents , and use them as siblings.
>
> Thats why I feel multicasting the solution. As I see
> it , one host is pinged , and one replies , and if that
> does not happen quick enough , the object is fetched directly.
> It seems that the more parents one has , the longer the delay is
> before a objects is delivered , and I'm worried about the time
> difference (Average of 500-600 Ms). Also , I'm reluctant to
> just set up a whole wack of siblings , it seems almost messy.
>
> I've experimented with parent rules , but it takes too much time
> to sit and tweak the whole day. I prefer the one ping , and the closest
> parent replies , or only one parent relies.
>
> Now , I've recompiled a kernel with multicast and Tunneling support
> and what I need to know is , how does one know that nlanr.mcast.ircache.net
> is 1.) Receiving 2.) Replying.
> Unfortanety I don't have the luxury of spending time sorting it out
> (Boss has a list off todos as long as my arm) , but a pointer as to what
> to look for would be appreciated.
> Squid 1.1.16 Linux Redhat4.2 Kernel 2.0.30 64 meg.
>
> --Daniel Schroder
> Networld
> http://livewire.new.co.za (F) 419 3212
> mailto:daniel@new.co.za (T) 419 4430
>
> On Thu, 28 Aug 1997, Duane Wessels wrote:
>
> > srainey@rmplc.net writes:
> >
> > >I have 7 Squid caches running under BSDI 2.10 and all on the same IP
> > >subnet. I wish to configure them as siblings and it seems reasonable to set
> > >up a local multicast network. However, after a couple of hours surfing the
> > >web I'm not much nearer being able to set this up.
> > >
> > >Multicast support is built into the kernel, but do I need to use mrouted if
> > >I'm not routing traffic beyond my local subnet? Can I choose any address
> > >from the 224.0.0.0/4 block given that I'm not routing this network, or is
> > >there a block for private multicast networks (is that what 224.0.0.0/24 is
> > >for)?
> >
> > You don't need mrouted if all machines are on the same subnet. Since
> > mrouted is not running (and if mcast is not enabled in your routers)
> > you should be able to use any address at all.
> >
> > >I've tried setting up rm-ps-squid-multicast.rmplc.co.uk to be 224.0.0.1 and
> > >then using this in squid.conf (on the host rooster) ...
> > >
> > >mcast_groups 224.0.0.1
> > >
> > >cache_host rm-ps-squid-multicast.rmplc.co.uk multicast 8080 3130 ttl=64
> > >cache_host adder.rmplc.co.uk sibling 8080 3130 multicast-responder
> > >cache_host rattle.rmplc.co.uk sibling 8080 3130 multicast-responder
> > >cache_host barracuda.rmplc.co.uk sibling 8080 3130 multicast-responder
> > >cache_host elk.rmplc.co.uk sibling 8080 3130 multicast-responder
> > >cache_host whale.rmplc.co.uk sibling 8080 3130 multicast-responder
> > >cache_host eagle.rmplc.co.uk sibling 8080 3130 multicast-responder
> >
> >
> > Hm, there might be something special about 224.0.0/24, but I'm not sure.
> >
> > Feel free to use local.mcast.ircache.net (224.0.14.33) if you can
> > guarantee that your packets won't leave your net/org.
> >
> > >I've also added a route ....
> > >
> > >route add -net 224.0.0.0 -netmask 240.0.0.0 -interface 194.238.50.8
> > >
> > >where 194.238.50.8 is the IP address of the single ethernet port in the
> > >server.
> > >
> > >I've also tried using 224.0.0.2 with no luck.
> > >
> > >If I ping 224.0.0.1 I get responses from all the other hosts, but Squid
> > >just doesn't seem to be responding to multicast requests.
> >
> > tcpdump?
> >
> > Duane W.
> >
>
Received on Sat Aug 30 1997 - 11:58:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:36:52 MST