Hi Again,
The problem was with my implementation, I'm using a multi-threaded
implementation, one thread for reading, another for writing. A mutex is
used to ensure serial access to the channel, the read thread used a
non-blocking read to check the recv buffer, then it slept for 20
milliseconds.
When I reduced the size of this sleep to 500 microseconds, the
throughput jumped to ~8MB.
My apologies for this distraction.
- Gearoid
On 30/01/12 11:37, Gearoid Murphy wrote:
Hi Aris,
I'm not sure if it's significant but the logs from the port forwarding
implementation show that the function 'channel_rcv_change_window'
makes changes to the window size but in the reverse port fowarding
implementation, changes to the window size are executed via the
'grow_window'
function.
- Gearoid
On 27/01/12 20:42, Aris Adamantiadis wrote:
Hi Gearoid,
It's possible that channel windows are not initialized the same way
in forward and reverse forwarding. This could result in bad
performances if the window is too small.
I'll check if I can find anything.
Aris
Le 27/01/12 18:16, Gearoid Murphy a écrit :
Hi,
We've been observing poor throughput (230KB/s) on libssh channels
generated from reverse port forwarding (ssh_forward_accept) via an
OpenSSH server.
Conversely, when using a channel generated through a normal port
forwarding call (ssh_channel_open_forward), we observe far greater
throughput (8MB/s).
Has anyone observed or experienced similar issues?, is there some
configuration aspect of the channel setup which needs to be modified?
libssh 0.5.2-1
Linux 3.0.0-15-generic x86_64 x86_64 x86_64 GNU/Linux
openssh-server 1:5.8p1
Thanks
- Gearoid
