VOICE Home Page: http://www.os2voice.org

February 2003 [Newsletter Index] [Previous Page] [Next Page] [Feature Index] editor@os2voice.org

OS/2 Tips

We scan the Web, Usenet and the OS/2 mailing lists looking for these gems. Have you run across an interesting bit of information about OS/2 or eComStation recently? Please share it with all our readers. Send your tips to tips@os2voice.org. If you are interested in joining a particular OS/2 mailing list, check out the VOICE Mailing List page for subscribing instructions for a large variety of existing lists - http://www.os2voice.org/mailinglists.html.

Editor's note: these tips are from OS/2-eComStation users and in some cases can not be verified by myself. Please heed this as a warning that if you are not sure about something, don't do it.

I have the latest Java 1.3.1 configured as default JVM. Lately I have experienced problems with some Java GUI applications, e.g. jEdit, not receiving keyboard input. They either didn't get any key presses at all or some keys only. The mouse worked OK though. I have been able to solve this by clearing the CLASSPATH environment variable before starting them. So for jEdit the CMD file to start it would look like:

SET CLASSPATH=
java -jar jedit.jar -settings=%HOME%\.jedit -server=%HOME%\.jedit\server

I suspect that this may be a version conflict with the old Swing library.

Christian Hennecke

No it's there because someone at IBM thought it would be clever to test if you have an UHCI USB Controller in your system. So it doesn't check if the basic package is installed. It simply will only install on UHCI. One should adjust the ddp file to remove that stupid line and make sure the driver doesn't install backleveled (USBD.SYS USBUHCI.SYS) as I'm not sure if that thing comes with it's own set. good ole IBM ....

Sure 1.1 is Backward compatible. If you look at the device report of a printer with USBRES.EXE you see the Protocol the Interface reports. With 1.1 a 3rd Protocol was added which is : "1284.4 compatible bi-directional interface" What protocol an printer implements is up to the vendor. It is mainly useful for printers which have multiple functions, like built in scanner, fax etc. as you can can have multiple data streams to/from the functions going on at the same time. On USB one could have done that with simply using multiple interfaces 1 for each function but that would probably make the firmware more complicated exp if the device can also be connected via the parallel port.

You can redirect the output with:

warpvision.exe ...your_parameters... 1>1.txt 2>2.txt

now you get two textfiles.

1.txt contains info
2.txt contains error-messages

if you use

1>>1.txt

an

2>>2.txt

the output is appended and not overwritten

Franz

If you are using a SCSI card plugged into a "normal" 32 bit, 33MHz PCI slot then your maximum throughput is limited by the speed of the PCI bus and not by the speed of the SCSI bus. The theoretical maximum of a 32bit/33MHz bus is 132MB/sec but it achieves less than that in practice because of overheads - probably somewhere between 75% and 90% throughput (99-118MB/sec). This means that you will never see the full benefit of a U160 card so a U320 one will have its potential even more restricted. A 64bit/33MHz bus tops out at 264MB/sec which is enough for a U160 card but still restricts the potential of a U320 one. In order to think about realizing the full throughput of a U320 card then you'd need to be using it in a 64bit/64MHz PCI slot (max 528MB/sec). Slots like these tend to only be available on "server" class motherboards not on general desktop type mobo's.

Now think about the peripherals you aim to attach to the card. The fastest SCSI disk drive currently available according to storagereview is the Seagate Cheetah 15K.3 which pulls 76.4MB/sec from a sequential read from the beginning of the disk. Unfortunately, storagereview doesn't appear to give MB/sec values for non-sequential read requests (sequential read requests are not the most frequently used type unless you typically perform video editing or something along that sort of lines) but in general the transfer values for this type of test are *much* lower than for flat-out sequential i/o. The nearest I think we have to a test on OS/2 that would show the difference in speed between these two access patterns is the result returned by Kai Uwe Rommel's diskio for track 0 speed (sequential) and my "multirw" test that reads the files in a specified directory tree using multiple threads. I can't try this out on my SCSI system because it's RAID 5 and returns better results for the non-sequential case than it does for the sequential one! On my IDE system, testing a WD 120GB 5400rpm drive I get results of 27MB/sec for sequential and 7.5MB/sec for the multi-read test and I'd expect these sorts of results to be vaguely typical for any single disk drive - so about a 1/4 the speed when performing non-sequential i/o.

From these results, I'd say that the fastest SCSI disk available at present does not really stress an U160 card. It's only just faster than an ordinary Ultra2 card (80MB/sec). You'd have to have two of these devices attached to a U160 card and be performing simultaneous sequential i/o to both of them to stress it and you'd be hitting a 32bit/33MHz PCI bus limit before you hit the U160 limit.

[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org