Opened 9 years ago

Last modified 3 months ago

#12321 new bug

sftp transfer slow compared to ubuntu.

Reported by: eanyx Owned by: nobody
Priority: normal Milestone: R1.1
Component: Network & Internet Version: R1/alpha4.1
Keywords: slow sftp transfer Cc:
Blocked By: Blocking:
Platform: All

Description

On lastest Haiku build (official nightly hrev49559 x86 hybrid gcc2) downloaded 21 august 2015, I still have the same speed issue.

I launch an sftp transfer of a file from haiku virtual host to physical host RHEL (Redhat Enterprise Linux) 6.5. Then I launch an sftp transfer of the same file from ubuntu mate 15.04 32 bits to the same physical host RHEL (Redhat Enterprise Linux) 6.5.

Haiku and ubuntu are installed on the same virtualbox binaries (Virtualbox 4.3.14 hrev95030 provided with RHEL 6.5).

And with the same virtual network configuration (NAT Intel PRO/1000 MT Desktop (82540EM)).

The RHEL openssh server is openssh-server-5.3p1-94.el6.x86_64 ubuntu openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015 haiku openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015

On ubuntu the average speed is 35 MB/s. On haiku the average speed is 8.8 MB/s.

Joined 2 screenshot and haiku /var/log/syslog + /var/log/syslog.old + versions of openssh.

Attachments (7)

screen_shot-buntu_mate_15_04_32_bits-on_virtualbox_4.3.14_r95030-on_RHEL_6.5-download_speed.png​ (84.2 KB ) - added by eanyx 9 years ago.
screenshot-haiku_hrev49548_hybrid_gcc2_x86-on_virtual_box_4.3.14_r95030-on_RHEL_6.5-download_speed.png​ (321.2 KB ) - added by eanyx 9 years ago.
openssh-server-RHEL-6.5.out​ (96 bytes ) - added by eanyx 9 years ago.
openssh_version_haiku.out​ (42 bytes ) - added by eanyx 9 years ago.
openssh_version_ubuntu_15_04_mate.out​ (65 bytes ) - added by eanyx 9 years ago.
syslog​ (394.1 KB ) - added by eanyx 9 years ago.
syslog.old​ (512.0 KB ) - added by eanyx 9 years ago.

Download all attachments as: .zip

Change History (14)

by eanyx, 9 years ago

Attachment: screen_shot-buntu_mate_15_04_32_bits-on_virtualbox_4.3.14_r95030-on_RHEL_6.5-download_speed.png​ added

by eanyx, 9 years ago

Attachment: screenshot-haiku_hrev49548_hybrid_gcc2_x86-on_virtual_box_4.3.14_r95030-on_RHEL_6.5-download_speed.png​ added

by eanyx, 9 years ago

Attachment: openssh-server-RHEL-6.5.out​ added

by eanyx, 9 years ago

Attachment: openssh_version_haiku.out​ added

by eanyx, 9 years ago

Attachment: openssh_version_ubuntu_15_04_mate.out​ added

by eanyx, 9 years ago

Attachment: syslog​ added

by eanyx, 9 years ago

Attachment: syslog.old​ added

comment:1 by eanyx, 9 years ago

Is the some ipro1000 driver issue or openssh issue.

note: the proper openssh version of ubuntu is OpenSSH_6.7p1 Ubuntu-5ubuntu1, OpenSSL 1.0.1f 6 Jan 2014.

Version 0, edited 9 years ago by eanyx (next)

comment:2 by mmlr, 9 years ago

Just for the record: The Haiku TCP implementation doesn't implement any of the performance features (window scaling for example). A generally more modest throughput is therefore fully expected. To compare the driver performance and system overhead alone you'd need to do a comparison using UDP, where such features do not come into play.

comment:3 by diver, 9 years ago

Don't know if it's related but just for the record:

VMware Fusion 7.1.2 

vendor 1022: Advanced Micro Devices, Inc. [AMD]
device 2000: 79c970 [PCnet32 LANCE]

using pcnet driver in nat mode. scp upload speed to host always starts at 2.7MB/s and deteriorates to about 100KB/s.

VirtualBox 4.1.28 

vendor 8086: Intel Corporation
device 1004: 82543GC Gigabit Ethernet Controller (Copper)

using ipro1000 driver in nat mode. scp upload speed stays within 6-8MB/s at all times. In bridged mode speed stays within 8-10MB/s at all times.

I uploaded the same 72Mb file to the same host in this testing.

comment:4 by diver, 9 years ago

Odd, now scp over nat in VBox shows the same speed as bridged. Go figure...

comment:5 by waddlesplash, 5 years ago

TCP stack changes mean performance is usually much faster now, so please test.

comment:6 by pulkomandy, 4 years ago

Milestone: R1 → R1.1

comment:7 by Coldfirex, 3 months ago

This should be resolved in a recent nightly if you can retest.

Note: See TracTickets for help on using tickets.