HECnet

hecnet@lists.dfupdate.se

15586 discussions

Introducing myself... and my little network

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong Sent: 08 June 2012 23:58 To: hecnet at Update.UU.SE Subject: RE: [HECnet] Introducing myself... and my little network On 06/08/2012 03:53 PM, Rob Jarratt wrote: I was once told that a TF series drive might be able to read past the error, but that TKs won't. FWIW, The TFxx drives have DSSI interfaces. The TZ drives are SCSI (e.g. TZ85 or TZ87). The TK drives (TK50, TK70) have DEC proprietary interfaces. A TF8x drive isn't going to do you any good unless you have a MicroVAX with a DSSI controller - Yes, I have two machines with DSSI. a TZ8x drive can at least be connected to any VAX or PDP with SCSI. AFAIK there isn't any difference, other than the interface, between a TF85 and a TZ85, or a TF87 vs TZ87. I don't think there's such a thing as a TK85 or TK87 - DEC dropped the proprietary interface after the TK70s. And I don't think there were any DSSI drives after the TF87. I know I have a TZ85 or TZ87 (maybe even both) somewhere but whether it's any better at reading bad TK50s I won't even speculate. BTW, If anybody has a TF drive that they'd like to swap for a TZ, let me know. I've got a rack of DSSI drives (RF7x and RF3x) that'd love to have a little tape drive for a cousin :-) I too would like to find any TF or RF drives, also would like to find a KFQSA so I can try out my KA655 CPUs. Regards Rob

13 years, 6 months

Introducing myself... and my little network

by bob＠jfcl.com

On 06/08/2012 03:53 PM, Rob Jarratt wrote: I was once told that a TF series drive might be able to read past the error, but that TKs won't. FWIW, The TFxx drives have DSSI interfaces. The TZ drives are SCSI (e.g. TZ85 or TZ87). The TK drives (TK50, TK70) have DEC proprietary interfaces. A TF8x drive isn't going to do you any good unless you have a MicroVAX with a DSSI controller - a TZ8x drive can at least be connected to any VAX or PDP with SCSI. AFAIK there isn't any difference, other than the interface, between a TF85 and a TZ85, or a TF87 vs TZ87. I don't think there's such a thing as a TK85 or TK87 - DEC dropped the proprietary interface after the TK70s. And I don't think there were any DSSI drives after the TF87. I know I have a TZ85 or TZ87 (maybe even both) somewhere but whether it's any better at reading bad TK50s I won't even speculate. BTW, If anybody has a TF drive that they'd like to swap for a TZ, let me know. I've got a rack of DSSI drives (RF7x and RF3x) that'd love to have a little tape drive for a cousin :-) Bob

13 years, 6 months

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/08/2012 03:53 PM, Rob Jarratt wrote: I have a TK50 cartridge that I have been trying to read for some time, it keeps failing at a single point. I was once told that a TF series drive might be able to read past the error, but that TKs won't. I don't know how much truth there might be to it, but I have been trying to find a TF drive for a long time, they just don't seem to come up. Are they as rare as they seem? I didn't think they were all that rare, but now that you mention it, I have seen many more TK50s and TK70s than Tx85 drives. Not sure why. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 22:07, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:36 PM, Johnny Billquist wrote: On 2012-06-08 21:28, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: ... If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. Right. But there are some interesting passages in the manual. " More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA. In DEQNA-lock mode the specifications of multiple physical Ethernet addesses will cause the DELQA to filter all such physical Ethernet addesses for packet reception. NOTE Enabling more than one physical address is not recommended under normal circumstances. This may have a substantial impact on performance. " What do you make of that? Johnny Hm. I wonder if the LQA uses a chip that doesn't natively support multiple MAC addresses (LANCE is one such, I think). If so, it would mean that it would have to emulate this QNA feature by setting promiscuous mode on that chip and doing the 16-entry exact filtering in firmware. Well, we *know* that the LQA uses the LANCE, so I guess that answers that question. Sounds reasonable that the LQA emulates the QNA by always placing the ethernet in promiscuous mode, if the QNA works the way you describe. Bummer. That would imply that QNA actually has some benefits over LQA, which I didn't expect. :-) I wonder if "substantial" is actually true. As I mentioned, the multiple individual address feature was introduced to allow LAT not to be broken by DECnet startup, so any OS that starts LAT before DECnet (VMS is one such, I think) would end up with multiple MAC addresses. And since the main reason for LQA was to make Local Area VAXclusters work right, one would assume the performance impact from this mode is not that high, since clusters are rather picky about performance issues. Thinking about it, in combination with what you wrote, I'd say yes, if you really put several physical addresses in the table. However, a) I don't expect VMS to run a LQA in QNA mode when it can perform much better in LQA mode, and b) I don't expect (even on VMS) that LAT is started before DECnet, or that LAT would not survive a change of MAC address after the start. I know that normally I always start LAT after DECnet on my VMS boxen, but on the other hand, there is no place in the provided templates where LAT is started, so it could go anywhere. Johnny

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 3:36 PM, Johnny Billquist wrote: On 2012-06-08 21:28, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: ... If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. Right. But there are some interesting passages in the manual. " More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA. In DEQNA-lock mode the specifications of multiple physical Ethernet addesses will cause the DELQA to filter all such physical Ethernet addesses for packet reception. NOTE Enabling more than one physical address is not recommended under normal circumstances. This may have a substantial impact on performance. " What do you make of that? Johnny Hm. I wonder if the LQA uses a chip that doesn't natively support multiple MAC addresses (LANCE is one such, I think). If so, it would mean that it would have to emulate this QNA feature by setting promiscuous mode on that chip and doing the 16-entry exact filtering in firmware. Bummer. That would imply that QNA actually has some benefits over LQA, which I didn't expect. I wonder if "substantial" is actually true. As I mentioned, the multiple individual address feature was introduced to allow LAT not to be broken by DECnet startup, so any OS that starts LAT before DECnet (VMS is one such, I think) would end up with multiple MAC addresses. And since the main reason for LQA was to make Local Area VAXclusters work right, one would assume the performance impact from this mode is not that high, since clusters are rather picky about performance issues. paul

