jness@umn-d-ub.D.UMN.EDU (Joel Ness) (12/11/89)
We've just installed a NetSerial in a lab full of MacIIcx's to allow them to share an HP PaintJet. It seems to work quite well and is transparent to the user. You just select the HP driver in the chooser and leave it set for printing out the phone port (even though there is nothing hooked up to the phone port). The NetSerial driver intercepts anything sent out the phone port, bundles it up in AppleTalk packets, and shoots it out the printer port to the NetSerial device itself. The NetSerial device then unbundles the packets and prints right to the HP as though it was connected directly to the Mac. If you have more than one NetSerial on the network you can choose which one you want things to go to right from the chooser. These things are more commonly used to share a modem, and they can be set to modem pool--give you the next available modem if you have more than one available. All in all we're happy with it and it's given us a cheap solution for sharing a serial printer without burdening our students with using switchboxes, etc. Joel Ness INTERNET: jness@ub.d.umn.edu Information Services BITNET: JNESS@UMNDUL University of Minnesota, Duluth
klong@wilkins.bcm.tmc.edu (Kevin Long) (12/19/89)
In article <3074@umn-d-ub.D.UMN.EDU> jness@ub.d.umn.edu.UUCP (Joel Ness) writes: > > We've just installed a NetSerial ... > It seems to work quite well... > >Joel Ness INTERNET: jness@ub.d.umn.edu >Information Services BITNET: JNESS@UMNDUL Our experience with the NetSerial has been mixed, and I'd like to ask if anyone else has the problems we've had. We use our NetSerial to allow people to dial in from home into our AppleTalk network. Our basic setup is: Home -- Hayes 2400 -- phone -- Hayes 2400 -- Shiva -- Office User baud modem lines baud modem NetSerial Network People can call up from home and print small files to printers, etc, with no problem. But if we equip the home machine with TOPS and try to mount a volume at the office or use ncsa telnet to pull a file off of one of our unix hosts gatewayed through the office network's fastpath, the connection is inevitably dropped, sometimes after 5 minutes, sometimes after 10. Phone Line ========== We have great confidence in the quality of the phone connection--haven't logged a garbage character in 2 years. It's all within the same phone exchange, and most of the route is fiber. NetSerial ========= We sent in our NetSerial to have it upgraded and have installed the latest version of the NetSerial drivers as of Nov 1 on the relevant machines. We have also connected the NetSerial up to an ethernet-to-serial line multiplexor to have it act as a shared serial port onto our ethernet, and it's worked very well for everyone in the office in outbound mode, to access peripherals, to log in to machines, to kermit over files, etc. The software ============ We're running TOPS 3.0 on MacOS6.0.4, but have had the problem also with all previous TOPS versions we've happened to try. NCSA Telnet is the 2.3 TCP version. This software works fine among machines on the office network, and we're sure that everyone is running the same version of the software. The Modems ========== We're using Hayes-compatible 2400-baud modems, that have worked flawlessly in every other application over the past few years. We've also tried using Telebit T2500 9600-baud modems configured according to Shiva's instructions, but with identical results. The Office Network ================== Our conclusion: the NetSerial is unreliable in this scheme. It is dropping the line. Is anyone else having these experiences? Kevin Long Baylor College of Medicine klong@bcm.tmc.edu
john@trigraph.uucp (John Chew) (12/20/89)
In <1861@gazette.bcm.tmc.edu> klong@wilkins.bcm.tmc.edu (Kevin Long) writes: >People can call up from home and print small files to printers, etc, with >no problem. But if we equip the home machine with TOPS and try to mount >a volume at the office or use ncsa telnet to pull a file off of one of >our unix hosts gatewayed through the office network's fastpath, the >connection is inevitably dropped, sometimes after 5 minutes, sometimes >after 10. ... > Kevin Long > Baylor College of Medicine > klong@bcm.tmc.edu I knew there had to be someone else out on the net with the same problem. We have tried several times to get a similar system working. We run 6.0.3 instead of 6.0.4, have used T-2500's exclusively, and are using TeleBridges instead of NetSerials, but we kept running into the same problem. Shiva tech support acknowledges that several users have reported similar problems, but have never been able to duplicate the problem in-house due to their lack of appropriate hardware (a FastPath box). The problem does not occur if nothing is running across the connection, but if a Telnet is running, the connection dies after a variable amount of time (usually several minutes). I noticed that if you can catch your local TeleBridge just after it goes catatonic but before it dies completely, sending it any sort of ZIP request wakes it up. Our local workaround therefore was a DA that users could leave running that would do a GetZoneList once a minute. John -- john j. chew, iii phone: +1 416 425 3818 AppleLink: CDA0329 trigraph, inc., toronto, canada {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john dept. of math., u. of toronto poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca}
tom@wcc.oz (Tom Evans) (12/20/89)
In article <1861@gazette.bcm.tmc.edu>, klong@wilkins.bcm.tmc.edu (Kevin Long) writes: > Our experience with the NetSerial has been mixed, and I'd like to ask if > anyone else has the problems we've had. > People can call up from home and print small files to printers, etc, with > no problem. But if we equip the home machine with TOPS and try to mount > a volume at the office or use ncsa telnet to pull a file off of one of > our unix hosts gatewayed through the office network's fastpath, the > connection is inevitably dropped, sometimes after 5 minutes, sometimes > after 10. I've had people with similar problems with other serial link hardware and software, specifically running one of the electronic mail packages. They find that short messages are fine, but long ones die. How long is long? About 2000 characters or so. The following from 2 months ago gives a good explanation of a possible reason: Note that this addresses AppleShare, but applies to all programs that use AppleTalk's Transaction Protocol (ATP) - this is most of them. Note (for explanation) that a BIG data request on ATP looks like: Req. Device: [Request] Rsp. Device: [RSP1] [RSP2] [3] [4] [5] [6] [7] [8] so there are from 1 to 8 response packets (568 bytes each). This depends on how much data was asked for. Anyway, the article: > Date: 17 Oct 89 03:32:00 GMT > Sender: daemon@ucbvax.BERKELEY.EDU > Organization: The Internet > Lines: 28 Does anyone have a fix for this piece of Apple stupidity? Externally it appears that the AppleShare code uses the following retransmission scheme: During the server signon the user MAC sends a full size echo packet and records the elapsed time until the reply. This time is then 2 times the one way packet time. It doubles this and uses that as the ATP timeout time. It is now 4 times the one way packet time. It then sends an 8 packet ATP request with a 4 packet time timeout. Guess what happens. While the 5th packet is coming in it asks for a resend of the last 4 packets. Now things really go to H... in a Handbasket. It uses the first copy of the last 4 packets and requests the next group of 8. Those 8 end up behind the second copy of the last 4 packets. Timeout, Timeout, Timeout ... We informed Apple of this problem over two years ago. To err is human but not to be able fix one's mistakes is stupidity. Does anyone know where the 2 is that is used for the doubling? I would like to change to about 8. PS. Many thanks to Jim Bruyn, Computer Systems Group, University of Waterloo for the ResEdit location of the Broadcast retry interval. --------- Other articles that followed this said where the "2" is and how to patch it. Do Shiva give you in INIT or something to drop in your System folder to patch these numbers for you? --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby, Melbourne 3179 | approximation" Victoria, Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832