HECnet

hecnet@lists.dfupdate.se

5 participants
15588 discussions

by Paul_Koning＠Dell.com

On Jan 7, 2013, at 1:52 PM, Ian McLaughlin wrote: Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? The internal net at DEC was seriously out of addresses, though just like IP that's partly because the addressing scheme forced it to be somewhat sparse. Still, there were certainly tens of thousands of nodes on it. paul

13 years

Area 48.....

by b4＠gewt.net

On 7 Jan 2013, at 13:59, Ian McLaughlin <ian at platinum.net> wrote: On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote: What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff. Ah, I probably couldn't use it on my stuff then. Ian

13 years

Area 48.....

by ian＠platinum.net

On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote: What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff. Ian

13 years

Area 48.....

by b4＠gewt.net

On 7 Jan 2013, at 13:52, Ian McLaughlin <ian at platinum.net> wrote: Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? I wonder if HECnet has overtaken it in size. ;) Ian p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy? What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote: Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years

Area 48.....

by ian＠platinum.net

Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? Ian p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy? On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote: Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years

Area 48.....

by sampsa＠mac.com

Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years

DMC11 in next simh version... looks nice, and question about TOPS-10

by Paul_Koning＠Dell.com

On Jan 6, 2013, at 8:55 PM, Gerardo Cacciari wrote: On Sat, 5 Jan 2013 01:31:36 +0000, you wrote: Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its implementation of property 3). That's required -- all DECnet protocols are packet oriented and packet boundaries are meaningful. There are no byte stream protocols in DECnet -- TCP is the only protocol among all the networking protocols I know of that made that horrible design error. Sorry to bother you, but right in these days I'm reading and learning something more about transmission protocols (such as BSC, SDLC, and DDCMP), and your statement about that TCP design error tickled my curiosity. I know that BSC and DDCMP can be defined as character oriented protocols, while things like SDLC (and all its derivatives) are bit oriented; there are other differences but this is the most striking one. But let's not digress. I'd relate TCP to DECnet NSP, rather than to DDCMP, and if I'm not wrong both protocols (and DDCMP too) have variable length packets, according to how much data they have to send at the moment. So, can't they both be defined byte stream protocols? Or maybe are you referring to the fact that while NSP and DDCMP have a per-packet acknowledgement, TCP acknowledges single bytes and so can theoretically acknowledge just the first N bytes of a given packet? Yes, TCP has variable length packets, as do the other protocols. The essence of "stream oriented protocol" is not in the packet format. Instead, it is in the definition of the service provided to the application. In TCP, the service provided is a stream of bytes delivered to the other end. The stream has no structure. In every other networking protocol (including, ironically, UDP) the service provided is delivery of a sequence of packets to the other end. A packet is a number of bytes AND a specific packet boundary. For example, if in TCP I send 10 bytes then 20 bytes, the receiver may see 30 bytes delivered all at once, or a delivery of 5 bytes followed by 25 bytes, or 6 deliveries of 5 bytes each. Some of those are not likely in practice, but all are valid. On the other hand, in DECnet (or UDP, or ISO transport) if I send a 10 byte packet then a 20 byte packet, the receiver sees a 10 byte packet followed by a 20 byte packet. Nothing else is possible. All applications need structured data of some sort. So what happens is that every application has to make up for the fact that TCP doesn't do a packet service by layering a packet delimiting scheme on top. Often that comes in the form of a header that contains a data length, then you count off that many bytes, and then you look for another header. If you ever get out of sync, you end up looking for a header in the wrong place and the protocol won't recover until you close the connection and restart. Also, in the real world under the covers, you always have packets. So you would think that in reality, a high speed application (like iSCSI) could just assume that its headers are always found at the start of TCP buffers. And yes, that's a valid optimization, but you can NOT rely on that being true 100% of the time, because it's only a "likely" behavior, not a guarantee that's part of the TCP service definition. By contrast, if you implemented iSCSI on top of DECnet, or OSI, you would simply have the iSCSI PDUs starting at the start of a transport layer SDU, and this whole mess would disappear. Your code would be much smaller and more reliable because you no longer have to allow for the "unlikely" case of application PDUs starting in the middle of a TCP data delivery, or worse yet, straddling a boundary. Incidentally, there's a successor to TCP called SCTP that has packet service, and it would be a great solution to all this if only it were in general use -- but it isn't. paul

13 years

