From owner-freebsd-current Mon Mar 12 21:59:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 26BB037B719 for ; Mon, 12 Mar 2001 21:59:23 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f2D5wnf94700; Tue, 13 Mar 2001 07:58:53 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200103130558.f2D5wnf94700@gratis.grondar.za> To: Matt Dillon Cc: "David Schwartz" , current@FreeBSD.ORG Subject: Re: Ethernet entropy harvesting seriously pessimizes performance References: <200103122231.f2CMVaL75959@earth.backplane.com> In-Reply-To: <200103122231.f2CMVaL75959@earth.backplane.com> ; from Matt Dillon "Mon, 12 Mar 2001 14:31:36 PST." Date: Tue, 13 Mar 2001 07:59:43 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Let me be clear about what I mean by interrupt rate limiting: > > interrupt() > { > harvester(...) > } It does that already. > harvester(...) > { > if (queue is not full) { > ... add data to queue (reasonably sized queue, like 32 entries) > } > } It does that. I guess we differ on the idea of "reasonable". > queue-runner(...) > { > for(;;) { > sleep for 1/10 second > > Pull next item (if any) off queue > } > } It almost does that, except it sleeps every N items where the user is given control of N. > That is what my patch does. If a high rate of interrupts occur, the > queue becomes full almost instantly because the queue-runner only > pulls one item off per 1/10 second. The result is that the > harvester() routine effectively becomes a NOP for most of the > interrupts. My code does that. Do a "cat /dev/zero > /dev/random" to see it in action. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message