Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78075 --- shadow/78075 2006-05-01 19:01:10.000000000 -0400 +++ shadow/78075.tmp.11276 2006-05-01 20:12:09.000000000 -0400 @@ -392,6 +392,33 @@ mono client, SSL RC4/SHA1/128b = 37 secs net download (97 seconds less than AES/256!) there is, of course, a bit of variation between different runs, usually less than 2 seconds. + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-01 20:12 ------- +I'm not sure how you can compare (or interpret the results from) ZLM +times versus wget times. + +To compare SSL performance you can either: + +* compare the times of an older ZLM with a newer one - but that +wouldn't be very interesting to get cryptographic results; + +* compare the times of an older ZLM with wget, then compare the +results with the newer ZLM. More interesting but still not enough +crypto related wrt the bug summary; + +* use the attached mget source code and compare the SSL/TLS speed +between Mono and wget. Both tools are doing the same and only thing: +transfering data using from an URL. Once done, you can compare mget +with ZLM to see how much time comes from ZLM itself and the Mono SSL +stack. + +You can also use ethereal (on a smaller RPM) to see which cipher gets +negotiated during the SSL/TLS handshake. That way you'll be sure if +it's AES256 or (I really doubt) something else. + +Side note: we do not share the same definition of "order of magnitude" +because in mine: 1 order of magnitude == 10x, 2 order of magnitude == +100x ... ;-) _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
