OpenCBM

Logged In: YES
user_id=1059994

Thanks for the test.

Thus, I'm closing this bug.

-- Spiro.

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

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

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.

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

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

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.

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.