HECnet

hecnet@lists.dfupdate.se

15589 discussions

Emulated XQ polling timer setting and data overrun

by Mark＠infocomm.com

On Thursday, June 05, 2014 at 1:27 AM, Johnny Billquist wrote: On 2014-06-05 02:38, Jean-Yves Bernier wrote: [...] I have tested commit 753e4dc9 on Mac OS 10.6, no virtualization. Both simh instances run on the same hardware. XQ set to different MAC addresses, since this is now enforced. Asynchronous network/disk IO may explain the uncommon transfer speed (I have filled a RM03 in seconds). Interesting. I still have real network issues with the latest simh talking to a real PDP-11 sitting on the same physical network. So you seem to have hit sime other kind of limitation or something... Can you elaborate on these 'real network issues'? This is the first I've heard of anything like this. I have not had any experience with a real PDP11 talking to a simh PDP or VAX, but in the past there were no issues with multiple simh VAX simulators talking to real VAX systems on the same LAN. Let me know. Thanks. - Mark

11 years, 8 months

Emulated XQ polling timer setting and data overrun

by bqt＠softjar.se

On 2014-06-05 02:38, Jean-Yves Bernier wrote: At 4:59 PM -0700 4/6/14, Mark Pizzolato - Info Comm wrote: Did you change the number of receive buffers? That does not seem possible under RSX. It is, but you need to do it in CFE. No way of dynamically changing at runtime. That really only indicates that you're running on a platform which can do Ethernet network I/O in a parallel thread. Most platforms did not use the threaded model previously. Previously, in 3.9, Polling was still necessary since the simulator didn't really support an asynchronous I/O model. The latest codebase has support for asynchronous network AND disk I/O. On the current codebase if you've got threads available, then network reads and writes are performed asynchronously and interrupts (I/O completion) is triggered with a few microseconds of latency. As I recall from earlier in these threads, you're running under CentOS on VirtualBox. You didn't mention what host OS you're running on. In any case, the threaded model might just work better in the virtual environment. I have tested commit 753e4dc9 on Mac OS 10.6, no virtualization. Both simh instances run on the same hardware. XQ set to different MAC addresses, since this is now enforced. Asynchronous network/disk IO may explain the uncommon transfer speed (I have filled a RM03 in seconds). Interesting. I still have real network issues with the latest simh talking to a real PDP-11 sitting on the same physical network. So you seem to have hit sime other kind of limitation or something... 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

11 years, 8 months

Emulated XQ polling timer setting and data overrun

by Mark＠infocomm.com

On Jun 4, 2014 5:38 PM, Jean-Yves Bernier <bernier at pescadoo.net> wrote: > > At 4:59 PM -0700 4/6/14, Mark Pizzolato - Info Comm wrote: > > >Did you change the number of receive buffers? > > That does not seem possible under RSX. > > > >That really only indicates that you're running on a platform which > >can do Ethernet network I/O in a parallel thread. Most platforms > >did not use the threaded model previously. Previously, in 3.9, > >Polling was still necessary since the simulator didn't really > >support an asynchronous I/O model. The latest codebase has support > >for asynchronous network AND disk I/O. On the current codebase if > >you've got threads available, then network reads and writes are > >performed asynchronously and interrupts (I/O completion) is > >triggered with a few microseconds of latency. As I recall from > >earlier in these threads, you're running under CentOS on VirtualBox. > >You didn't mention what host OS you're running on. In any case, > >the threaded model might just work better in the virtual environment. > > > I have tested commit 753e4dc9 on Mac OS 10.6, no virtualization. Both > simh instances run on the same hardware. XQ set to different MAC > addresses, since this is now enforced. > > Asynchronous network/disk IO may explain the uncommon transfer speed > (I have filled a RM03 in seconds). I didn't notice you were not testing traffic between VAXes . The threaded network I/o buffers more traffic which could naturally avoid overruns. Disk I/o with RQ and RP are now asynchronous on VAX and PDP11. - Mark

11 years, 8 months

Emulated XQ polling timer setting and data overrun

by bernier＠pescadoo.net

At 4:59 PM -0700 4/6/14, Mark Pizzolato - Info Comm wrote: Did you change the number of receive buffers? That does not seem possible under RSX. That really only indicates that you're running on a platform which can do Ethernet network I/O in a parallel thread. Most platforms did not use the threaded model previously. Previously, in 3.9, Polling was still necessary since the simulator didn't really support an asynchronous I/O model. The latest codebase has support for asynchronous network AND disk I/O. On the current codebase if you've got threads available, then network reads and writes are performed asynchronously and interrupts (I/O completion) is triggered with a few microseconds of latency. As I recall from earlier in these threads, you're running under CentOS on VirtualBox. You didn't mention what host OS you're running on. In any case, the threaded model might just work better in the virtual environment. I have tested commit 753e4dc9 on Mac OS 10.6, no virtualization. Both simh instances run on the same hardware. XQ set to different MAC addresses, since this is now enforced. Asynchronous network/disk IO may explain the uncommon transfer speed (I have filled a RM03 in seconds). -- Jean-Yves Bernier

