HECnet

hecnet@lists.dfupdate.se

4 participants
15588 discussions

by mcguire＠neurotica.com

On 01/09/2013 02:34 PM, sampsa at mac.com wrote: Anyone have one of these handy - the one on RHESUS is corrupted.. http://www.neurotica.com/misc/ALPHAF084.IMG (I'm pretty sure that's the right file) Please let me know when you have it so I can remove it from the server. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years

HECnet performance....

by sampsa＠mac.com

The output format of the mapper is very simple, and we plan to run it like once a week, max. So if people in non-auto-mappable areas just send me their info in the relevant format, I can use that to complete the map. sampsa On 9 Jan 2013, at 21:16, Johnny Billquist <bqt at softjar.se> wrote: On 2013-01-09 20:10, Peter Lothberg wrote: solution. Be it Ciscos, Multinet on VMS, or Rob's user level router... Do ROB.s user level router do the upper layers, NML? -P (I;m thinking solving the problem with cisco's that don't respond to "Tell".) Nope. Same issue as with the Ciscos... I think we need some other kind of solution than a pure automated mapper in order to figure things out, although more than currently is done through NML could probably be done. Johnny

13 years

VMS 8.3 / 8.4 AXP installer ISO?

by sampsa＠mac.com

Anyone have one of these handy - the one on RHESUS is corrupted.. sampsa

13 years

HECnet performance....

by Paul_Koning＠Dell.com

On Jan 9, 2013, at 9:06 PM, Peter Lothberg wrote: Keep in mind, on here you've got 600MHz Alphas (performance like a 2.5GHz x86 box but with better I/O) and you've got emulated VAXen running on 700MHz ARM processors...which do you think will be faster? ;) -Dave I think we are more limited by the protocol itself, they where not thinking gigabit networking, packet size and number of outstanding packets (window size) is a limitation here that processor speed can't help. Remember, this is pre-tcp, pre van j protocols, and maybe to heavily influenced by X.25. (Connection oriented conection less, or was it the other way around..) Whoa, not so fast. Some people might not appreciate it if you compare DECnet with X.25. A bunch of TCP/IP technology actually comes from DECnet. There's OSPF, of course (which came from OSI IS-IS, which came from DECnet Phase V). Also, a fair amount of congestion control work started at DEC. That's why there is the "DEC bit", the nickname for the congestion notification flag that figures in a number of congestion control schemes (originally added in DECnet based on the work of K.K. Ramakrishnan). For that matter, some of the "slow start" congestion control approaches also were originally done at DEC, by Raj Jain. Connection oriented and connectionless: DECnet in that respect (on Ethernet) is exactly like TCP/IP. Yes, point to point datalinks are connection oriented; that was necessary in the early days (not for IP since it only used expensive links). And besides, it doesn't cost much there. One example why you shouldn't mention X.25 is that NSP, like TCP, uses a 3-way connection establishment handshake. X.25 has a two way handshake, a serious design error it copied from HDLC. In some ways DECnet is better than TCP, for example the application addressing being separate from the NSP connection endpoint addressing (object numbers vs. connection numbers), where TCP uses the same for both. As a result, connection lookup is dramatically more efficient in NSP. You're right that NSP has limited window size compared to TCP. More precisely, TCP with window scaling. If DECnet had lived long enough, it would presumably have had a window scaling option too. Another example is, how do DECnet figure out the MTU? It takes the max packet size of the two endsystems and uses the lowest of the two numbers. If there is a node in the middle with a smaller MTU it will retransmitt for ever. MRC (rip) ported DECnet to the DEC2020, where for reasons you only have one page (512words) to store 4 packets from the KMC/DUP. So it's not 576, it's 360 (something).. So having a 2020 with two serial ports and DECnet acting as a routing-4 node broke most connections... True. DECnet is a private network technology, so the assumption is that it can rely on correct management of the routers. And MTU size is one of the things assumed to be done right. DEC's network for a long time used 576 as its MTU; I would assume even a 2020 can be set that way, how else could such a node have existed on the DEC Easynet? paul

13 years

HECnet performance....

by setala＠gmail.com

This is getting interesting, but I only have DC PSU's on my personal "Lab" GSR and don't have any DC power source.. Well, maybe I have to dive into the company dumpster and find more suitable box.. --Saku On Wed, Jan 9, 2013 at 7:10 PM, Peter Lothberg <roll at stupi.se> wrote: > solution. Be it Ciscos, Multinet on VMS, or Rob's user level router... Do ROB.s user level router do the upper layers, NML? -P (I;m thinking solving the problem with cisco's that don't respond to "Tell".)

