FlashFXP Forums - View Single Post

Yil · 11-08-2010, 04:46 PM

BoNeZz: OK, I think I have an idea of what might be happening on single core machines and probably in other cases where there are more active transfers than logical cores.

The I/O threads send/receive all data and prior to v7.4 they would hand off the actual CPU-intensive encryption/decryption to another thread. With the change to OpenSSL and the high-performance non-copying BIO interface it became trickier to pass the work off to another thread so I opted to just do it when I got the data and figured I'd save the overhead of a few context switches and a bunch of other crap in the process. The request for new data from the socket wouldn't occur until after all the processing was done in either case and the kernel just buffers any new TCP data arriving. With this setup the total CPU time will indeed be less but it appears I forgot to take into account what the higher priority of the I/O thread might do to the rest of the computer. It's possible that hogging the CPU in such a way changes the system responsiveness. This is particularly hard to judge when a network and a remote machine feedback into everything. Subtle changes to the timing of sending network ACKs, etc can effect max bandwidth...

If during your tests you were the ONLY user downloading from the FTP I don't think there should be much of a difference on a single core machine. Perhaps you could double check that just to see if that matters?

However, I can now theorize why 2+ users downloading/uploading on a single core machine might see a difference between v7.3 and v7.5. It probably doesn't help that OpenSSL got stronger (and slower) encryption ciphers.

I'm not sure what the best solution is. I'll probably try playing with the priority of the I/O threads depending upon what they are doing. So before encryption/decryption they would go back to normal priority which means the other I/O threads would be favored. This would approximate the old behavior provided you doubled the number of I/O threads. Doing that now won't really hurt, but it won't help too much because they would all be at the same higher priority right now...

This is an interesting phenomenon, and one I didn't think of or see in any of my tests with my core i7 and it's 8 logical cores

Thanks for bringing it to my attention.

11-08-2010, 04:46 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	BoNeZz: OK, I think I have an idea of what might be happening on single core machines and probably in other cases where there are more active transfers than logical cores. The I/O threads send/receive all data and prior to v7.4 they would hand off the actual CPU-intensive encryption/decryption to another thread. With the change to OpenSSL and the high-performance non-copying BIO interface it became trickier to pass the work off to another thread so I opted to just do it when I got the data and figured I'd save the overhead of a few context switches and a bunch of other crap in the process. The request for new data from the socket wouldn't occur until after all the processing was done in either case and the kernel just buffers any new TCP data arriving. With this setup the total CPU time will indeed be less but it appears I forgot to take into account what the higher priority of the I/O thread might do to the rest of the computer. It's possible that hogging the CPU in such a way changes the system responsiveness. This is particularly hard to judge when a network and a remote machine feedback into everything. Subtle changes to the timing of sending network ACKs, etc can effect max bandwidth... If during your tests you were the ONLY user downloading from the FTP I don't think there should be much of a difference on a single core machine. Perhaps you could double check that just to see if that matters? However, I can now theorize why 2+ users downloading/uploading on a single core machine might see a difference between v7.3 and v7.5. It probably doesn't help that OpenSSL got stronger (and slower) encryption ciphers. I'm not sure what the best solution is. I'll probably try playing with the priority of the I/O threads depending upon what they are doing. So before encryption/decryption they would go back to normal priority which means the other I/O threads would be favored. This would approximate the old behavior provided you doubled the number of I/O threads. Doing that now won't really hurt, but it won't help too much because they would all be at the same higher priority right now... This is an interesting phenomenon, and one I didn't think of or see in any of my tests with my core i7 and it's 8 logical cores Thanks for bringing it to my attention.