13 years, 6 months

Introducing myself... and my little network

by robert.jarratt＠ntlworld.com

I have a TK50 cartridge that I have been trying to read for some time, it keeps failing at a single point. I was once told that a TF series drive might be able to read past the error, but that TKs won't. I don't know how much truth there might be to it, but I have been trying to find a TF drive for a long time, they just don't seem to come up. Are they as rare as they seem? Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 08 June 2012 08:57 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Introducing myself... and my little network On 06/08/2012 03:55 AM, Johnny Billquist wrote: I haven't tried cleaning TK50 heads in years, but I will (now that I have a more respectable workspace) start trying that. I will let you know how things go. I'll probably start digging into those within the next month or two. Thank you for the suggestion! I take it TK50 tapes won't read in a later drive? They will. TK70 and TK85 (if I remember right) can both read TK50. You also have the TZ30 (I think the name is), which is a TK50 compatible, but smaller drive, with SCSI. The TK85 can read TK50s? I didn't know that! If that's the case, it's likely that the TF85 (DSSI version) may as well, and I have one of those. That may be one more option to get my huge pile of TK50s read. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 6 months

Introducing myself... and my little network

by jg＠jordi.guillaumes.name

Al 08/06/12 08:22, En/na Peter Lothberg ha escrit: I've got also some emulated PDP10 which I've not networked (yet). I'm having trouble plugging into DECNET a TOPS20/Panda machine... If someone could point me to any docs I would appreciate it a lot Does Ethernet-Multicast get set up correclty on your host? Well, after struggling all day with those machines, I've got both the TOPS20 and TOPS10 KHL10 systems visibles from DECNET. So those machines are now in HECnet as nodes 6.78 (BITXT2) and 6.80 (BITXT1). Don't ever try to find logic in my node number assignement. It used to be rational, but right now is a mess... :) To cut the story short, I run the KLH10s inside a virtualbox VM instead of running them in bare metal. Why? Two reasons: for some reason the dte interface gets wedged when I run it on iron, and second, that's the way I can assign a dedicated ethernet adapter for each instance. The problem was that KLH10 failed to set up the interfaces to promiscuous mode, and failed also to change the hardware address. I "fixed" it doing it before firing the emulator, using ifconfig. Now both machines can set up DECNET and it seems to work. Things to be fixed, or learnt yet: 1) Defining the permanent node database for both TOPS10 and TOPS20. NCP rejects the DEFINE NODE commands. I guess there is some sort of utility like the one in RSX (CFE) to define the "permanent" node list, but I've not been able to find that one. There is a NIPGEN in TOPS-10 to build a CMD file with the SET NODE commands, but no NIPGEN in TOPS-20 that I've been able to find... 2) LAT. LAT works fine in TOPS-20. In TOPS-10 LCP tells me LAT is active, but it does not work (does not even announce itself). How do I enable LAT in TOPS-10? 3) And, spealking of LAT... How do I change the service identification in TOPS-20? I mean, how do I change it PERMANENTLY? I guess I have to put it in some sort of auto-executing file. SYSTEM.CMD? Something in 7-1-CONFIG.CMD? Again, any pointer to docs would be very appreciated. I don't want to bug you with the thousands of questions I've got :) 4) A few minutes after startup of TOPS-10. I get the following message at the console: CCPOEF Output error on DSKB:SER001.EXE[10,1], status=40017 It does not seem to have any advert effect, but I'd like to know what's wrong. I've not seen such a message in my KS-based TOPS-10 running under SIMH. Now, I've got to install in the KLH10 TOPS-10 all the stuff I've got... :) That will keep me busy for a while.

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 21:28, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: On 2012-06-08 19:02, Paul_Koning at Dell.com wrote: ... Thanks for making me re-read the DELQA manual again. :-) You're very welcome! I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this. But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy... Johnny QNA, yes -- it was abandoned after revision L still didn't work right. LQA is a completely new design that does work, but it is compatible at the driver level with QNA (or nearly so). There are bugs in the LQA as well. But yes, it is a totally different design than the QNA. The address match is really very simple. There are no bugs here... the hardware has a 16 entry table and it accepts packets whenever the DA matches any of the 16 entries (essentially a 16 entry CAM). There are no "valid" bits (as you might find in some more advanced CAMs) so it treats all 16 entries as meaningful addresses. That means you have to fill in all 16. Yes. If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. Right. But there are some interesting passages in the manual. " More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA. In DEQNA-lock mode the specifications of multiple physical Ethernet addesses will cause the DELQA to filter all such physical Ethernet addesses for packet reception. NOTE Enabling more than one physical address is not recommended under normal circumstances. This may have a substantial impact on performance. " What do you make of that? Johnny

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 8, 2012, at 3:18 PM, Johnny Billquist wrote: On 2012-06-08 19:02, Paul_Koning at Dell.com wrote: ... Thanks for making me re-read the DELQA manual again. :-) You're very welcome! I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this. But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy... Johnny QNA, yes -- it was abandoned after revision L still didn't work right. LQA is a completely new design that does work, but it is compatible at the driver level with QNA (or nearly so). The address match is really very simple. There are no bugs here... the hardware has a 16 entry table and it accepts packets whenever the DA matches any of the 16 entries (essentially a 16 entry CAM). There are no "valid" bits (as you might find in some more advanced CAMs) so it treats all 16 entries as meaningful addresses. That means you have to fill in all 16. If you don't need 16 distinct values, you simply pad the table with extra copies of any of the meaningful values; that way the result is what you want. The easiest way to do that is to make extra copies of the entry that specifies the MAC address, but that isn't necessary, it is mentioned only because it's easy to remember. paul