11 years, 8 months

Phase II

by paul_koning＠dell.com

Are there any Phase II implementations out there that could be downloaded and run on an emulator such as SIMH? DECnet/E for RSTS V7 would be great since I know that well, but something else would also be interesting. I m trying to make my DECnet/Python allow Phase II, as opposed to the standard one version back backward compatibility. That s not documented but it is perfectly doable. Finding a real test system is the tricky part. It would be really neat to be able to find one that uses the marginally documented intercept feature. Does anyone here know where that was used? I have a vague impression that TOPS-10 and/or TOPS-20 treated the front end PDP-11 like another node. so that would be the relay node and the 10 or 20 the end node in a Phase II star network. Is that correct? paul

11 years, 8 months

Emulated XQ polling timer setting and data overrun

by Mark＠infocomm.com

On Wednesday, June 04, 2014 at 4:08 PM, Jean-Yves Bernier wrote: At 10:44 AM -0700 4/6/14, Mark Pizzolato - Info Comm wrote: If you're going to drive this deeply into testing it would really be best if you ran with the latest code since your results may ultimately suggest code changes, AND the latest code may behave significantly different than the older versions. Independent of which codebase you're running, and since you're now tweaking the behavior of the simulated hardware, you may want to look at sim> SHOW XQ STATS and try to analyze the relationship between these stats and the ones the OS sees. Also, you may want to explore what happens if: NCP> DEFINE LINE QNA-0 RECEIVE BUFFER 32 Is done prior to starting your network... The limit of 32 may be different on different Operating Systems... Once again the latest code is available from: https://github.com/simh/simh/archive/master.zip Mark, what kind of magic did you perform on XQ? I tried commit 753e4dc9 and overruns are gone. No more NFT/FAL hangups. Transfer speed is higher than ever : 10000. blocks in 4 seconds. I can't believe it. This ROCKS. Significant changes have been made since 3.9, but I haven't seen substantial throughput differences. Did you change the number of receive buffers? Maybe the secret is here: sim> sh xq XQ address=17774440-17774457, vector=120, MAC=08:00:2B:AA:BB:01 type=DEQNA, polling=disabled, sanity=OFF leds=(ON,ON,ON) attached to eth0 "polling=disabled" That really only indicates that you're running on a platform which can do Ethernet network I/O in a parallel thread. Most platforms did not use the threaded model previously. Previously, in 3.9, Polling was still necessary since the simulator didn't really support an asynchronous I/O model. The latest codebase has support for asynchronous network AND disk I/O. On the current codebase if you've got threads available, then network reads and writes are performed asynchronously and interrupts (I/O completion) is triggered with a few microseconds of latency. As I recall from earlier in these threads, you're running under CentOS on VirtualBox. You didn't mention what host OS you're running on. In any case, the threaded model might just work better in the virtual environment. - Mark

11 years, 8 months

Emulated XQ polling timer setting and data overrun

by bernier＠pescadoo.net

At 10:44 AM -0700 4/6/14, Mark Pizzolato - Info Comm wrote: If you're going to drive this deeply into testing it would really be best if you ran with the latest code since your results may ultimately suggest code changes, AND the latest code may behave significantly different than the older versions. Independent of which codebase you're running, and since you're now tweaking the behavior of the simulated hardware, you may want to look at sim> SHOW XQ STATS and try to analyze the relationship between these stats and the ones the OS sees. Also, you may want to explore what happens if: NCP> DEFINE LINE QNA-0 RECEIVE BUFFER 32 Is done prior to starting your network... The limit of 32 may be different on different Operating Systems... Once again the latest code is available from: https://github.com/simh/simh/archive/master.zip Mark, what kind of magic did you perform on XQ? I tried commit 753e4dc9 and overruns are gone. No more NFT/FAL hangups. Transfer speed is higher than ever : 10000. blocks in 4 seconds. I can't believe it. This ROCKS. Maybe the secret is here: sim> sh xq XQ address=17774440-17774457, vector=120, MAC=08:00:2B:AA:BB:01 type=DEQNA, polling=disabled, sanity=OFF leds=(ON,ON,ON) attached to eth0 "polling=disabled" -- Jean-Yves Bernier

11 years, 8 months

DEC Notes conference archive

by mcguire＠neurotica.com

On 06/04/2014 05:34 PM, John Dohn wrote: Hi, guys! Do anyone have archive of conferences mentioned at http://www.buschdorf.eu/vaxnotes/ ? I sure hope so. It looks like the suits got to it! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 8 months

DEC Notes conference archive

by xdelta＠meta.ua

