Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy!usc!orion.cf.uci.edu!uci-ics!zardoz!tgate!irsx01!ka3ovk!drilex!axiom!linus!nixbur!nixpbe!peun32!lewin
From: lewin@peun32.UUCP
Newsgroups: comp.unix.xenix
Subject: Problems with vpix under xenix2.3.1
Message-ID: <42500001@peun32>
Date: 22 May 89 20:26:58 GMT
Lines: 50
Nf-ID: #N:peun32:42500001:000:1656
Nf-From: peun32.UUCP!lewin    May 22 15:07:00 1989


Hi net,

I am trying to do something very simple here on an AT running
SCO xenix 2.3.1 on a 80386. I'm running a graphic's based PC-
Package which requires DOS and GEM as it's foundation - and
usually would permit a serial-PC-Line to communicate with some
host system.

So what do we do? We start vpix and talk from DOS internally
to xenix via named pipes under the xenix-file-system. One for
input say z:/dev/pc2xnx and one for the reply z:/dev/xnx2pc.

All works well except that once vpix is running xenix seem's
to get less than 10% of the time-slice??

--> So, I though, start vpix with a *nice* setting!
    ie.: nice -7 vpix

Great! But now both seem to run in a burst fashion, ie. first
vpix is busy for say 7/10th's of a second then xenix? I can't
figure out what the hell is going on - it's almost like vpix
regularly say's *sleep 1*!

This simple test shows up the problem - perhaps some one out
there with a similar configuration could give this a try - and
offer some kind of explanation or consolation.

- login twice.
- in one window start vpix -> nice -7 vpix
- type the following in the other window:-
	while true
	do
	sync
	done

your fixed disk should start to regularlly flash - now switch
to the vpix window and observe what happens to the poor task
running in the back-ground. If you then switch to a new window
things work fine again - but as soon as you go back to the vpix
window the task in the back-ground becomes sluggish!

Would appreciate any hints or advice.

    ___
   /   )                 /
  /----  __      /      /    _        . __
 /      (_/_/_/_/_     /___ (-_/_,_/_<_/ /

 email: lewin.pad@nixpbe.uucp  (via eunet)