Hi, > There is an open bug report about issues with delay pools, claiming > that delay pools is not working at all in 2.5.STABLE3 IIRC. I have
I've looked for it in squid-cache.org Bugzilla database, but unable to find anything related to IRC and delay pools. Closest match I think is, but nothing like my case: http://www.squid-cache.org/bugs/show_bug.cgi?id=670 > not yet had time to evaluate this report. Please check if this is > consistent with what you are seeing on SquidNT, if not open a new > report. I'll do it, if you kindly explain my thoughs in the end of the letter. > As your router is broken and crashes on this kind of traffic, please > conduct testing of the delay pools feature from another equipment not > using that router. I've tested delay pools on direct connection SquidServer<>Client (only fast swicth between, no router) - client is able to get page, but trafic is the same - very high number of 1 byte packets. Client machine - P4 @ 2.4 Ghz, 512 RAM, 100 Mbps 3COM NIC. Server - much the same HW. Result - CPU usage when using delay pools peaks from 30% to average 80-90%. rate measured with snifer - ~20000 packets/sec. In such case I do not wonder why my small router is out of CPU power to survive! > Trust me, the router bug should be fixed. Not fixing the router issue > is asking for trouble later. I understand that clearly. The problem is that fixing the router this time is the harder way to go, because it is a part of infrastructure, while Squid as of today - is not. > This is kind of the same question if a NT server should bluescreen if > it receives a certain malformed packet from the network. Sure, in a > perfect world it should not receive such packets in the first place, > but it sure should not bluescreen if it does.. Agree again. But while network is under my supervision it is a little perfect world, where no one knows, what DoS is :) Until Squid ofcourse was installed :) ------------------------------------------ Ok, here is my letter, I have written to Serassio Guido, developer and supervisor of SquidNT project (all quited text): > Ok, I am not Squid or delay-pools expert, but what I see with >snifer, seems to me strange behavior of Squid: > >1. On request of web page, which is belongs to delay pool, a client computer >in the beginning gets only a few quite big packets - from ~100 to ~1500 bytes >each. > >2. This lasts presumably until client computer depletes his initial pool. > >3. After this the stream of 1 byte packets is send, making it atleast ~1000-5000 >packets/second, (depending on delay pool restore speed? I think). >- this is delay pool throtling in use. > >4. After page load is almost finished and there is no constant demand >of download, Squid behavior of packets restores to the one mentioned in 1 >step. > > What I do not understand from software design point of view what is >the difference between 5000 packets/sec with only 1 byte of meaningful payload >and 5/sec packets with 1000 bytes worth of data each? The difference for the >end-user or client is the same. > > Is this usual/default Squid behavior? Can anything be done to make >it send >fewer, but larger packets when using delay pools? > > Should I post this question also to the squid-users mailing list? So, now I wonder, if: 1. My case is usual Squid behaivior. A. If so - can it be changed to send larger, but fewer delayed packets? 2. It is mis-configuration in my config? 3. Squid NT port is broken / mis-implemented in some way. Thank you again for support!
