Hacker News Reader

Comment by OrangeMango | Hacker News Reader

Cluster-wide batch queues built-in, a cluster-wide file system, etc.

Samba support is awful, though.

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.

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.

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.

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.

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.

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.

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?

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#...

Reply on news.ycombinator.com