Hi, guys! Do anyone have archive of conferences mentioned at http://www.buschdorf.eu/vaxnotes/ ? -- Best Regards

11 years, 8 months

Same MAC address on different nodes

by Mark＠infocomm.com

On Sunday, May 25, 2014 at 10:14 AM, Johnny Billquist wrote: On 2014-05-25 19:04, Hans Vlems wrote: Huh? With ethernet, communication with adjacent nodes works without involving any routers anyway. And if you need to talk with anything beyond, you're going to go through the router on the way there anyway. Really, unless you actually have several interfaces, there is no gain in running a router compared to an endnode. However, running a router definitely use up more resources, which is a disadvantage. Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown the simulators the VM host and the real iron. Would still not make any difference, which I have pointed out several times now, and also what Jean-Yves have been observing the last two days. Really. There is no black magic here. I can explain every bit of it if someone needs more convincing. Essentially, the MAC address in the actual ethernet controller (or the MAC address set before boot in simh) is irrelevant. Once DECnet starts running, that MAC address is not used anymore. It is just a trivia piece of information so that you can know what the hardware MAC address from the factory is. It is not used by anything, especially not anything related to network communication. The VM host in turn cares even less, since whatever MAC address simh plays around with is fully local to simh, and does not affect the VM host. Any questions? Actually depending on the timing, having multiple nodes on the same LAN with the same hardware MAC address WILL cause an error in a simh configuration. A little background here is appropriate: VMS (and presumably other DECnet capable DEC Operating Systems) have logic in the network device driver which attempts to assure that no other node on the LAN has the same MAC address whenever an application or protocol stack attempts to set the Physical Address on the network card. The validation step uses the Loopback protocol to send a packet to (and from) the MAC address which the software is trying to set the Physical Address to and if a response is actually received, the attempt to set the Physical Address is rejected. This is intended to detect duplicate DECnet addresses on a LAN segment. The process of sending loopback packets like this (and correctly getting answers when the problems they are designed to detect were there) caused some interesting structural design issues in the sim_ether layer way back when the XQ device was first being developed. As it turns out, the process described above was designed BEFORE learning bridges and other switches which are fundamentally part of networks today were in use. The initial simh Ethernet device implementations reflected the hardware behavior. The hardware behavior first set the Physical MAC address to the new value and then sent the loopback packet, but on switched networks this didn't actually detect the problem it was originally designed to detect. The detection problem is due to the fact that learning bridges AND most switches running some form of spanning tree protocol generally don't forward the first packet they see from a particular address. They may not forward packets from a particular address for a good number of seconds while they potentially learn about changing topologies. The 'right' approach to implement this test would be for the loopback packet to be sent from the current Physical MAC address BEFORE it is changed. This approach works on learning networks (presuming that the current Physical MAC address had already been learned on that LAN due to other traffic). The current simulated approach to this problem does several things: 1) it detects the send to self loopback attempt and before actually transmitting anything changes the source address of the loopback packet to be the current physical address of the host system's lan interface. 2) it temporarily enables capture of a potential loopback response to the host system's MAC address in the pcap filter in effect. 3) it then sends the packet. If a response is received, it is reformatted to look like what the original hardware response would have been if a duplicate MAC address had been found and then passes that up into the simulated system. This approach effectively detects duplicate DECnet addresses on today's LANs. As I mentioned above, the VMS driver actually performs this loopback test ANY time the Physical MAC address is changed, not just by DECnet or cluster software. The original logic in sim_ether only had examples with DECnet addresses so it the tests to detect this presumed DECnet format MAC addresses. Once I realized that a complete solution involved any address, I generalized the check. After I generalized the check, I realized that DECnet Phase V systems don't change their LAN interface MAC addresses. Given the potential of multiple simulated systems existing on the same LAN with potentially conflicting MAC addresses, I leveraged the already existing logic to verify that the Hardware MAC address wasn't already in use on the LAN by executing the above mentioned loopback test when a simh LAN device is attached to a network segment. So, if you've got 2 simh VAX systems on the same LAN segment and you don't change the MAC address of the LAN interface: System 1: sim> show xq XQ address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF DEQNALock=OFF, leds=(ON,ON,ON) not attached sim> attach xq eth0 WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008) Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38} sim> System 2: sim> show xq XQ address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF DEQNALock=OFF, leds=(ON,ON,ON) not attached sim> attach xq eth0 WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008) Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38} XQ: MAC Address Conflict on LAN for address 08:00:2B:AA:BB:CC, change the MAC address to a unique value Eth: closed \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38} Unit not attachable sim> This functionality exists for all LAN devices on the supported simulators (XQ and XU in the Qbus and VAX family simulators) in the latest simh codebase. Depending on the timing of various actions, the above collision wouldn't be detected if one of the nodes is running a network stack which changes the physical address. It will then be up to the simulated OS to potentially detect address collisions. - Mark

11 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet