ioFTPD v7.7.3 (STABLE) Released

[Yil]

Paja1: Clearly you see a difference, now to determine possible causes... BTW, I'm relatively convinced this isn't a common problem as I know lots of people aren't seeing this.

1) Let's compare apples to apples since the non-SSL transfers are similar let's set it up so that we can rule out the client/server having really poor CPU time or really bad encryption.

Try this .ini setting:
OpenSSL_Ciphers = DEFAULT:!LOW:!EXPORT:!HIGH

The !HIGH on the end should exclude the > 128bit suites along with some 128bit ones, if you don't get AES128-SHA then try

OpenSSL_Ciphers = DEFAULT:!LOW:!EXPORT:!HIGH:AES128-SHA

which I think should work but I've never tested... This is just passed to the OpenSSL library directly so you can consult the OpenSSL documentation for examples and more information.

If that doesn't show a difference then let's try to make sure it's just an encryption library difference. Since v6.6.0 is a long ways from 7.7.3, how about you try 7.3.3 which is the last of the non-OpenSSL releases? That way we can rule out a lot of changes. In general v7.4 and 7.5 were really about OpenSSL and 7.6 and 7.7 were primarily bugfix releases with a few non-vital changes thrown in.

[paja1]

Hi Yil,
thanks for your post, here are some results:

7.7.3
TLSv1 encrypted session using cipher DHE-RSA-SEED-SHA (128 bits)
700.73 MB in 1 minute 47 second (6.49 MB/s)

So it's slightly better, just not as fast as 6.6.0.

I tried both:

OpenSSL_Ciphers = DEFAULT:!LOW:!EXPORT:!HIGH

and

OpenSSL_Ciphers = DEFAULT:!LOW:!EXPORT:!HIGH:AES128-SHA

Both versions are running on the same port, same hdd. :S

I'm going to download 7.3.3. and will see

Paja

[paja1]

OK, 7.3.3 installed, configuration updated and here is the result:

TLSv1 encrypted session using cipher AES128-SHA (128 bits)
700.73 MB in 24.26 seconds (28.89 MB/s)

TLSv1 encrypted session using cipher AES256-SHA (256 bits)
700.73 MB in 23.82 seconds (29.42 MB/s)

What else can i test or try?

thx

[Yil]

Ok. Now try 7.4.5 which is basically 7.3 with initial OpenSSL support and an older compiled encryption library. Since this doesn't have the priority fix to make things fairer with multiple downloaders the encryption should run at high priority which is good for testing since you are the only user downloading anyway. If that appears the same then try disabling your anti-virus / MSE / etc and see if that makes a difference...

[paja1]

Originally Posted by Yil

Ok. Now try 7.4.5 which is basically 7.3 with initial OpenSSL support and an older compiled encryption library. Since this doesn't have the priority fix to make things fairer with multiple downloaders the encryption should run at high priority which is good for testing since you are the only user downloading anyway. If that appears the same then try disabling your anti-virus / MSE / etc and see if that makes a difference...

Hi, I can't find 7.4.5 only 7.4.3, can you give me a link?

thx

[Yil]

Oops, 7.4.3 is fine. .4 was a limited release debug version, and .5 added some iTCL stuff for socket protection but neither are needed for your test.

[paja1]

Originally Posted by Yil

Oops, 7.4.3 is fine. .4 was a limited release debug version, and .5 added some iTCL stuff for socket protection but neither are needed for your test.

OK, todays results:

6.6.0
TLSv1 encrypted session using cipher AES256-SHA (256 bits)
699.68 MB in 29.32 seconds (24.12 MB/s)

7.3.3
TLSv1 encrypted session using cipher AES256-SHA (256 bits)
699.68 MB in 28.69 seconds (24.39 MB/s)

7.4.3
TLSv1 encrypted session using cipher AES256-SHA (256 bits)
699.68 MB in 4 minutes 58 seconds (2.34 MB/s)

7.7.3
TLSv1 encrypted session using cipher ECDHE-RSA-AES256-SHA (256 bits)
699.68 MB in 5 minutes 17 seconds (2.20 MB/s)


I'm running Windows 2008/R2 x64. No anti-virus is installed.
Not a single CPU Core is going over 6% utilization.
Same file, same HDD, all is the same.

Any idea?
Thanks!

PaJa

[Yil]

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?

[Flow]

Is this on only issue with filetype .mkv ? Have you tried rename file to .rar or .zip (just try) and do same transfer test.

[paja1]

Originally Posted by Yil

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?

Hi Yil,

i've changed setting for 6.6.0 and 7.3.3 to this:

Min_Cipher_Strength = 256
Max_Cipher_Strength = 256

It gives me 256 bit encryption.

Yes, i'm running on AMD but i had the same speed issues on my old box with intel as well

I tried to connect my laptop to the same switch where my box is, so nothing on the way, with similar results. :S

