schoff@NIC.NYSER.NET (Martin Lee Schoffstall) (07/17/87)
I have two questions concerning the current (3.X) implementation: 1) does it still support the async tcp/ip code (ttylink in WIN/VX 2.2) 2) Does anyone have a DECNET async connection where they use DBRIDGE, and what is the performance like? Marty
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (07/22/87)
Dbridge in Version 2 of the code is abysmal. I don't know if it is fixed in 3.0 since I now have a real IP path between the two sites. It would be nice if Woolongong would take the effort of reversing this product (allowing DECNET to flow through their IP paths) but it probalby isn't an easy modification. -Ron
rick@ut-ngp.UUCP (Rick Watson) (07/23/87)
> Dbridge in Version 2 of the code is abysmal. I don't know if it is > fixed in 3.0 since I now have a real IP path between the two sites. > It would be nice if Woolongong would take the effort of reversing this > product (allowing DECNET to flow through their IP paths) but it probalby > isn't an easy modification. > > -Ron *Flame on* Saying that "Dbridge [...] is abysmal" is not really very informative. What specifically did you have problems with? *Flame off* We have been using DBRIDGE under v2.x (and now 3.0) with good performance under light to moderate usage (say 1-4 "active [currently transferring data]" circuits in/out of each node). Performance will (of course) be dependent on DECnet circuit speed and loading. Our topology looks like: 192.16.73---ether --+--128.83-----ether-+--------- | |... | | |... +---+ +---+ +---+ | | | | UTADNX | |--- 10 (arpanet) +---+ +---+ +---+ | | ---DECnet 192.16.72----- | | | | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +---+ +---+ +---+ with DBRIDGE/DECnet making the connections for the network 192.16.72 over serveral leased phone lines that run at 56KB, 230.4KB and ~760KB. The CPU overhead for the DBRIDGE process on UTADNX can get to be high if it is having to route too many packets on to 128.83 and beyond. It really needs to be a dedicated uVax. It would be nice if the DBRIDGE interface could live in the WIN/TCP kernel (like ELINK does now), instead of a user-mode process, but I have no idea if that is possible. Rick Watson University of Texas Computation Center arpa: ccaw001@utadnx.cc.utexas.edu rick@ngp.utexas.edu uucp: ...seismo!ut-sally!ut-ngp!rick bitnet: ccaw001@utadnx phone: 512/471-3241
leres@ucbarpa.Berkeley.EDU (Craig Leres) (07/27/87)
Dbridge exists because we wanted internet access from VMS system that only had a point to point interface which DECnet already had its claws in. But there were other VMS machines on our DECnet that did have internet access so we devised a way to take advantage of them. We knew from the start that dbridge would never be a speed demon; not only is the overhead for DECnet too great, but it generates lots of system calls and process context switches. Of course, the minute we got money to buy a DEUNA, we started running elink. But dbridge served us well until that happened. Craig