13 years, 6 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 19:02, Paul_Koning at Dell.com wrote: On Jun 8, 2012, at 10:50 AM, Johnny Billquist wrote: On 2012-06-08 16:42, Paul_Koning at Dell.com wrote: ... That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do. Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway. A typical modern NIC has (a) a modest-sized list of exact match filters, (b) a hash (CRC) based multicast filter, and usually (c) a separate flag to enable broadcast. So if you have at most, say, 16 unicast + multicast addresses enabled, it uses (a); if you have at most 16 unicast but too many multicast addresses, it uses (b) to do an approximate filter of the multicasts with the exact match done in the driver, and if you ask for more than 16 unicasts it will tell you that it can't do that. I have forgotten most of what I might have known of modern NICs, I think... The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address. (Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...) Johnny That's not quite true. DEC, not surprisingly, was the first to identify the need for multiple unicast support in NICs, so the DECnet Ethernet datalink spec calls for it and all except the very oldest DEC NICs support that. Specifically, QNA and LQA do, because they take a 16 entry address filter. The QNA manual says that you put in the MAC address, broadcast, multicast addresses, plus extra copies of the MAC address, but in fact the device is perfectly happy to accept additional individual addresses. I believe VMS (and possibly other OSs) took advantage of this to allow LAT to come up first with the ROM based MAC address, then enable DECnet with its address without disturbing LAT. Thanks for making me re-read the DELQA manual again. :-) I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this. But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy... Johnny

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet