woods@eci386.uucp (Greg A. Woods) (10/27/90)
[ I've appended comp.terminals.tty5620 to the newsgroups line, which BTW, was "inadvertently" set to poster (though I didn't remove comp.graphics. The download-hang problem, in my experience, is common to other "blit" (or DMD) terminals. ] In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes: > We are having problems downloading a 630MTG application from a 3B2/500. > > Everything worked fine on earlier versions of the application. But > after adding more code, re-compiling, etc. the next download just > "hung." I'll try and describe the symptoms a bit better ... Your descriptions follow exactly with my experience with a tty5620 DMD terminal. The downloads, particularly of large programmes, periodically hang. On the 5620 the hung layer must be deleted, thereby killing the 32ld on the host. My most recent experience was with xproof, with which I would have to try three or four times consecutively before it succeeded. This seems to be a problem in either the download protocol, or in the xt(7) driver itself. This is the first time I've heard of this problem occuring on the 630's. On my 3b2/400, any burst of (integral) disk activity sharply increased the chances of failure. Even the disk activity associated with loading the 32ld programme, and the binary to be downloaded, was often enough to trigger a hang. Rumors have it that a re-implementation of 32ld done locally for 386 based machines doesn't experience these lock-ups quite so often. A significant number of people in the Toronto area will be running 5620's on a variety of systems in the near future. I'm sure we will be investigating this problem further. One task I've set for myself is to port dmdld to support the 5620 (i.e. to replace 32ld), and be portable across several host architectures. Since dmdld is in the 630-pkg stuff from the Toolchest, it will allow non-3b2 users (such as myself when I'm at the office :-) to benefit from the 5620 (and the [67]30-MTG's) (given they/I port the host-side software, and have a 5620/630 development package handy). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
wsinpdb@wsinfo13.info.win.tue.nl (Paul de Bra) (10/29/90)
In article <1990Oct26.201542.775@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes: >> We are having problems downloading a 630MTG application from a 3B2/500. >> >> Everything worked fine on earlier versions of the application. But >> after adding more code, re-compiling, etc. the next download just >> "hung." I'll try and describe the symptoms a bit better ... >... >This seems to be a problem in either the download protocol, or in the >xt(7) driver itself. This is the first time I've heard of this >problem occuring on the 630's. I know this won't help, but I spent a fair amount of my time drinking coffee while downloading large programs into a 630 during the past 2 years. I have used this 630 either connected to a Vax through a datakit node or a modem, and also connected to a 386 at 19200 baud through a straight cable. The Vax was running the Ninth (later Tenth) edition Unix, and the 386 was running AT&T sVr3.2u. All downloads were while in layers or 630mux. I have never ever had a hang, not even when downloading over a noisy phone line. This suggests that the problem may have been in the 3b2. (I have rarely used the 630 with a 3b2) Paul. (debra@research.att.com)