Novell Client IR9a slow after a while to NW 6.5 SP8

Hello.

I have an installation with a growing number of Windows 7 64-Bit SP1 machines with the Novell Client for Windows 7 SP1 IR9a.
After a while (some after one hour, some after about 3-4 hours) of using the machine the access to the server shares becomes extremly slow. A logoff from Windows 7 and relogon resolves the problem, then it is fast again.
Windows XP Professional machines with the 4.91 client to not have this problem.

I have tried:

- disable IPv6
- sorted the Provider order -> Netware Services is on top
- updates the Novell Client to IR9a

Any idea?

Thanks fir help,
Michael
  • -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I once saw something similar doing some testing for another customer and
    opened Bug# 690630 as a result. The original description from the bug
    follows:

    <quote>
    A customer reported that NCP performance with the Novell Client on
    windows seven was significantly degraded compared to NCP on windows XP
    or SMB. While running several tests I have found one pattern that
    appears to be repeatable, specifically the degradation of performance
    copying files from the volume, to the same volume, via NCP from the
    windows machine. To duplicate this I have a directory with one thousand
    one hundred-byte files which I copy, delete, copy again, delete,
    watching the time each iteration.

    The first copy after mapping the drive takes around one minute. After
    about ten tries I'm up to three minutes. Disconnecting from the Novell
    network and reconnecting does not improve performance. Restarting the
    workstation does improve performance back to the original performance.
    Running the same test over and over to the same volume using SMB as the
    protocol has about the same performance for every pass... around 01:14,
    even when a test before/after these SMB tests but using NCP shows the
    degraded/degrading performance.

    The performance hit I'm seeing appears to be correlated with the number
    of files used more than the size of the files. I'm specifically testing
    with thousands of small files to show the degradation vs. larger files.
    The systems used for testing are connected via a gigabit switch (and
    show gigabit speeds for their network connections) and are sitting next
    to eachother. All systems (seven, XP, and OES) are bare metal and
    dedicated to this set of tests.

    For testing I have used richcopy, robocopy, and fastcopy along with the
    regular copy functionality of the operating system. I'm continuing
    testing copying from the server via SMB and to the server via NCP, and
    vice versa, and it seems that NCP performance is worse over time when it
    comes to writing compared to reading, though that's still based on
    preliminary results. The systems here are currently available for
    engineering to access as needed; I'd like to work with anybody involved
    to see how I can better troubleshoot this as well.

    Expected Results: Constant performance for a given data set and
    operation due to use.

    Actual Results: Degrading performance for a given data set and operation
    due to use.
    </quote>

    If this matches your observations, especially with IR9a applied, you may
    want to open a Service Request with Novell to link it to this bug. It
    may be worth noting that in my testing logging out and back in did NOT
    help improve performance so this appeared to be some kind of leak in a
    way that was not tied just to the user's session.

    This is a possible update that may resolve this issue due to work on
    another bug which you can try. As this is a bug the SR should be
    credited to you if this turns out to be the issue.

    Good luck.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.15 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQIcBAEBAgAGBQJO05sfAAoJEF XTK08PnB5OBsP/iRkh1WB8PKOlzAkaJrDlihK
    6VhbRuJ9C/7H6G5 YB/8vPxex9qeoA4sJaTxrKIV/2ikIFvFlqlamqPutud5SGlT
    BPrwC0Bf9GToB3/g9uDak7IJKJP/QHnLrKhn/TSAaO1PasWE7oudmxXBfMlG8sXG
    y/P6wox6LV5vjPk/w10y38nvteiGVS0HMeWzhYZTWVtg76iOl1L0w4HVGU8xRWYK
    GjgRJyyVQRVmiiWh9F3GLCYtvq9tSFyGN5GHATSROCmiLf43 AAAJrAwYELD3cW7
    ys0nnyN pKm07iAtlKh5afYEMaseeoRJZFWxO39LOOXAg8FVOVpXdPJJv3GuwPqX
    96yKqPZPz6AiLEH7qgeUGN1/3LJYCjK1TlC7oN/D0dRwxBuyoAKgkYbGyOjrABHt
    vfCuaNPK2nsUpOzhUK2tw1523lUNEW0bUdxE6bNXxp0ccfeETpjqszeLCuFtYQFs
    OTJK0qjJYeUkXw9yDzLKGUH28vcb53wxEup1C8JFif3Pxg27myzad4LYOPXxVpdT
    2jVGclT78phfXym2tKsSx8SKH7KpcfdESUQ8 N3bsXtM6kadXi tfWn5jwg1CE3K
    B/5QCLqbGi0OeA5n1Sz5JPRisCCmXcplQ1v3/1nnezSxI6R2ZHNEdCl2K8MwGUGr
    XkmzLYO1q3miy luSOd3
    =Gkab
    -----END PGP SIGNATURE-----
  • Aaron,

    On 28.11.2011 15:33, ab wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > I once saw something similar doing some testing for another customer and
    > opened Bug# 690630 as a result. The original description from the bug
    > follows:


    There's one noteable difference though (says the customer who made you
    log that defect): At least in my original case, logging off and back on
    wouldn't help. A full reboot woth Win7 was necessary to get the client
    back to normal performance.

    YMMV.

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

    Thank you for your answers. So it is a bug in the client?
    Here a logff / logon to Windows 7 solves the problem, but it is annoying. We don't need th restart the whole client machine.

    Michael
  • Hello.

    Thank you for your answers. So it is a bug in the client?
    Here a logff / logon to Windows 7 solves the problem, but it is annoying. We don't need th restart the whole client machine.

    Michael
  • multicom;2157318 wrote:
    Hello.

    Thank you for your answers. So it is a bug in the client?
    Here a logff / logon to Windows 7 solves the problem, but it is annoying. We don't need th restart the whole client machine.

    Michael


    Sounds like a bug.

    You've tried client 2 sp2 right?
    Doesn't look like your bug is listed as fixed but they've finally officially recommended to turn off file caching on the Win7 client. Hoping this client is approaching relative stability now that Attachmate is on the case.

    Bug fixes since latest 1.x version are listed in the sp2 readme:
  • Hi Foccer.

    Thank you for the reply. I will try now SP2 on one station.

    Michael
  • Hi.

    Sp2 seems to has solved the problem.

    Thanks,
    Michael
  • Hi.

    Sp2 seems to has solved the problem.

    Thanks,
    Michael