View Single Post
Old 11-14-2011, 09:06 PM  
Yil
Too much time...
 
Join Date: May 2005
Posts: 1,194
Default

paja1: Could you please double check what you posted? The Microsoft encryption library used by ioFTPD in v7.3 and before I believe only supports up to 128bit AES keys. I just double checked an old build and that was the best I could do. That doesn't change the recorded speeds, but it highlights the fact that we aren't comparing the same algorithm across 2 different encryption libraries... I expect you meant AES128-SHA in the first 2 timings.

If that's correct, then go back to 7.7.3 and tweak the OpenSSL_Ciphers line to make it use AES128-SHA as well. See the previous post for details. That should get all the timings on 128 bit AES.

I think we can speculate that since the ONLY significant difference between 7.3 and 7.4 (provided it just has the 1 transfer!) was the encryption library so it must be at fault, and I have an idea why. You mentioned the cores, ghz, etc but what architecture is the CPU? 6 cores got me thinking this is an AMD machine? That got me thinking that even though v7.4 and v7.7 use different OpenSSL compiled libraries both were compiled by me from unmodified sources. In both cases I used the optimized assembly language optional compilation option for max speed and perhaps this is somehow horrendous on AMD CPUs... I can't see why that would be, but I'm running out of ideas.

Since ioFTPD uses unmodified OpenSSL code this means you can use anybody's compiled ssleay32.dll and libeay32.dll files provided they are v1.0+. Grab both of them from a newer FlashFXP release, mIRC, etc and try it to see if it makes a difference. Perhaps they are compiled without the assembly language routines or with a different compiler.

The only machines I know the speed of are all Intel based and all appear fine. Perhaps someone else out there can confirm that their AMD based machine is doing fine?
Yil is offline   Reply With Quote