#7 Performance problems with native IEC transfers, workaround

v0.0.12
closed
driver (9)
5
2012-09-14
2004-11-20
Anonymous
No

With version 0.0.12.0 and earlier versions as well as
some patched and self compiled versions after 0.0.12.1
I encounter performance problems for native IEC
transfers (no usage of any turbo protocol) from time to
time. Until now I couldn't see any rules, when of for
what version this happens.

For an example, if I transfer the ROM area of my
1541-II down to the PC with:

cbmctrl download 8 0x8000 0x8000 ROMIMAGE.ROM

this transfer normally needs ~116 seconds.

If the performance problem comes into account (I'm not
able to reproduce this problem with every version and
under any test circumstances), the very same transfer
needs 588 seconds instead. This is a resulting factor
of 1/5 for this test case.

Take note that the downloaded ROM does not contain
any transfer errors, the whole ROM is identical to
previously downloaded versions.

Workaround:
This performance problem can be worked around, if other
processes are started in the background, which somehow
have soem influence of the thread/process scheduling of
the Operating System (Windows XP here). Currently two
alternative commands can be issued, both are tools out
of the cygwin Unix emulation layer:

  • sleep 100000000000
  • tail -f somefiletowatch.log

Until now, I couldn't find other such tools that are no
cygwin tools. Maybe a native Win32 program issuing some
passive waiting (sleep) is also suitable to work around
the above problem.

Womo

Discussion

  • Spiro Trikaliotis

    Logged In: YES
    user_id=1059994

    Ok, I revisited that problem. I'm almost sure this is related to
    the NT4 related performance problem.

    I have another patch for it, which will be included in 0.0.12.2.

    For now, I set this issue to "pending" and I am waiting for
    future reports. If this does occur again, feel free to reopen
    this issue.

    Spiro.

     
  • Spiro Trikaliotis

    Logged In: YES
    user_id=1059994

    BTW: If this problem occurs again, please do the following for
    me to obtain some performance data:

    1. Create a directory "c:\opencbm\timing". This name is
      hard-coded, and the performance data will only be written if
      that directory exists.
    2. Make sure that there is no file "c:\opencbm\timing\timing.
      dat" inside that directory. If there is one, delete it.

    3. Install the driver, and do whatever you are doing. Make sure
      you do not do too much work, as the file will get big

    4. Uninstall the driver ("instcbm --remove")
    5. Take the file "c:\opencbm\timing\timing.dat", compress it,
      and send it to me via private mail.

    If possiblem, a timing.dat file for a run which did not show
    this behaviour might be helpfull, too.

    Thanks for the support,
    Spiro.

     
  • Nobody/Anonymous

    Logged In: NO

    Note to myself:

    It seems that the driver then must not be installed in
    automatic mode, when performance data should be created.

    Womo

     
  • Nobody/Anonymous

    Logged In: NO

    I found a dependency for the performance problem.

    Whenever Skype, a free VoIP software runs in the background
    (traybar), then I cannot watch the problem. Whenever I
    prepare the machine for long run test sessions I close all
    unneeded processes, traybar programs, services and so on.
    Therefore Skype is not running then and the performance
    problem becomes active.

    Timing.dat files as well as some other logs are following in
    a private mail as proposed.

    Womo

     
  • Spiro Trikaliotis

    Logged In: YES
    user_id=1059994

    1. It works with automatic mode, too. Just do what I told you
      ;-) and remove the driver before trying to get the timing.dat
      file. This file is only written if the driver is unloaded, which can
      be done by removing it completely.

    2. Thanks for the timing.dat files, I'm currently investigating
      further.

    Anyway, I'm reopening this issue again.

     
  • Nobody/Anonymous

    Logged In: NO

    The problem persists in CVS development release 0.1.0.15 and
    internal snapshot 0.1.0.15ss9:

    As tested the last weekend and previously discussed, the
    performance problem as described above persists with the
    latest development releases of cbm4win.

    The provided tool "htsmp.exe" (based on
    WaitForSingleObject()) was not able to help working around
    the problem. The only known working helper tools are sleep
    and tail out of the Cygwin distribution.

    Womo

     
  • Nobody/Anonymous

    Logged In: NO

    Problem solved with the upcoming 0.1.0a release

    I just checked out the current CVS branch
    0_1_0-bugfix_branch, which contains a fix from Spiro for the
    performance problem that could be watched under SMP and HT
    (Hyperthreading) system architectures.

    First I disabled all programs that established a workaround
    for this problem in the background, namely: Skype (VoIP) and
    ICQ (IM).

    A regression test of the latest internal development release
    0.1.0.15ss9 which does not contain the fix did show the
    performance problem clearly, runtime for the follwoing
    command was:
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 573s

    Installing the 0.1.0a release instead and executing the very
    same command brought:

    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 96s

    This definetly shows the fix. One drawback that could be
    watched is that the CPU load is much higher, while the first
    command (version 0.1.0.15ss9) consumed 20% to 30% CPU power,
    the latter one led to a consumption of 70% to 80%. Side
    note: WinAMP was running in the background for both command,
    so that I could check for other drawbacks regarding some
    multimedia software.
    Well, the high CPU load is something to work on in the future.

    Now some more regression tests are to do, all done with
    version 0.1.0a:

    Skype and ICQ running in the background as well as WinAMP:
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 87s
    "sleep 10000" + WinAMP running in the background:
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 87s
    "tail -f file" + WinAMP running in the background:
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 100s
    "tail -f file" + WinAMP running in the background (second time):
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 83s
    WinAMP only (second time):
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 91s
    Without background processes (one of the mentioned above):
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 90s
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 89s
    "tail -f file" running in the background (without WinAMP):
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 69s
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 67s
    "sleep 100000" running in the background (without WinAMP):
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 68s
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 68s
    Skype and ICQ running in the background only:
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 67s
    cbmctrl download 8 0x8000 0x8000 32k_image.rom - 70s

    Enough for now, I think. What can be watched is that the
    performance heavily depends on the background CPU load, but
    all the transfers are in general faster than with my
    introductional bug report. This is definetly an improvement
    although there's enough room for more.
    Since we all know (do we?) that serving synchronous
    protocols is a mess under multitasking OSes due to
    scheduling and other quirks the disadvantage of this fix,
    very high CPU load, is understandable.

    For now this fix is a sufficient solution, furthermore since
    the standard IEC protocol should be avoided in general and
    replaced by a turbo protocol routine whenever it is possible.

    Womo

     
  • Spiro Trikaliotis

    Logged In: YES
    user_id=1059994

    Thanks for the test.

    Thus, I'm closing this bug.

    -- Spiro.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks