4 ms·

Cluster-wide batch queues built-in, a cluster-wide file system, etc. Samba support is awful, though.

eej71 7y ago
Yes and TCP/IP support in general on VMS was not great. Performance was a consistent problem. It was clearly a second class citizen for a very long time.
- OrangeMango 7y ago
  Part of my day job is maintaining our home-grown data processing system on an old VMS (Itanium) cluster. We've been trying to get rid of it for close to 7 years now but don't seem much closer than when we started. For things that OpenVMS is good at, it is REALLY good at. Everything else... is pretty antiquated.
- cturner 7y ago
  Did VMS TCP/IP support suffer due to poor effort from Digital, or as an inherent side-effect of the kernel design? Could poor TCP/IP performance have been a consequence of 'real asynchronous I/O support'? Berkeley sockets is obnoxious [Example]. But the advanced user can get fine control over it. If you have a use-case that is vulnerable to back-pressure, with Berkeley sockets you can manage that away. Some friendlier API designs would have worse options. Berkeley sockets is ubiquitous, and there is not much to compare it to. Insights from VMS would be interesting. -- :Example. A selector indicates that a socket is ready for read/write. But what that actually means is contextual, depending on whether it was created as a client or server socket. You can't attach metadata to the socket to assist with that. Rather, you have to maintain parallel structures.
  - eej71 7y ago
    IMO, one of the significant scaling bottlenecks for VMS was there were only a handful of spinlocks that governed kernel activity. The one that I remember was IOLOCK8 (sp?). Any ethernet frame handling would have to hold that for a period of time. The underlying code that those stacks use to manage their inbound ethernet frames is likely quite old and would require significant work to reduce contention around that lock. To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.
    - eej71 7y ago
      I'll add in that you could run a fairly simple program on Linux that simply blasted out very small UDP packets and point it at a VMS node - any port is fine - you'll drive up the interrupt mode on that box. You won't need much traffic. Smaller packets are better because you want to punch it with lots of packets. It won't be much actual bandwidth. VMS performance here is kind of sad. As a bonus feature, if your VMS TCP/IP stack is configured to send ICMP replies when there is nothing there at the given port, you'll create even more grief because now the stack is busy trying to receive the blast you give it and send out replies too.
      - cturner 7y ago
        Thanks for these notes. It's neat that you have a hypothesis for the source of the problem that goes down to the types of locks.
    - derefr 7y ago
      Are you talking about a lock held for regular interrupt-driven packet delivery, or a lock held even when an Ethernet card wants to DMA into a kernel ring buffer?
      - eej71 7y ago
        I don't think DMA is an option in VMS land. Just a lock held for regular interrupt driven packet delivery. Been a while since I've dealt with it. This provides an in-depth description of the VCI API which is used to write your own ethernet frame handler. Some descriptions of when IOLOCK8 is held. https://rtk.mirrors.pdp-11.ru/_vax/openvms.org.ru/vci1.html#bottom_main https://rtk.mirrors.pdp-11.ru/_vax/openvms.org.ru/vci1.html#...

Yes and TCP/IP support in general on VMS was not great. Performance was a consistent problem. It was clearly a second class citizen for a very long time.

OrangeMango 7y ago
Part of my day job is maintaining our home-grown data processing system on an old VMS (Itanium) cluster. We've been trying to get rid of it for close to 7 years now but don't seem much closer than when we started. For things that OpenVMS is good at, it is REALLY good at. Everything else... is pretty antiquated.
cturner 7y ago
Did VMS TCP/IP support suffer due to poor effort from Digital, or as an inherent side-effect of the kernel design? Could poor TCP/IP performance have been a consequence of 'real asynchronous I/O support'? Berkeley sockets is obnoxious [Example]. But the advanced user can get fine control over it. If you have a use-case that is vulnerable to back-pressure, with Berkeley sockets you can manage that away. Some friendlier API designs would have worse options. Berkeley sockets is ubiquitous, and there is not much to compare it to. Insights from VMS would be interesting. -- :Example. A selector indicates that a socket is ready for read/write. But what that actually means is contextual, depending on whether it was created as a client or server socket. You can't attach metadata to the socket to assist with that. Rather, you have to maintain parallel structures.
- eej71 7y ago
  IMO, one of the significant scaling bottlenecks for VMS was there were only a handful of spinlocks that governed kernel activity. The one that I remember was IOLOCK8 (sp?). Any ethernet frame handling would have to hold that for a period of time. The underlying code that those stacks use to manage their inbound ethernet frames is likely quite old and would require significant work to reduce contention around that lock. To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.
  - eej71 7y ago
    I'll add in that you could run a fairly simple program on Linux that simply blasted out very small UDP packets and point it at a VMS node - any port is fine - you'll drive up the interrupt mode on that box. You won't need much traffic. Smaller packets are better because you want to punch it with lots of packets. It won't be much actual bandwidth. VMS performance here is kind of sad. As a bonus feature, if your VMS TCP/IP stack is configured to send ICMP replies when there is nothing there at the given port, you'll create even more grief because now the stack is busy trying to receive the blast you give it and send out replies too.
    - cturner 7y ago
      Thanks for these notes. It's neat that you have a hypothesis for the source of the problem that goes down to the types of locks.
  - derefr 7y ago
    Are you talking about a lock held for regular interrupt-driven packet delivery, or a lock held even when an Ethernet card wants to DMA into a kernel ring buffer?
    - eej71 7y ago
      I don't think DMA is an option in VMS land. Just a lock held for regular interrupt driven packet delivery. Been a while since I've dealt with it. This provides an in-depth description of the VCI API which is used to write your own ethernet frame handler. Some descriptions of when IOLOCK8 is held. https://rtk.mirrors.pdp-11.ru/_vax/openvms.org.ru/vci1.html#bottom_main https://rtk.mirrors.pdp-11.ru/_vax/openvms.org.ru/vci1.html#...