>Do you guys have any profiling data to suggest this is beneficial? At >last check, the Java crypto was not a substantial performance problem, >and we found that these problems only arose under heavy load because of >context-switch cache flushing. If this is the case, native crypto isn't >going to help you.
There is no current data to wheter that is the cause for crypto being slow is because of context switches or not (not saying that it ain't, just that I don't know). One thing that is sure though it that there is a roof to SHA-1:s performance, even when NO context switching is involved.. As toad suggests it seems to be about 600MHz of p4 class CPU per MBit/s of datarate. That is enough for me. As I have said a couple of times.. introducing nio would make more accurate profiling easier for several reasons (besides making fred behave better and faster), I still vote for nio-as-fast-as-possible. My current profiling suggests that DLES and SHA1 are the main CPU hogs on a busy node (80 connections, 0.8MBit/s transfer during the profile). Have a look at the URL I sent yesterday, in that data DLES stands for 44% and SHA-1 for 13% of the CPU. DLES usage will be decreased with sip v2 (or? Have I misunderstood?), and SHA-1.. well toad seemed to get an idea tonight.. /N _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
