https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6075
--- Comment #29 from AXB <[email protected]> 2009-03-03 22:24:55 PST --- (In reply to comment #28) > > No problem, and in fact thanks for sticking with it this long. i'm very > > happy > > to have documented in the record these difficult to debug problems that > > could > > arise from a high speed connection throttled by a lower speed upstream, or > > by > > high rate UDP getting throttled by a Zyxel or similarly performing router. > > I wonder how common this problem is. Thanks to Elsa for perseverance! > How many SOHO users of SpamAssassin suffer from this without knowing? Please note : This has been noticed/debugged in a SOHO setup with unusually high traffic (+80 simultaneous SMTP sessions) doing inline scanning and not using sequential lookups as would happen with a MDA. (specifically: spam trap boxes) Hardware was +5 year old and not ready for today's high speed connections. Updated hardware does not show this effect. In one case, where a custoemr was affected, reporting to Zyxel, resulted in a firmware update which corrected the issue. > It might be possible to implement application-level traffic shaping > (leaky bucket or token bucket algorithm) for taming UDP storms. > The main problem seems to be lack of fine granularity in tasks of SA > (and the absence of fine granularity interrupts in Perl). Something > like a 10 ms scheduling event would do for the purpose, and could also > help with more prompt harvesting of responses (Bug 5589 comment 7). > A Bug 6060 calls for shorter chunks of noninterrupted grinding too. > Just thinking aloud... IMO, adding throttling won't fix the issue as timeframes may vary in such a wide way that it would only make debugging harder. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
