Re: Ethernet entropy harvesting seriously pessimizes performance
"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 systems to write code without tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. Well, I dunno about that. It dovetails into the thread in developers about getting people to use FreeBSD for research and to my mind I think -current probably is a legitimate place for research. As long as the basic -current doctrine of not commiting totally non-functional code is adhered to there's no reason why experimental code can't be tried out in -current. If you don't like the problems that research cause you then -current isn't what you should be running -- it's an old mantra that isn't repeated enough these days. Of course, I'd much prefer it if -current wasn't totally hosed as much as it has been recently but random hasn't caused half the turmoil that some other changes have so it's unfair to pick on it as a major problem. I think Peter gets the award for causing most downtime in -current recently, which is quite a feat given the SMP work taking place :-) Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 to be able to use their systems to write code without tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. Well, I dunno about that. It dovetails into the thread in developers about getting people to use FreeBSD for research and to my mind I think -current probably is a legitimate place for research. As long as the basic -current doctrine of not commiting totally non-functional code is adhered to there's no reason why experimental code can't be tried out in -current. You are missed point here. Doing research using FreeBSD is not the same as committing poorly designed and untested code into it, completely replacing previous satisfactory in the most cases subsystem. Developers usually can tolerate disturbances when some major redesign occurs, that in the long run would benefit the whole community (e.g. SMPng), but not the constant problems with not so important and hardly critical for 95% of users component as random number generator is. If you don't like the problems that research cause you then -current isn't what you should be running -- it's an old mantra that isn't repeated enough these days. Most developers just have to use 5-current, because it is their development and reference platform. Of course, I'd much prefer it if -current wasn't totally hosed as much as it has been recently but random hasn't caused half the turmoil that some other changes have so it's unfair to pick on it as a major problem. Saying "this is bad, but that was much worse" could not be an excuse for not doing it properly. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Ethernet entropy harvesting seriously pessimizes performance
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 machine (say 100MHz or slower) and test you fu^H^Hboring harvester on it before committing anything. The whole devrandom affair gone too far and shown exactly how things should not be developed in FreeBSD. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 code and kern.random.sys.burst=$SMALLNUMBER ?? Mark, please get slow machine (say 100MHz or slower) and test you fu^H^Hboring harvester on it before committing anything. The whole devrandom affair gone too far and shown exactly how things should not be developed in FreeBSD. I've done this. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? I've not tried Rijndael code yet, do you think that it could make a noticeable difference? As for kern.random.sys.burst=$SMALLNUMBER I think that it is your task to tune defaults in such a way that it would not disturb even low-profile users (i.e. would not cause any measureable performance degradation). Tuning defaults with power users in mind is extremly bad idea - we are not an OS with mininal configuration PIII-500/128MB. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? I've not tried Rijndael code yet, do you think that it could make a noticeable difference? As for kern.random.sys.burst=$SMALLNUMBER I think that it is your task to tune defaults in such a way that it would not disturb even low-profile users (i.e. would not cause any measureable performance degradation). Tuning defaults with power users in mind is extremly bad idea - we are not an OS with mininal configuration PIII-500/128MB. Have to admit that after updating my kernel all these and several other harvester-related problems are gone. Now there is no measureable difference in performance with harvesting turning on and off and mouse moves smothly without usual patch for scmouse.c. ;) Finally I can thank you for a good work Mark! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 harvesting turning on. 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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 the Davies-Meyer hash in hash.c. In order for the random kthread to show me numbers (I got paranoid when it didn't seem to show up), I slowed it down by looping the hashing "guts" 100 times :). This very clearly shows the superior key agility of Rijndael over Blowfish. Now kern.random.sys.burst is still available for those very slow, very high interrupt cases. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c2001/02/11 16:21:35 1.31
+++ yarrow.c2001/03/12 19:09:15
@@ -104,11 +104,8 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
-
- else {
-
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 make the random
code less intrusive to the rest of the system. You need to do it as a
matter of course, not as an afterthought. A better hashing algorithm
is all well and fine, but doesn't really solve the lots-of-interrupts
problem, it just moves the bar a little. It doesn't scale, whereas
a hard limit on interrupt seeds per second does scale.
If you need a larger ring for initial seeding, then I recommend adding
a flag to the harvester. e.g. manual reseeding would use
the whole ring, but interrupt seeding would only operate if the current
number of entries in the ring is 32 and be a NOP otherwise. Or
something like that. Even 32 could be too large... that would be
32 x 10 or 320 interrupt seeds a second, which is overkill. Perhaps
something like 8 would be better (8 x 10 = maximum of 80 interrupt
reseeds a second).
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c2001/02/11 16:21:35 1.31
+++ yarrow.c2001/03/12 19:27:02
@@ -104,11 +104,9 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
- else {
-
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
Index: yarrow.h
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.h,v
retrieving revision 1.15
diff -u -r1.15 yarrow.h
--- yarrow.h2001/02/11 16:21:35 1.15
+++ yarrow.h2001/03/12 19:27:20
@@ -32,7 +32,7 @@
*/
/* The ring size _MUST_ be a power of 2 */
-#define HARVEST_RING_SIZE 1024/* harvest ring buffer size */
+#define HARVEST_RING_SIZE 64 /* harvest ring buffer size */
#define HARVEST_RING_MASK (HARVEST_RING_SIZE - 1)
#define TIMEBIN16 /* max value for Pt/t */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 much more
configurable way.
M
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c 2001/02/11 16:21:35 1.31
+++ yarrow.c 2001/03/12 19:09:15
@@ -104,11 +104,8 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
-
- else {
-
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
: : 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 much more :configurable way. : :M : 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
: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 adjustments make the code any better from an algorithmic point of view. As far as I can tell, things can still run away and interrupts still have an unnecessarily large fixed overhead when they call the random_harvest_internal(). 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 interrupts per second? Why are you going through loops to create complex, sensitive code paths when a simple solution can be plopped down and will work, SNAP, just like that? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 interrupts per second? Why are you going through loops to create complex, sensitive code paths when a simple solution can be plopped 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 Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
: 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 :Warning: this .sig is umop ap!sdn And if I were paranoid I could setup an interrupt a thousand times a second to scan all of physical memory and harvest the randomness from that. I am a security minded person... and I am also pragmatic. There's such a thing as overkill and your random number generator is doing it in spades. It is entirely unnecessary. Maybe rather then throw in the overkill you should actually *test* the random number generator to see where the randomness starts to break down when lowering the harvest rate. Thousands of harvests a second is just plain insane, no matter how security minded your 'lots of security minded people' are. Just ten a second should be plenty good enough, frankly, even for a paranoid security minded guy, especially considering the amount of memory the random number generator is using for state. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. Thanks. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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, 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 tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. Thanks. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
