Highlighted
Absent Member.
Absent Member.
3575 views

Slow file transfer speeds to NSS volumes

We are getting slower file transfer speeds between our workstations and the NSS volumes on a new OES 11.2 server than I expect. I am hoping someone has some ideas of how to speed things up.

The max speeds I am getting (on 1 Gbps devices) are server receive/write speeds of around 50 MBps (400 Mbps) and server send speeds of around 45 MBps (360 Mbps). This is when copying an 8 GB file from a Win7 x64 machine with the Novell Client installed.

The same workstations (which have SSDs) are able to transfer about 930 Mbps between one another when using a network speed test utility. So, I am confident the bottleneck is not the workstations or the switches.

The server is OES 11.2 running on SLES 11.3, fully patched. It is running on "bare metal" (not a VM) on a Dell PowerEdge R710 with an internal RAID 5 array. The disks are 10K RPM, so they are rated at a min of 170 IOPS. I have two 1 Gbps NICs bonded, so the theoretical max throughput is near 2 Gbps, with the disks being the limiting factor.

I have noticed with all our OES servers that file transfer performance is never as good as I expect, so I don't think it is a problem with this specific box. This one is a new install, purchased and installed just a couple months ago.

I have tried some of the suggestions in TID 7003585 and other TIDs, including changing the NSS volume Read Ahead Count in Blocks from 16 to 64. All these changes have no noticeable impact on the performance.

On the Novell Client side, we have File Caching set to off, and File Commit is set to on. I realize this does not help performance, but we have had significant problems in the past when these two are set differently.

Can anyone give me some advice on how we can speed up file transfers?

Rick P
Labels (2)
0 Likes
9 Replies
Highlighted
Knowledge Partner
Knowledge Partner

On 09/09/2014 01:16 PM, RPummel wrote:
>
> We are getting slower file transfer speeds between our workstations and
> the NSS volumes on a new OES 11.2 server than I expect. I am hoping
> someone has some ideas of how to speed things up.


Just to point out what is probably obvious, there is nothing about the
Novell client that knows that NSS is behind this, and no direct connection
to the NSS volume from the client. The reason I point this out is to
ensure that we troubleshoot properly from the start. For example, what
are connections like to other parts of the server which are not using NSS?
What about using transfer methods, to both the NSS and non-NSS parts of
the server, using other file-transfer protocols (NFS, SSH/SCP, FTP, SMB,
etc.)? Also, how quickly can you copy the the NSS volume directly using
the server itself (copying from somewhere else on the server)? The first
step, to me, is to limit the problem to the real slow part. It may turn
out to be that this is only reproducible from NCP clients, but in that
case it's more likely to be NCP slowness than NSS slowness; the tests
above should help us.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Am 09.09.2014 21:16, schrieb RPummel:

> Can anyone give me some advice on how we can speed up file transfers?


You can't. What you see is the max a single NCP connection can achieve.
It's the protocol which limits you.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Absent Member.
Absent Member.

Is this documented somewhere, or is this just your own experience? If it is a limitation of the protocol, I would like to know this for sure before I spend more time troubleshooting. If it is not, then I need to see if there is anything I can do to speed it up.

mrosen;2332705 wrote:
Am 09.09.2014 21:16, schrieb RPummel:

> Can anyone give me some advice on how we can speed up file transfers?


You can't. What you see is the max a single NCP connection can achieve.
It's the protocol which limits you.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Absent Member.
Absent Member.

ab wrote:

> For example, what
> are connections like to other parts of the server which are not using NSS?
> What about using transfer methods, to both the NSS and non-NSS parts of
> the server, using other file-transfer protocols (NFS, SSH/SCP, FTP, SMB,
> etc.)? Also, how quickly can you copy the the NSS volume directly using
> the server itself (copying from somewhere else on the server)?
>


This raises the question how to read or write from NSS without using
NCP. In my understanding the mount on /media/nss/VOLUME is an NCP one as
it is managed through the NCP server, correct? Thus using another
protocol like SSH in order to transfer files to another system will
still make use of a local NCP connection.

Günther
0 Likes
Highlighted
Absent Member.
Absent Member.

Not at all. As ab said
there is nothing about the Novell client that knows that NSS is behind this, and no direct connection to the NSS volume from the client

CIFS clients can read and write to NSS just fine.

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
Highlighted
Visitor.

Some tests yu will want to perform:

Got to the server console and find the 8GB file in question and see how fast it is copied to /dev/null

e.g.



# 4GB ISO on NSS volume

ferb:/media/nss/NETADMIN/OES/iso # ls -lia
total 4188048
641 drwxrwxrwx 1 root root 4096 Aug 1 10:15 .
132 drwxrwxrwx 1 root root 4096 Aug 1 11:05 ..
896 -rw-rw-rw- 1 root root 4288559104 Jul 21 11:21 OES_11.2.0.iso

ferb:/media/nss/NETADMIN/OES/iso # dd bs=1M < OES_11.2.0.iso > /dev/null
4089+1 records in
4089+1 records out
4288559104 bytes (4.3 GB) copied, 9.49028 s, 452 MB/s

ferb:/media/nss/NETADMIN/OES/iso # dd bs=1M < OES_11.2.0.iso > /dev/null
4089+1 records in
4089+1 records out
4288559104 bytes (4.3 GB) copied, 1.50252 s, 2.9 GB/s

# Same 4GB ISO on EXT3.

ferb:/media/nss/NETADMIN/OES/iso # cd /iso <-- On EXT3

ferb:/iso # ls -li
total 4192144
11542530 -rw-r--r-- 1 root root 4288559104 Jul 21 11:21 OES_11.2.0.iso

ferb:/iso # dd bs=1M < OES_11.2.0.iso > /dev/null
4089+1 records in
4089+1 records out
4288559104 bytes (4.3 GB) copied, 9.18625 s, 468 MB/s

ferb:/iso # dd bs=1M < OES_11.2.0.iso > /dev/null
4089+1 records in
4089+1 records out
4288559104 bytes (4.3 GB) copied, 1.50839 s, 2.8 GB/s



For my server there is no difference, at all between EXT3 and NSS in terms of performance. The un-cached reads clocks in at ~450 MB/sec, cached reads ~2.8 GB/sec. Performing the copy twice, and ensuring the file is not already cached, is critical to the test. So its not NSS that is the problem. It also points out that the second time you read the file, essentially no disk I/O is actually required.

Bonding NICs does not double your speed for a given client.

The best way to test the performance is to map a drive, and use a Windows port of dd and copy the data to the bit bucket. Writing the data to a disk, even an SSD, introduces latency and timing which impact the outcome.

Things like opportunistic locks, client side caching, .... impact performance. As it requires additional work.

NCP is designed for hundreds or thousands of clients simultaneously accessing many files. Its sort of like saying that since I'm driving on an 8 lane highway, and nobody else is on the road, that I should be able to drive 400 miles per hour.

Latency is an issue for NCP, so addressing sources for latency in your network will improve performance.

You can use Wireshark ( on another workstation attached to a mirrored port ) to assess the data flow and identify if the client or the server is the issue. We have found that, largely, the client is the source of the issue. The server responds almost instantaneously, where as the client is slow to request the next "chunk" of data. Wireshark is, ultimately, the decisive tool to point the finger at client or server.

-- Bob
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Am 11.09.2014 17:06, schrieb RPummel:
>
> Is this documented somewhere, or is this just your own experience? If it
> is a limitation of the protocol, I would like to know this for sure
> before I spend more time troubleshooting. If it is not, then I need to
> see if there is anything I can do to speed it up.


It's fact, mathematically achievable by understanding tcp/ip and looking
at the tcp/ip parameters of an established NCP connection. Next find out
if the speed relevant parameters can be user-altered (no), and there you
go. It is also absolutely hardware independant, no matter how fast your
link is (even 10GBe or if it owuld exist 100GBe wouldn't be any faster).

Please do note that this is for *single* connections. NCP really shines
serving multiple clients simultaneously. On the downside, it really
can't saturate a mere GB link with a single connection.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Sorry to revive the old thread, but I thought it interesting that the May 2015 OES 11 SP2 Scheduled Maintenance Update 10648 (Restricted update) lists the following fix;

915203: Copying large files using Novell Client is slower than CIFS clients

While possibly not directly related to the NCP protocol limitations discussed in this thread, it will be interesting to see what is actually achieved with this update for NCP/Novell Client and large file transfer speeds vs CIFS.

Kevin


mrosen;2333472 wrote:
Am 11.09.2014 17:06, schrieb RPummel:
>
> Is this documented somewhere, or is this just your own experience? If it
> is a limitation of the protocol, I would like to know this for sure
> before I spend more time troubleshooting. If it is not, then I need to
> see if there is anything I can do to speed it up.


It's fact, mathematically achievable by understanding tcp/ip and looking
at the tcp/ip parameters of an established NCP connection. Next find out
if the speed relevant parameters can be user-altered (no), and there you
go. It is also absolutely hardware independant, no matter how fast your
link is (even 10GBe or if it owuld exist 100GBe wouldn't be any faster).

Please do note that this is for *single* connections. NCP really shines
serving multiple clients simultaneously. On the downside, it really
can't saturate a mere GB link with a single connection.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Hi.

Am 01.06.2015 um 21:36 schrieb salisburyk:
>
> Sorry to revive the old thread, but I thought it interesting that the
> May 2015 OES 11 SP2 Scheduled Maintenance Update 10648 (Restricted
> update) lists the following fix;
>
> 915203: Copying large files using Novell Client is slower than CIFS
> clients
>
> While possibly not directly related to the NCP protocol limitations
> discussed in this thread, it will be interesting to see what is actually
> achieved with this update for NCP/Novell Client and large file transfer
> speeds vs CIFS.


No need to be sorry at all, and yes, that is indeed supposed to chnage
exactly the tcp/ip parameters NCP uses/used discussed in this thread.

I have not had a chance to test this on a quick enough server. Also,
please note that it needs the most current Novel Client too.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.