DU11 vs. DUV11

by bqt＠softjar.se

On 2013-01-06 22:06, Steve Davidson wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Sunday, January 06, 2013 15:54 To: hecnet at Update.UU.SE Cc: John Wilson Subject: Re: [HECnet] DU11 vs. DUV11 On 2013-01-06 21:47, John Wilson wrote: I still can't find where it says "8085A" in the 110/130 manual, but page B-3 gives I/O page timings and mentions an "I/O microprocessor" and the fact that word I/O takes 90 usec but byte I/O takes 180 usec. So that certainly explains the difference in the DUV driver. Plus the manual specifically says that RSX11S is available for the /110, so I guess it was even supported! Sweet. Also mentioned on page 4-6, but pretty much with the same level of detail. Byte writes cause a read-modify-write. Time of 180 usec. And there is an (unmentioned) 8-bit microprocessor acting in between the PDP-11 and any peripherials. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol I just found my VT103 LSI-11 Video Terminal User's Guide. The beast looks like a VT100 but has dual, count them dual, TU58's in the front and a 4x4 18-bit backplane in the back. Typical configuration (slot-wise) is: 1 - LSI-11 Processor 2 - MSV11-DD memory 3 - DJV11-J (4-channel serial line interface) Or 1 - LSI-11 Processor 2 - MVX11-A memory and serial in/out The bus slots are numbered from 0-7. I will look for my PDT documentation a little later. I am cleaning up that part of the basement now anyway. I actually have a couple of VT103, but I've never laid my hands on any PDT-11, which is why I (obviously) don't know enough about them. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

13 years

DU11 vs. DUV11

by jeep＠scshome.net

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Sunday, January 06, 2013 15:54 To: hecnet at Update.UU.SE Cc: John Wilson Subject: Re: [HECnet] DU11 vs. DUV11 On 2013-01-06 21:47, John Wilson wrote: I still can't find where it says "8085A" in the 110/130 manual, but page B-3 gives I/O page timings and mentions an "I/O microprocessor" and the fact that word I/O takes 90 usec but byte I/O takes 180 usec. So that certainly explains the difference in the DUV driver. Plus the manual specifically says that RSX11S is available for the /110, so I guess it was even supported! Sweet. Also mentioned on page 4-6, but pretty much with the same level of detail. Byte writes cause a read-modify-write. Time of 180 usec. And there is an (unmentioned) 8-bit microprocessor acting in between the PDP-11 and any peripherials. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol I just found my VT103 LSI-11 Video Terminal User's Guide. The beast looks like a VT100 but has dual, count them dual, TU58's in the front and a 4x4 18-bit backplane in the back. Typical configuration (slot-wise) is: 1 - LSI-11 Processor 2 - MSV11-DD memory 3 - DJV11-J (4-channel serial line interface) Or 1 - LSI-11 Processor 2 - MVX11-A memory and serial in/out The bus slots are numbered from 0-7. I will look for my PDT documentation a little later. I am cleaning up that part of the basement now anyway. -Steve

13 years

DU11 vs. DUV11

by lee.gleason＠comcast.net

You must be talking of the PDT-11/150 then. The /110 and /130 sat inside a VT100 shell. Extremely similar to a VT103 (I actually never figured out what the difference between a VT103 and a PDT-11/130 is.) I may be grossly misinformed, but my understanding is that although the /110 and /130 both live inside a VT100, they're *not* like VT103s, and have no Q-bus but use a custom CPU board just like the /150 (I doubt it's the exact same board, but a similar design). I could have sworn the 110/130 manual on bitsavers (which is misfiled away from the 150 manual -- I forget where) said so but on a quick skim I can't find it. The I/O hardware has enough programming differences that it can't be regular Q-bus stuff, although I suppose they could have made a whole set of PDT-specific boards. Yes, I think that's the case. I found a paragraph in the PDT 11/130 manual that states that the PDT family all have "bounded bus" systems that are completely buried in the PDT card, and an 8 bit processor actually talks to the IO devices. It also says that a word transfer to the IO system takes 90 microseconds, and a byte transfer takes 180 seconds, so that explains the logic behind the optimization. I never thought of any of them running any type of RSX - I ll have to dust off one of my PDT-11/150s and see if I can get some sort o' RSX on it. -- Lee K. Gleason N5ZMR Control-G Consultants lee.gleason at comcast.net

13 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet