On Tuesday, February 20, 2018 at 12:25 PM, Zane Healy wrote: > > On Feb 19, 2018, at 10:42 PM, Mark Pizzolato <m...@infocomm.com> > wrote: > > > > On Monday, February 19, 2018 at 9:55 PM, Zane Healy wrote: > >> I’d posted about this nearly a month ago, and have made some real > >> progress this weekend. > >> > >> Configuration: > >> MONK > >> OpenVMS 8.3/Alpha > >> Compaq XP1000/667 > >> > >> RENNY > >> OpenVMS 7.3/VAX > >> SIMH MicroVAX3900 > >> > >> I’m backing MONK up over the Cluster to a “tape drive” on RENNY. > >> > >> First, Ubuntu includes a package for SIMH V3.8-1. If you’re just > >> using disk and network, it seems to be just fine. If you want to > >> write tapes, it seems fine. If you want to read tapes, upgrade, as > >> it appears to crash OpenVMS V7.3, at least when messing with “tapes" > >> the size I’m creating. Hopefully the crashing isn’t a clustering > >> issue, I still need to test that. I downloaded the latest SIMH sources, > >> and > built them today, and I appear to be able to read tapes without crashing. > >> At least it doesn’t crash when reading from the SIMH VAX, I still > >> need to try reading one over the cluster on my Alpha. > > [...] > >> One stupid question, I assume that SIMH emulates the network > >> interface at 10Mbit. Is there any way to speed that up? Granted, > >> all my real VAXen are limited to 10Mbit, but a faster link in SIMH would be > nice. > > > > The network interface is not artificially limited to 10Mbit. Years > > ago, I measured some 25Mbit on my desktop system. I suggest that you > > run with the latest code from https://github.com/simh/simh. Simh > > v3.8-1 was from a long time ago, and significant changes have been > > made since then. > > I grabbed the latest copy of the source from GitHub yesterday. I ran another > backup last night using the current SIMH, and it was the first to die before > finishing, but there could have been other issues. I’m trying again, as that > was > also my first attempt and running it with the /LIST option. > > As noted, the latest SIMH was needed to successfully read the tape (I simply > did a listing). > > It’s hard to judge the speed accurately, due to tape Metadata, but I’m seeing > the ‘virtual tape’ be created at about 510KB/sec. That is faster than what I > was > previously seeing. I wouldn’t be surprised if part of the bottleneck is the > virtual tape drive.
I would actually attribute the 'improved' behavior to the fact that tape I/O to TQ and XQ devices is asynchronous in the latest code. I would seriously consider Mr Baker's suggestion of backing up to simh disks. Not to save sets, but to merely using VMS backup to perform BACKUP/Image to RQ units attached to disk container files. Thus allowing any recovery you might need to have random access to the original file system without having to dig through a save set sequentially. An industrious fellow might also want to manage the RQ media setup and change activities automatically from the AXP system with a program that does a TCP connect to a simh Remote Console. - Mark _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