Even switched the Windows Firewall off, but still the same results

I'm quite desperate.

PaJa

[Yil]

paja: I was able to confirm that 256aes did indeed work on 7.3.3 under win7 to my chagrin. I'm going to have to go back and test that on an old XP SP2 release because it didn't work when I tested it years ago (pre-vista) so it's possible they have added support for it and didn't document it, or it's only on the newer OSs, or it only works if you disable 128 bit support which I can't prove I tested back then...

We'd still have switched to OpenSSL because the stupid MS encryption library does all that DLL ref counting that was making the loader lock problem worse.

I'm really at a loss unless you try a different compiled OpenSSL library. Anything else odd installed on the server machine like some performance optimizer, network monitor, etc? There just isn't much difference between 7.3 and 7.4 and as far as network traffic goes there shouldn't be any difference which would account for performance changes like you are seeing.

One other thing you could try. V7.4 shouldn't have the Deny_Port_Host feature so why don't you connect to the server via 127.0.0.1 and select the Use Host IP for PASV feature and then FXP to the server from itself and see what kind of performance you get locally. Do the same test using the 192.168.x.y address of the machine to see if that makes a difference. If that works then it means we're dealing with just a network issue.

[paja1]

Originally Posted by Flow

Is this on only issue with filetype .mkv ? Have you tried rename file to .rar or .zip (just try) and do same transfer test.

Hi,
on all file types

I do not have any FW, Antivirus, optimizer... it's quite fresh Windows 2008 R2 installation with only ioFTPD on it.

PaJa

[paja1]

Originally Posted by Yil

paja: I was able to confirm that 256aes did indeed work on 7.3.3 under win7 to my chagrin. I'm going to have to go back and test that on an old XP SP2 release because it didn't work when I tested it years ago (pre-vista) so it's possible they have added support for it and didn't document it, or it's only on the newer OSs, or it only works if you disable 128 bit support which I can't prove I tested back then...

OK, good to know, hehe

Originally Posted by Yil

We'd still have switched to OpenSSL because the stupid MS encryption library does all that DLL ref counting that was making the loader lock problem worse.

I can totaly understand that.

Originally Posted by Yil

I'm really at a loss unless you try a different compiled OpenSSL library. Anything else odd installed on the server machine like some performance optimizer, network monitor, etc? There just isn't much difference between 7.3 and 7.4 and as far as network traffic goes there shouldn't be any difference which would account for performance changes like you are seeing.

Nothing, it's really fresh install with only ioFTPD on.
I did have tried another version of OpenSLL (0.9.8e) with this result:
7.4.3
TLSv1 encrypted session using cipher AES256-SHA (256 bits)
696.79 MB in 2 minutes 47 seconds (4.17 MB/s) (same switch, only two PCs connected, my laptop and the box itself.

Originally Posted by Yil

One other thing you could try. V7.4 shouldn't have the Deny_Port_Host feature so why don't you connect to the server via 127.0.0.1 and select the Use Host IP for PASV feature and then FXP to the server from itself and see what kind of performance you get locally. Do the same test using the 192.168.x.y address of the machine to see if that makes a difference. If that works then it means we're dealing with just a network issue.

If i try to download file directly on the box, via external IP, i'm getting good reasonable speed, but i did know that.

Example of localy downloaded file:
7.7.3
SSL encrypted session using cipher DHE-RSA-AES256-SHA (256 bits)
699,54 MB in 32,62 seconds (21,45 MB/s)

Example of local FXP (public IP) transfered file:
7.4.3
150 Opening BINARY mode data connection using SSL/TLS.
Transferred 1 file totaling 702,63 MB in 29,08 seconds (24,98 MB/s)

Example of local FXP (127.0.0.1) transfered file:
7.4.3
150 Opening BINARY mode data connection using SSL/TLS.
Transferred 1 file totaling 702,63 MB in 24,52 seconds (28,74 MB/s)

So it's a network problem, but i had it on my old box as well, with OpenSSL builds. I don't understand why is it, as there was not much changes in the code, as you mentioned. I'm going out of options.

PaJa

[Flow]

Originally Posted by paja1

Hi,
on all file types

I do not have any FW, Antivirus, optimizer... it's quite fresh Windows 2008 R2 installation with only ioFTPD on it.

PaJa

What duplex is your networkcard on?

[paja1]

Originally Posted by Flow

What duplex is your networkcard on?

1Gb, Full-Duplex.

Btw, I don't have any speed issue to download from IIS HTTS (256 bit) up to 38MB/s and ioFTPD up to version 7.3.* about 28-30MB/s. So doesn't looks like an LAN adapter issue.

And I had the same problem on different HW box as well. (Intel P4 Dual Core, Windows 2003 32 bit), i do have AMD Phenhm II X6, Windows 2008 R2, with the same result.

I already tried three different switches as well, without any change.

PaJa