13 years

HECnet performance....

by bqt＠softjar.se

On 2013-01-09 20:10, Peter Lothberg wrote: solution. Be it Ciscos, Multinet on VMS, or Rob's user level router... Do ROB.s user level router do the upper layers, NML? -P (I;m thinking solving the problem with cisco's that don't respond to "Tell".) Nope. Same issue as with the Ciscos... I think we need some other kind of solution than a pure automated mapper in order to figure things out, although more than currently is done through NML could probably be done. Johnny

13 years

HECnet performance....

by roll＠Stupi.SE

solution. Be it Ciscos, Multinet on VMS, or Rob's user level router... Do ROB.s user level router do the upper layers, NML? -P (I;m thinking solving the problem with cisco's that don't respond to "Tell".)

13 years

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by mcguire＠neurotica.com

On 01/09/2013 01:57 PM, Johnny Billquist wrote: ...and like this from NCP under VMS: NCP> connect node gw physical address <MAC address> via <circuit-name> Note that the MAC address must have its octets delimited by colons under Linux, and hyphens under VMS. NCP>connect node gw physical address AA-00-04-00-01-F4 via ISA-0 Console connected (press CTRL/D when finished) User Access Verification Username: NCP> Uhhh...HOLY CRAP! That works from outside my network?! Is it working because you specified the circuit which gave it a path, or because it gleaned the DECnet area/node address from the (changed-by-DECnet) MAC address? I'm guessing the latter. (Peter?) It works on any LAN, including across bridges, so the various Internet based bridges we have make this work over some distance. The communication is via MOP remote console packets, which are not routed (just like LAT). The addressing is direct to the MAC address, whatever that happens to be at the destination. If the node you want to talk to supports MAC address aliases, the original address might work, but in any case the DECnet style Ethernet address will work. That was my belief before five minutes ago, when Brian was messing with me and got me all excited. I was certain that MOP was an unroutable, LAN-only protocol like LAT. But then, apparently folks have been booting DECservers via HECnet..? Nothing strange with that. The bridge makes it appear as if you are on the same ethernet segment. That makes sense...This will only work over bridged links, though. My Cisco GRE link (for example, in my configuration) should not propagate that traffic. (and if it does, is anyone else seeing my LAT service announcements? ;)) If (say) Brian and I were to create bridge-groups in our IOS configs that bridge across our Ethernet segments and the tunnel interfaces, that should work. I'm not too interested in doing that (it'd be lots of traffic) but I'd expect it to work. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years

HECnet performance....

by bqt＠softjar.se

On 2013-01-09 19:33, Dave McGuire wrote: On 01/09/2013 12:11 PM, Cory Smelosky wrote: I would like to identify what results in me having rather low FAL access speeds, however. I don't know if my network is misconfigured, or if it's just a result of using real hardware on a remote node. Nearly all of the real hardware that I'm aware of on HECnet is actually very fast; significantly faster than pretty much any emulated system. The slowest system I'm aware of on here is my PDP-11/53. Keep in mind, on here you've got 600MHz Alphas (performance like a 2.5GHz x86 box but with better I/O) and you've got emulated VAXen running on 700MHz ARM processors...which do you think will be faster? ;) Still, really abmysal network file transfer speeds can happen for reasons that can be improved. Johnny

13 years

HECnet performance....

by bqt＠softjar.se

On 2013-01-09 19:20, Peter Lothberg wrote: Also, the metrics are set on the circuit, and not individual destinations. While this worked more or less ok for DEC back in the day, with the bridge, the cost of two different destinations over the same circuit could in reality be very different. Bridged ethernet is a BAD thing for most protocols. And if you use spanning tree, it's not making optimal use of the topology. Totally agree. Radia finally came around and "Trill" is a routed network to carry ethernet frames. Hmm. Interesting. Might be something to look at, if I ever get plenty of time... As the cost/hop is in the routing vectors being sent periodiacally, you could implement a "cost/hop" NAT (half nat, one half on send one half on receive and some protocol to exchange how you want the metric matrix to look). That could be interesting, but since I don't expect us to fool around with the DECnet protocols as such, I guess this will not happen. Using dedicated routers that can tunnel traffic is really the best solution. Be it Ciscos, Multinet on VMS, or Rob's user level router... I think we're slowly getting more in that direction. Johnny

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