lewin@peun32.UUCP (05/23/89)
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)ivar@acc.uu.no (Ivar Hosteng) (05/27/89)
> All works well except that once vpix is running xenix seem's > to get less than 10% of the time-slice?? > That's because VP/ix has to poll all devices that DOS is using. This takes a lot of time, and the result is that the rest of the system is suffering. I had the same problem myself but found no solution. > --> 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*! I'm not sure why this is happening, but I think it's the swapper that executes the VP/ix task and because it has a higher nice factor it is halted more often. You must remember that most of the Xenix tasks uses blocking I/O and thus is giving up the rest of its slice. Since VP/ix is polling all devices there is no way for the swapper to know when VP/ix is waiting for I/O. This makes the swapper execute VP/ix until its maximum time slice expires. > 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! The reason the system regains the speed when you switch to a new window is that when VP/ix is not in the current window it stops executing. This is in my opinion the weakest side of VP/ix and makes it unusable for my purposes. VP/ix runs fine on a external terminal but then you only get a monochrome screen. > Would appreciate any hints or advice. I have no solutions to your problem but I hope this explains why it goes so bad. Maybe someone at SCO is reading this and can give a more concise answer. Ivar Hosteng, Advanced Computer Consultans, Oslo, Norway - ivar@acc.uu.no
clewis@eci386.uucp (Chris Lewis) (06/09/89)
In article <105@accsys.acc.uu.no> ivar@acc.uu.no (Ivar Hosteng) writes: >> All works well except that once vpix is running xenix seem's >> to get less than 10% of the time-slice?? >That's because VP/ix has to poll all devices that DOS is using. This >takes a lot of time, and the result is that the rest of the system is >suffering. I had the same problem myself but found no solution. >> --> 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*! Question: Does your VP/IX appear to be accumulating CPU time faster than real time? You can prove that VP/ix polls simply by seeing if the process time via "ps" goes up even when your VP/ix session is simply displaying a DOS prompt. I was told (by an ISC employee) that the 386/ix scheduler attempts to circumvent the nastiness of VP/ix polling by artificially diddling the clock ticks being charged to the process. You see, most UNIX schedulers dynamically increase the priority of a process on each I/O that it performs, and decreases it proportional in some fashion to the CPU the process uses. Thus if you zap the process times in the proc area up, the priority will go down. Sort of ass-backwards if you ask me. At one time, (perhaps 386/ix 1.0.3 or ..4), there was a version of VP/ix that didn't poll. No CPU "leakage". Ran like a bat out of hell. Don't know why they went back to the polling version (presumably some brain-dead DOS application package requires it). Further, all should be aware that VP/ix is both a memory and CPU hog. As a general rule, you can get quite reasonable performance if you allow 1 megabyte of physical memory for each simultaneous VP/ix session, plus sufficient memory for the kernel (plus something for the UNIX processes to live in). On 386/ix, 2 VP/ix sessions aren't too bad in 4Mb (provided that the t'other guys aren't running cc, troff, rn, jove or perl). Things get much better when you get to 8Mb or more. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425