"Matthew N. Dodd" wrote:
On Mon, 12 Mar 2001, Mark Murray wrote:
Lots of security minded people what _all_ the interrupt entropy
they can get, and this method gives them that while allowing others
to throttle the harvester back.
Lots of -CURRENT users want to be able to use their
Paul Richards wrote:
"Matthew N. Dodd" wrote:
On Mon, 12 Mar 2001, Mark Murray wrote:
Lots of security minded people what _all_ the interrupt entropy
they can get, and this method gives them that while allowing others
to throttle the harvester back.
Lots of -CURRENT users want
Hi,
In addition to reported earlier general machine slowdown with interrupt
harvesting is turning on, ethernet entropy harvesting seriously hammers network
performance as well. Ftping big file over my 10M network now about 15% slower
with ethernet harvesting turning on.
Mark, please get slow
In addition to reported earlier general machine slowdown with
interrupt harvesting is turning on, ethernet entropy harvesting
seriously hammers network performance as well. Ftping big file over my
10M network now about 15% slower with ethernet harvesting turning on.
Even with the Rijndael
Mark Murray wrote:
In addition to reported earlier general machine slowdown with
interrupt harvesting is turning on, ethernet entropy harvesting
seriously hammers network performance as well. Ftping big file over my
10M network now about 15% slower with ethernet harvesting turning on.
Maxim Sobolev wrote:
Mark Murray wrote:
In addition to reported earlier general machine slowdown with
interrupt harvesting is turning on, ethernet entropy harvesting
seriously hammers network performance as well. Ftping big file over my
10M network now about 15% slower with
On Mon, 12 Mar 2001, Mark Murray wrote:
In addition to reported earlier general machine slowdown with
interrupt harvesting is turning on, ethernet entropy harvesting
seriously hammers network performance as well. Ftping big file over my
10M network now about 15% slower with ethernet
Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ??
Rijndael stops it showing up much in top -S. I'm wondering where it is
hiding :-). kern.random.sys.burst=$SMALLNUMBER had very little effect.
The Rijndael code makes a 2-orders-of-magnitude difference to the speed
of
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
-Matt
Index: yarrow.c
Sorry, the last patch won't patch cleanly, I forget to update my
-current source before diffing. A new patch is attached, and it
also includes reducing the sdize of the entropy ring from 1024 to a
more reasonable 64.
Mark, what I said last month still holds... you need to
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
Erm, you are behind :-)
I have already committed something that does this in a
:
: Please try this patch. This should solve all the random harvesting
: performance issues no matter how efficient or inefficient the hash
: function (untested as I do not have a -current box at the moment).
:
:Erm, you are behind :-)
:
:I have already committed something that does
Mark, something like this doesn't REQUIRE any configuration!!! Don't
add confusion to the system. Just make the default something
reasonable. There is absolutely no reason to have to be able to adjust
the interrupt seeding code if the default is made something reasonable.
:Matt,
:
:At it is very obvious to me that you have not even looked at the new
:code, let alone run it, I suggest that you do both before further
:engaging in this conversation.
:
:M
:--
:Mark Murray
:Warning: this .sig is umop ap!sdn
I looked at it. I'm sorry, I don't see how your
I don't understand what is so difficult about simply rate-limiting
the code at the proper point -- at the very beginning of the
call that the interrupt harvester makes, removing most of the fixed
overhead for the case where a system is getting a large number of
: down and will work, SNAP, just like that?
:
:Because I need to make folks other than you happy.
:
:Lots of security minded people what _all_ the interrupt entropy
:they can get, and this method gives them that while allowing others
:to throttle the harvester back.
:
:M
:--
:Mark Murray
On Mon, 12 Mar 2001, Mark Murray wrote:
Lots of security minded people what _all_ the interrupt entropy
they can get, and this method gives them that while allowing others
to throttle the harvester back.
Lots of -CURRENT users want to be able to use their systems to write code
without
I mostly agree with this, but let's also remember that this is -CURRENT too
and that Kris Mark others have been pretty good about feeling sorry for
you when you get hung up... ahem- responding to and fixing issues :-)
On Mon, 12 Mar 2001, Matthew N. Dodd wrote:
On Mon, 12 Mar 2001,
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
19 matches
Mail list logo
