[Simh] vax idle for NetBSD
I just installed NetBSD/VAX V8 on SIMH. The documentation mentions "set cpu idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU. I'm running it on the microvax3900 simulator, if that makes a difference. Any ideas? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] vax idle for NetBSD
Hi Paul, On Thursday, November 15, 2018 at 6:32 AM, Paul Koning wrote: > I just installed NetBSD/VAX V8 on SIMH. The documentation mentions "set > cpu idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU. > > I'm running it on the microvax3900 simulator, if that makes a difference. Any > ideas? I thought this had gotten settled a long time ago. At one point, the BSD code that implemented what the OS does when there is nothing else to do got changed from how things were done in earlier BSD kernels. The big change seemed to align with when SMP support was added to the kernel to support other (non VAX) architectures. This restructuring created some platform specific routine which existed to do what was good on that platform while idling. As it turned out, what was initially implemented in the VAX specific code that did that was operationally indistinguishable from other code running elsewhere in the OS, and given that on those kernel versions idling wasn't possible under simh. Someone (I don't recall who) had come along and complained about this and after explaining the issue, I suggested that if the VAX specific routine were changed to do something that wasn't done anywhere else in the OS simh idling support could once again work. When I was poking around, I observed that nothing in any BSD kernel used IPL 1 for anything, so I suggested that the kernel idle routine could set IPL to 1 could be an indicator that simh could detect and properly idle. The party who had complained passed this suggestion back as a VAX platform specific patch and it ultimately was included in the kernel and it worked for subsequent versions. Maybe this change has gotten removed from the VAX specific BSD code in recent versions, or maybe something else is going on with your simh configuration that is interfering with idling. I can't find a VAX platform NetBSD 8.0 ISO image, or I'd have checked out what is happening before writing this. If you can make the disk image and your configuration file available for me. I'll explore the details and let you know what is happening. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Ultrix network issues
I've been successfully running Ultrix 4.5 on a Microvax3900 sim , but I've had problems with networking since migrating the sim to a Xen DomU host. TCP network performance for file transfers is painfully slow. I've reproduced the problem with ftp and rcp. After an initial flurry of traffic Ultrix only responds to incoming tcp packets after, in some cases, as much as 2 minutes later. Interactive sessions seem to have no problems. The only thing that has changed has been the migration to Xen (it was previously running on a Vmware ESxi host) and a change from tap to raw ethernet interfaces. The underlying OS (Debian Stretch) and the Ultrix install is identical between systems. I've got other OSs working fine with no network issues, various VMS versions. Anyone got any pointers, or have also seen similar issues with Ultrix? Running latest simh code from GitHub. -Douglas ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Ultrix network issues
Hi Douglas, On Thursday, November 15, 2018 at 8:50 AM, Douglas Hall wrote: > I've been successfully running Ultrix 4.5 on a Microvax3900 sim , but I've had > problems with networking since migrating the sim to a Xen DomU host. > > TCP network performance for file transfers is painfully slow. I've reproduced > the problem with ftp and rcp. After an initial flurry of traffic Ultrix only > responds to incoming tcp packets after, in some cases, as much as 2 minutes > later. Interactive sessions seem to have no problems. > > The only thing that has changed has been the migration to Xen (it was > previously running on a Vmware ESxi host) and a change from tap to raw > ethernet interfaces. The underlying OS (Debian Stretch) and the Ultrix > install is > identical between systems. > > I've got other OSs working fine with no network issues, various VMS versions. > > Anyone got any pointers, or have also seen similar issues with Ultrix? > > Running latest simh code from GitHub. From what you've said here, not being a Xen user myself, it is not 100% clear exactly what's running where. Is it: Ultrix on simh running on Debian Stretch running under Xen? OR: Ultrix on simh running on Xen running under Debian Stretch? OR: Something else...? Without regard to that, if you: 1) Stop the VMS instance running under your configuration 2) Stop the Ultrix instance running under your configuration 3) Change the Ultrix's configuration file to attach the VMS instance's boot disk image 4) Start simh with the otherwise unchanged Ultrix configuration 5) Confirm that networking with the VMS OS running in the simh Ultrix simulator is absolutely normal or if it exhibits issues similar to the Ultrix OS's behavior. Let us/me know what happens. Good Luck. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] vax idle for NetBSD
> On Nov 15, 2018, at 10:21 AM, Mark Pizzolato wrote: > > Hi Paul, > > On Thursday, November 15, 2018 at 6:32 AM, Paul Koning wrote: >> I just installed NetBSD/VAX V8 on SIMH. The documentation mentions "set >> cpu idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU. >> >> I'm running it on the microvax3900 simulator, if that makes a difference. >> Any >> ideas? > > I thought this had gotten settled a long time ago. > > At one point, the BSD code that implemented what the OS does when there is > nothing else to do got changed from how things were done in earlier BSD > kernels. The big change seemed to align with when SMP support was added to > the kernel to support other (non VAX) architectures. This restructuring > created some platform specific routine which existed to do what was good on > that platform while idling. As it turned out, what was initially implemented > in the VAX specific code that did that was operationally indistinguishable > from other code running elsewhere in the OS, and given that on those kernel > versions idling wasn't possible under simh. Someone (I don't recall who) had > come along and complained about this and after explaining the issue, I > suggested that if the VAX specific routine were changed to do something that > wasn't done anywhere else in the OS simh idling support could once again > work. When I was poking around, I observed that nothing in any BSD kernel > used IPL 1 for anything, so I suggested that the kernel idle routine could > set IPL to 1 could be an indicator that simh could detect and properly idle. > The party who had complained passed this suggestion back as a VAX platform > specific patch and it ultimately was included in the kernel and it worked for > subsequent versions. > > Maybe this change has gotten removed from the VAX specific BSD code in recent > versions, or maybe something else is going on with your simh configuration > that is interfering with idling. > > I can't find a VAX platform NetBSD 8.0 ISO image, or I'd have checked out > what is happening before writing this. If you can make the disk image and > your configuration file available for me. I'll explore the details and let > you know what is happening. I just followed these instructions: http://www.netbsd.org/ports/vax/emulator-howto.html using the 8.0 image found via the link on that page. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Ultrix network issues
On Thu, 15 Nov 2018, at 17:25, Mark Pizzolato wrote: > From what you've said here, not being a Xen user myself, it is not 100% clear > exactly what's running where. > > Is it: Ultrix on simh running on Debian Stretch running under Xen? > OR: Ultrix on simh running on Xen running under Debian Stretch? > OR: Something else...? Sorry if that wasn't clear. I have a Xen environment running with Debian Stretch in Dom0 and also in the DomU that has simh running. > > Without regard to that, if you: > 1) Stop the VMS instance running under your configuration > 2) Stop the Ultrix instance running under your configuration > 3) Change the Ultrix's configuration file to attach the VMS instance's > boot disk image > 4) Start simh with the otherwise unchanged Ultrix configuration > 5) Confirm that networking with the VMS OS running in the simh Ultrix > simulator is absolutely normal or if it exhibits issues similar to the > Ultrix OS's behavior. No change. network performance with VMS is as expected, performance with Ultrix is unusable. I can attach a pcap of a file transfer to the Ultrix system if it helps. As a further test, I installed NetBSD8/vax in simh on the same DomU I have Ultrix on and it doesn't exhibit any unusual issues with network performance. For reference, here is the show version MicroVAX 3900 simulator V4.0-0 Current Simulator Framework Capabilities: 64b data 64b addresses Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP Idle/Throttling support is available Virtual Hard Disk (VHD) support RAW disk and CD/DVD ROM support Asynchronous I/O support (Lock free asynchronous event queue) Asynchronous Clock support FrontPanel API Version 12 Host Platform: Compiler: GCC 4.2.1 Compatible Clang 3.8.1 (tags/RELEASE_381/final) Simulator Compiled as C arch: x64 (Release Build) on Nov 10 2018 at 16:37:50 Memory Access: Little Endian Memory Pointer Size: 64 bits Large File (>2GB) support SDL Video support: No Video Support RegEx support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms OS: Linux ermine-xen 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux git commit id: acbea915 git commit time: 2018-11-10T04:34:43-0800 -Douglas ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Ultrix network issues
On Thursday, November 15, 2018 at 3:27 PM, Douglas Hall wrote: > On Thu, 15 Nov 2018, at 17:25, Mark Pizzolato wrote: > > > From what you've said here, not being a Xen user myself, it is not > > 100% clear exactly what's running where. > > > > Is it: Ultrix on simh running on Debian Stretch running under Xen? > > OR: Ultrix on simh running on Xen running under Debian Stretch? > > OR: Something else...? > > Sorry if that wasn't clear. I have a Xen environment running with Debian > Stretch in Dom0 and also in the DomU that has simh running. > > > > > Without regard to that, if you: > > 1) Stop the VMS instance running under your configuration > > 2) Stop the Ultrix instance running under your configuration > > 3) Change the Ultrix's configuration file to attach the VMS instance's > > boot disk image > > 4) Start simh with the otherwise unchanged Ultrix configuration > > 5) Confirm that networking with the VMS OS running in the simh Ultrix > > simulator is absolutely normal or if it exhibits issues similar to the > > Ultrix OS's behavior. > > No change. network performance with VMS is as expected, performance with > Ultrix is unusable. I can attach a pcap of a file transfer to the Ultrix > system if it > helps. > > As a further test, I installed NetBSD8/vax in simh on the same DomU I have > Ultrix on and it doesn't exhibit any unusual issues with network performance. > > For reference, here is the show version > > MicroVAX 3900 simulator V4.0-0 Current > Simulator Framework Capabilities: > 64b data > 64b addresses > Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP > Idle/Throttling support is available > Virtual Hard Disk (VHD) support > RAW disk and CD/DVD ROM support > Asynchronous I/O support (Lock free asynchronous event queue) > Asynchronous Clock support > FrontPanel API Version 12 > Host Platform: > Compiler: GCC 4.2.1 Compatible Clang 3.8.1 (tags/RELEASE_381/final) > Simulator Compiled as C arch: x64 (Release Build) on Nov 10 2018 at > 16:37:50 > Memory Access: Little Endian > Memory Pointer Size: 64 bits > Large File (>2GB) support > SDL Video support: No Video Support > RegEx support for EXPECT commands > OS clock resolution: 1ms > Time taken by msleep(1): 1ms > OS: Linux ermine-xen 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10- > 27) x86_64 GNU/Linux > git commit id: acbea915 > git commit time: 2018-11-10T04:34:43-0800 Thanks for the SHOW VERSION output. Meanwhile the more important detail will be things like SHOW ETHERNET And SHOW XQ STATS, and just SHOW XQ (after the OS has exhibited the problem AND after a different OS doesn't exhibit the problem. In your configuration file for BOTH the working and the non-working cases please try variations of: SET XQ TYPE=DEQNA SET XQ TYPE=DELQA SET XQ TYPE=DELQA-T This change would occur in your configuration file before you attach the device. If you still get everything but Ultrix working for each of these cases, then the only difference is the potential timing regarding how the Ultrix driver handles the buffer descriptor lists vs how the other operating systems do it. Let me know what you find. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Ultrix network issues
On Thu, 15 Nov 2018, at 23:47, Mark Pizzolato wrote:
> Thanks for the SHOW VERSION output.
>
> Meanwhile the more important detail will be things like SHOW ETHERNET
> And SHOW XQ STATS, and just SHOW XQ (after the OS has exhibited the
> problem AND after a different OS doesn't exhibit the problem.
sim> show ethernet
ETH devices:
eth0 eth0 (No description available)
eth1 eth1 (No description available)
eth2 eth2 (No description available)
eth3 tap:tapN (Integrated Tun/Tap support)
eth4 nat:{optional-nat-parameters}(Integrated NAT (SLiRP) support)
eth5 udp:sourceport:remotehost:remoteport (Integrated UDP bridge support)
libpcap version 1.8.1
Open ETH Devices:
XQ eth1 (No description available)
Ethernet Device:
Name:eth1
Reflections: 0
Self Loopbacks Sent: 2
Self Loopbacks Rcvd: 0
Host NIC Address:1A:DE:AD:BE:EF:19
Packets Sent:38
Packets Received:51
Asynch Interrupts: Enabled
Interrupt Latency: 0 uSec
Read Queue: Count: 0
Read Queue: High:2
Read Queue: Loss:0
Peak Write Queue Size: 1
BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst FF:FF:FF:FF:FF:FF)
or (ether dst CF:00:00:00:00:00)))
sim> show xq stats
XQ Ethernet statistics:
Recv: 55
Dropped: 0
Xmit: 36
Xmit Fail: 0
Runts: 0
Oversize: 0
SW Reset: 1
Setup: 2
Loopback: 0
Recv Overrun: 0
ReadQ count: 0
ReadQ high:2
Ethernet Device:
Name:eth1
Reflections: 0
Self Loopbacks Sent: 2
Self Loopbacks Rcvd: 0
Host NIC Address:1A:DE:AD:BE:EF:19
Packets Sent:39
Packets Received:55
Asynch Interrupts: Enabled
Interrupt Latency: 0 uSec
Read Queue: Count: 0
Read Queue: High:2
Read Queue: Loss:0
Peak Write Queue Size: 1
BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst FF:FF:FF:FF:FF:FF)
or (ether dst CF:00:00:00:00:00)))
sim> show xq
XQ address=20001920-2000192F, vector=3F8*, BR4, MAC=1A:AD:FA:BE:CE:19
type=DELQA-T, mode=DEQNA, polling=disabled, sanity=OFF
throttle=disabled, DEQNALock=OFF, leds=(ON,ON,ON)
attached to eth1
After problem manifests itself:
Remote Console Command from 198.18.0.50> show xq
XQ address=20001920-2000192F, vector=3F8*, BR4, MAC=1A:AD:FA:BE:CE:19
type=DELQA-T, mode=DEQNA, polling=disabled, sanity=OFF
throttle=disabled, DEQNALock=OFF, leds=(ON,ON,ON)
attached to eth1
sim> show xq stats
XQ Ethernet statistics:
Recv: 422
Dropped: 0
Xmit: 255
Xmit Fail: 0
Runts: 0
Oversize: 0
SW Reset: 1
Setup: 2
Loopback: 0
Recv Overrun: 0
ReadQ count: 0
ReadQ high:8
Ethernet Device:
Name:eth1
Reflections: 0
Self Loopbacks Sent: 2
Self Loopbacks Rcvd: 0
Host NIC Address:1A:DE:AD:BE:EF:19
Jumbo Fragmented:7
Packets Sent:258
Packets Received:422
Asynch Interrupts: Enabled
Interrupt Latency: 0 uSec
Read Queue: Count: 0
Read Queue: High:8
Read Queue: Loss:0
Peak Write Queue Size: 1
BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst FF:FF:FF:FF:FF:FF)
or (ether dst CF:00:00:00:00:00)))
With NetBSD:
sim> show ethernet
ETH devices:
eth0 eth0 (No description available)
eth1 eth1 (No description available)
eth2 eth2 (No description available)
eth3 tap:tapN (Integrated Tun/Tap support)
eth4 nat:{optional-nat-parameters}(Integrated NAT (SLiRP) support)
eth5 udp:sourceport:remotehost:remoteport (Integrated UDP bridge support)
libpcap version 1.8.1
Open ETH Devices:
XQ eth1 (No description available)
Ethernet Device:
Name:eth1
Reflections: 0
Self Loopbacks Sent: 2
Self Loopbacks Rcvd: 0
Host NIC Address:1A:DE:AD:BE:EF:19
Packets Sent:3
Asynch Interrupts: Disabled
Read Queue: Count: 0
Read Queue: High:0
Read Queue: Loss:0
Peak Write Queue Size: 1
BPF Filter: (((ether dst 00:00:00:00:00:00) or (ether multicast)))
sim> show xq stats
XQ Ethernet statistics:
Recv: 0
Dropped: 0
Xmit: 0
Xmit Fail: 0
Runts: 0
Oversize: 0
SW Reset: 1
Setup: 1
Loopback: 0
Recv Overrun: 0
ReadQ count: 0
ReadQ high:0
Ethernet Device:
Name:eth1
Reflections: 0
Self Loopbacks Sent: 2
Self Loo
Re: [Simh] Ultrix network issues
On Thursday, November 15, 2018 at 4:31 PM, Douglas Hall wrote:
> On Thu, 15 Nov 2018, at 23:47, Mark Pizzolato wrote:
>
> > Thanks for the SHOW VERSION output.
> >
> > Meanwhile the more important detail will be things like SHOW ETHERNET
> > And SHOW XQ STATS, and just SHOW XQ (after the OS has exhibited the
> > problem AND after a different OS doesn't exhibit the problem.
>
> sim> show ethernet
> ETH devices:
> eth0 eth0 (No description available)
> eth1 eth1 (No description available)
> eth2 eth2 (No description available)
> eth3 tap:tapN (Integrated Tun/Tap support)
> eth4 nat:{optional-nat-parameters}(Integrated NAT (SLiRP) support)
> eth5 udp:sourceport:remotehost:remoteport (Integrated UDP bridge
> support)
> libpcap version 1.8.1
> Open ETH Devices:
> XQ eth1 (No description available)
> Ethernet Device:
> Name:eth1
> Reflections: 0
> Self Loopbacks Sent: 2
> Self Loopbacks Rcvd: 0
> Host NIC Address:1A:DE:AD:BE:EF:19
> Packets Sent:38
> Packets Received:51
> Asynch Interrupts: Enabled
> Interrupt Latency: 0 uSec
> Read Queue: Count: 0
> Read Queue: High:2
> Read Queue: Loss:0
> Peak Write Queue Size: 1
> BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst
> FF:FF:FF:FF:FF:FF) or
> (ether dst CF:00:00:00:00:00)))
>
> sim> show xq stats
> XQ Ethernet statistics:
> Recv: 55
> Dropped: 0
> Xmit: 36
> Xmit Fail: 0
> Runts: 0
> Oversize: 0
> SW Reset: 1
> Setup: 2
> Loopback: 0
> Recv Overrun: 0
> ReadQ count: 0
> ReadQ high:2
> Ethernet Device:
> Name:eth1
> Reflections: 0
> Self Loopbacks Sent: 2
> Self Loopbacks Rcvd: 0
> Host NIC Address:1A:DE:AD:BE:EF:19
> Packets Sent:39
> Packets Received:55
> Asynch Interrupts: Enabled
> Interrupt Latency: 0 uSec
> Read Queue: Count: 0
> Read Queue: High:2
> Read Queue: Loss:0
> Peak Write Queue Size: 1
> BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst
> FF:FF:FF:FF:FF:FF) or
> (ether dst CF:00:00:00:00:00)))
>
> sim> show xq
> XQaddress=20001920-2000192F, vector=3F8*, BR4,
> MAC=1A:AD:FA:BE:CE:19
> type=DELQA-T, mode=DEQNA, polling=disabled, sanity=OFF
> throttle=disabled, DEQNALock=OFF, leds=(ON,ON,ON)
> attached to eth1
>
>
> After problem manifests itself:
>
> Remote Console Command from 198.18.0.50> show xq
> XQaddress=20001920-2000192F, vector=3F8*, BR4,
> MAC=1A:AD:FA:BE:CE:19
> type=DELQA-T, mode=DEQNA, polling=disabled, sanity=OFF
> throttle=disabled, DEQNALock=OFF, leds=(ON,ON,ON)
> attached to eth1
>
> sim> show xq stats
> XQ Ethernet statistics:
> Recv: 422
> Dropped: 0
> Xmit: 255
> Xmit Fail: 0
> Runts: 0
> Oversize: 0
> SW Reset: 1
> Setup: 2
> Loopback: 0
> Recv Overrun: 0
> ReadQ count: 0
> ReadQ high:8
> Ethernet Device:
> Name:eth1
> Reflections: 0
> Self Loopbacks Sent: 2
> Self Loopbacks Rcvd: 0
> Host NIC Address:1A:DE:AD:BE:EF:19
> Jumbo Fragmented:7
> Packets Sent:258
> Packets Received:422
> Asynch Interrupts: Enabled
> Interrupt Latency: 0 uSec
> Read Queue: Count: 0
> Read Queue: High:8
> Read Queue: Loss:0
> Peak Write Queue Size: 1
> BPF Filter: (((ether dst 1A:AD:FA:BE:CE:19) or (ether dst
> FF:FF:FF:FF:FF:FF) or
> (ether dst CF:00:00:00:00:00)))
>
>
> With NetBSD:
>
> sim> show ethernet
> ETH devices:
> eth0 eth0 (No description available)
> eth1 eth1 (No description available)
> eth2 eth2 (No description available)
> eth3 tap:tapN (Integrated Tun/Tap support)
> eth4 nat:{optional-nat-parameters}(Integrated NAT (SLiRP) support)
> eth5 udp:sourceport:remotehost:remoteport (Integrated UDP bridge
> support)
> libpcap version 1.8.1
> Open ETH Devices:
> XQ eth1 (No description available)
> Ethernet Device:
> Name:eth1
> Reflections: 0
> Self Loopbacks Sent: 2
> Self Loopbacks Rcvd: 0
> Host NIC Address:1A:DE:AD:BE:EF:19
> Packets Sent:3
> Asynch Interrupts: Disabled
> Read Queue: Count: 0
> Read Queue: High:0
> Read Queue: Loss:0
> Peak Write Queue Size: 1
> BPF Filter: (((ether dst 00:00:00:00:00:00) or (ether multicast)))
>
> sim> show xq stats
> XQ Ethernet statistics:
> Recv: 0
>
