joakimf@sluga.UUCP (Joakim Fredriksson) (09/23/89)
I think I've seen something about this before. But at the time I didnt "need" the information. My experience is that when I'm running DESKview my diskdrive seem to operate slower. Well it just doesnt seem to run slower, I tried CORETEST on the drive and it reported that without DV it could read 666.0 KB/sec and with DV only 104.5 KB/sec. This is a real loss of performance in my book!!! Does anybody have a explanation to give me, maybe I've missed some- thing in the manual. I guess that the DV-people didnt make a program that should slow the computer. PS. The only program (partition) I had running was CORETEST DS. ------------------------------------------------------ - Jocke Fredriksson - - Swedish Univerisity of Agricultural Sciences - - Dpt of Operational Efficiency - - S-770 73 Garpenberg - - SWEDEN - - Internet: joakimf@sluga.se Tel:46/225/22100 - ------------------------------------------------------
palowoda@fiver.UUCP (Bob Palowoda) (09/24/89)
From article <170@sluga.UUCP>, by joakimf@sluga.UUCP (Joakim Fredriksson): > > > I think I've seen something about this before. But at the time I > didnt "need" the information. My experience is that when I'm running > DESKview my diskdrive seem to operate slower. Well it just doesnt > seem to run slower, I tried CORETEST on the drive and it reported > that without DV it could read 666.0 KB/sec and with DV only > 104.5 KB/sec. This is a real loss of performance in my book!!! This seems about the same results that I got. I looks like DV cannot distribute system resoures very well. Try running two or more disk tests or load three database programs at once. The system comes down to it's knee's. Running DOS under UNIX (with and ESDI) I got about 500k/bytes/sec. Under just dos I got about 990k/bytes a second. Running 4 cortest programs simultanous I got 400k/bytes a seconed in each dos session. Running 4 corestest in DV got a whopping 39k/bytes/sec. I seen the same results with Multi-Link/Lanlink. I haven't tested other dos multi-user programs. Another area of concern is high speed serial communications => 9600bps. I suspect something like DV to have a problem here also. Try running 4 19200bps lines on modems and see if you don't drop any characters. This is even a problem in unix machines sometimes. I don't think that any dos multi-taskers can have a scheduler that can prioritize on the type of task. > Does anybody have a explanation to give me, maybe I've missed some- > thing in the manual. I guess that the DV-people didnt make a program > that should slow the computer. No matter what multi-tasking-user software you run on one cpu it's going to slow the system down. You just want to find the one that performs the best for your needs. ---Bob -- Bob Palowoda packbell!indetech!palowoda *Home of Fiver BBS* login: bbs Home {sun|dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB Voice: (415)-623-7495 Public access UNIX XBBS
larry@nstar.UUCP (Larry Snyder) (09/24/89)
> Another area of concern is high speed serial communications => 9600bps. > I suspect something like DV to have a problem here also. Try running > 4 19200bps lines on modems and see if you don't drop any characters. I was running multiple high speed modems locked at 38400 under DOS and was dropping characters all the time until replacing the 16450s with 16550As and adding the 16550A driver. With the driver my 10 mhz 1 wait 286 at the time could support multiple transfers of 2510 cps at one time. -- Larry Snyder uucp: iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site Notre Dame, Indiana USA
slin@cory.Berkeley.EDU (Steven Philip Lin) (09/25/89)
In article <688@fiver.UUCP> palowoda@fiver.UUCP (Bob Palowoda) writes: >From article <170@sluga.UUCP>, by joakimf@sluga.UUCP (Joakim Fredriksson): >> >> >> I think I've seen something about this before. But at the time I >> didnt "need" the information. My experience is that when I'm running >> DESKview my diskdrive seem to operate slower. . . . In the back of the Desqview manual is a suggestion for improving the speed of file operations under Desqview. First, some background. The Desqview authors claim that file operations use DMA, but that expanded memory isn't compatible with DMA. As a result, all file operations under Desqview must be performed using conventional memory. Desqview is normally set up with a 2k buffer of conventional memory for such file operations. This buffer, however, may sometimes be too small. Now the solution. A way to improve the performance of file operations is to increase the size of this buffer. In the setup program for Desqview there is an option to change the DOS buffer for EMS. The option is located under the performance heading. The authors suggest increasing this buffer in 2 or 3k increments, though little is gained by increasing it beyond 30k. There is an exception to this suggestion. If you have an 80386 machine with QEMM-386 version 4.1 or later, set the DOS buffer for EMS to 0. Apparently the 386 is able to get around the limitation of requiring conventional memory for DMA transfers. All of this information was taken from the manuals of Desqview 386 v 1.0 (i.e. Desqview v 2.25 and QEMM-386 v 4.2).
mau@netcom.UUCP (Rich Mau) (09/26/89)
I assume that you are aware of the affects of interleave - as interleave gets
closer to 1:1 (i.e. sequential sectors adjacent) transfer rates get faster,
until the program does not request the next sector "soon enough", in which
case the disk drive must make a complete revolution before it can read the next
sector. Your setup may have this problem.
Also, some disk controller manufacturers that do data caching have "special
cased" the transfers that Core Test does. This causes very high transfer
rates to be reported by Core Test where much lower rates would be reported
for reads to another area of the disk.
********************************************************
* Rich Mau ...!{apple,amhdal}!netcom!mau *
********************************************************
--
********************************************************
* Rich Mau ...!{apple,amhdal}!netcom!mau *
********************************************************