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-02 16:36:42.000000000 -0400 +++ shadow/78075.tmp.18850 2006-05-02 18:29:28.000000000 -0400 @@ -467,6 +467,71 @@ ------- Additional Comments From [EMAIL PROTECTED] 2006-05-02 16:36 ------- ZMD does virtually the same thing as mget.cs -- it reads a 8192 bytes on each read. + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-02 18:29 ------- +> I use openssl in client mode to check what cypher is being used, +> and did so for all the results posted - when I say one cypher was +> used, it was. + +Hey, I totally believe you, but you also said: + +> Default cypher is presumed to be "apache-standard" AES/256. + +and I assumed you weren't 100% sure about the AES/256 being the +negotiated cipher. Ethereal was an easy way to find out without any +change to the client or server. + +> Sebastien, can you comment on the why I would not be able to +> compare download via rug/zlm vs wget ? + +You can compare, but the results just doesn't mean much. ZLM itself +should be taking time (doing the transfer and/or other stuff, like +initialization, logging...), requiring extra memory, extra JIT time... + +Substracting the install time from the total time does help - but it +doesn't consider all the other stuff ZLM possibly does (directly or +indirectly), so you're comparing SSL(mono)+extra(ZLM) with SSL(wget). + +By comparing mget/wget you compare the real SSL speed - which is the +real issue: SSL(mono) versus SSL(wget). That won't make AES faster, +but it will show more accurate results. Anyway feel free to try it (as +I can't) and you'll see if the extra(ZLM) time exists or not. + +You can also try to vary the size of the downloaded RPM as the +negotiation is very CPU intensive (and has no relation with the +download size). + +Also, if it fit a real-life scenario for ZMD, you can try to download +multiple RPM without re-staring the ZMD process (as this will require, +under most circumstances, only a single handshake). + +> Go figure, I also thought the same. And 7 seconds, 37 seconds, +> 2m7sec (127 seconds) are *indeed* in three different orders, +> the powers of ten 0, 1 and 2. + +yes and that exact statement would also be true if wget took 1 second +and Mono took 999 seconds ;-) but you're free to find that a fair +assessment. + +Personally I prefer using your numbers (even if they do not compare +mget with wget)... +37 / 7 = 5.3x, which is slow (if not quite one order of magnitude, 10x) +127 / 7 = 18.14x, which is bad (if not even close to two order of +magnitude, 100x) + +> Under the same configuration, wget takes 9 seconds. + +even if I'm not totally sure if it's 7 or 9 seconds I should be using +to compare with 127s (127 / 9 = 14.11x). + + +So my point isn't that the Mono crypto algorithms are fast. They are +managed implementations, which inherits a lot of advantages but (even +if they can get better) will *never* compare, performance wise, to +hand-optimized assembly implementations as used in openssl, gnutls... +In fact using a well known managed AES implementation (from a Mono +competitor in the Windows world) would still be much slower than wget +(sorry the competitor's EULA prohibits publishing benchmarks). _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
