Hello all,
Why the data transfer speed of the OpenSSL client and server is nearly 10
times slower then when using the regular sockets? The code of the standard
samples of client and servers are used.
The code for client is:
char host[MAX_PATH];
BIO *out;
char buf[1024*10],*p;
SSL_CTX *ssl_ct
Sergey S. Levin wrote:
Why the data transfer speed of the OpenSSL client and server is nearly
10 times slower then when using the regular sockets? The code of the
standard samples of client and servers are used.
Are you also measuring the time it takes to setup the SSL connection or
are you o
Hello Darryl,
Thank you for a reply.
From glancing at your code it looks like your bulk data transfer is
something like 300 lots of nBioBlockSize, and I presume nBioBlockSize is
<= 10k, so thats only 3Mb of data.
The nBioBlockSize is 4096 Bytes. The transfer is 300 * buf_size where the
buf_s
SW crypto aint cheap. It can consume lots of CPU cycles. If the system
was nearly CPU saturated with a "plain" transfer, then the overhead of
the crypto can very definitely take the throughput down considerably.
rick jones
one of these days I need to make an SSL version of netperf :)
Hello Rick,
SW crypto aint cheap. It can consume lots of CPU cycles. If the system
was nearly CPU saturated with a "plain" transfer, then the overhead of
the crypto can very definitely take the throughput down considerably.
1. If i use FileZilla and SSL connection - it works on 100% of spe
Sergey S. Levin wrote:
I dont see any timing code in the middle to separate the timings for
the SSL cryptographic setup phase from the application data transfer
phase. I think you are doing a piggybacked connection setup so your
first application data write is performing the SSL connection set
Hello Richard,
But which cpu types/frequencies are involved on both sides of the
connection and which cipher suite do you use?
Server - Celeron 2GHz, Cient - Intel PIV 2GHz.
As to the second question - I'm not changing the defaul values in the
sources code. I had taken the saccept.c and sconne
On Fri, Mar 02, 2007 at 07:47:29PM +0200, Sergey S. Levin wrote:
> Hello Richard,
>
> >But which cpu types/frequencies are involved on both sides of the
> >connection and which cipher suite do you use?
>
> Server - Celeron 2GHz, Cient - Intel PIV 2GHz.
> As to the second question - I'm not chang
Sergey S. Levin wrote:
But which cpu types/frequencies are involved on both sides of the
connection and which cipher suite do you use?
Server - Celeron 2GHz, Cient - Intel PIV 2GHz.
As to the second question - I'm not changing the defaul values in the
sources code. I had taken the saccept.c a
> cout << "Set BIO block size (ex: 4096): ";
> cin >> nBioBlockSize;
What value are you using for nBioBlockSize?
> else
> {
> BIO_ctrl(out, BIO_CTRL_FLUSH, 0, NULL);
> }
Why is this here?
DS
_
Sergey S. Levin wrote:
1. If i use FileZilla and SSL connection - it works on 100% of speed.
I dont know what FileZilla is, but which SSL implementations is used and
what key exchange protocol and what symmetric cipher did it choose ?
2. The processor load is just 5% so, this should not b
Darryl Miles wrote:
Sergey S. Levin wrote:
1. If i use FileZilla and SSL connection - it works on 100% of speed.
I dont know what FileZilla is, but which SSL implementations is used and
what key exchange protocol and what symmetric cipher did it choose ?
FileZilla uses also OpenSSL.
Ciao,
Sergey S. Levin wrote:
Hello Rick,
SW crypto aint cheap. It can consume lots of CPU cycles. If the
system was nearly CPU saturated with a "plain" transfer, then the
overhead of the crypto can very definitely take the throughput down
considerably.
1. If i use FileZilla and SSL connection
On Mon, Mar 05, 2007 at 10:46:19AM -0800, Rick Jones wrote:
> Sergey S. Levin wrote:
> >Hello Rick,
> >
> >>SW crypto aint cheap. It can consume lots of CPU cycles. If the
> >>system was nearly CPU saturated with a "plain" transfer, then the
> >>overhead of the crypto can very definitely take
14 matches
Mail list logo