> Fixing the router is not about correting this issue, but correcting
> the fact that this issue causes your router to crash and require a
> reboot to recover.
Ofcourse. But I am afraid, that my router CPU is to slow to cope with
such packet storm anyway. I will do the best I can with it, but let
us focus on Squid delay pools.
> Delay pools are not supposed to give storms of small packets. Instead
> they are supposed to give delayed larger packets up to te byte rate
> specified in the pool.
Thanks for clarification. I expected this reasonal behavior.
And Squid seems to behave like this until initial delay-pool is
depleted.
> > 2. It is mis-configuration in my config?
> Not likely.
I'll try to do it with bare config - only basic acl and 1 delay
pool. Maybe default config is OK. If there will be any new evidence,
I'll post it.
> It may be a NT port issue, or maybe a generic Squid-2.5.STABLE3 issue.
> I do not know which yet. Bug #670 seems to suggest it is a generic
> Squid-2.5.STABLE3 issue if the cause is the same, but Bug #670 is
> less verbose on the detailed symptoms so I do not know.
#670 is not specific enough to match my case. Once again:
All is OK - client loads page slowed-down to desired rate, page
is complete, everything is OK, except small-packets storm instead
of fewer big.
> A quick test on Linux seems to indicate delay pools works like
> expected however. Created a class 1 pool with parameter 1000/1000,
> and I have a single 1000 byte packets sent to the client once per
> second.
I believe that. I would go for Linux, but its HW in my case
is too limited.
> I think your problem is probably different from that of Bug #670.
I presume the same. It is a pity, I do not have direct debugging
tools to pinpoint problem myself. Hope I provided enought clues to do
this "on your side".
------------------------------------------
The last one for today: should I end my posting to mailing list
and open new bug in Bugzilla instead? Or maybe you have added to
"to do" list already?
Thanks again.
