Doing an inquiry on the tape from the tape management system shows me the following:
General Data Volume Serial. . . : 163738 Alternate Volume . : Media type . . . : 3490-36X2 Record Format. . . : VB Record Length. . . : 32756 Block Size . . . : 229376 My next window to do a GEN change (management will not allow dynamic I/O Changes) is the 3rd weekend of Feb. I wish I had the downtime window to make the change, run some test, change to a different frame size, run additional test and so on, I'd do that. The change I'll implement this weekend I'll need to live with for the next month, that's why I'm looking for what others have experienced. Yes, this HiperSocket interface will be dedicated to Bulk Transfers, specifically our backups. -----Original Message----- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Adam Thornton Sent: Thursday, January 15, 2009 9:56 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: HiperSocket Performance On Jan 15, 2009, at 8:40 AM, Rakoczy, Dave wrote: > > I've spent the past few days scouring these archives looking for what > others have done. I found a few threads that addressed HiperSocket > throughput speeds between zOS and zLinux, but were using FTP as the > benchmark utility. I have a window this weekend where I can put in a > I/O Gen change for the Maximum Frame Size on the HiperSocket channel > define (hopefully I'm on the right track here). > > So, the question I'm posing is : If you are using HiperSockets to > support FDR/Upstream, in your experience where did you find the > performance throughput sweet spot? What does FDR/Upstream use as a tape block size? Most of the backup software I'm familiar with uses 32k or 64k chunks, so if you can set your frame size to match, that's probably ideal (assuming that much or most of your Hipersocket traffic *is* backup blocks). If your traffic is dominated by bulk transfers (like backup blocks) rather than interactive traffic, then the larger frame and larger MTU the better (unless you're in a *really* memory starved environment, but if you are this probably isn't going to be your first bottleneck). How long till the next-but-one window? Try something different this weekend, and measure it, would be my advice. Go back to the other one if it's worse, or try a third one, at your next opportunity (it is unlikely, I think, to get enormously faster or slower, presuming you're not doing silly things with MTU or frame size; 576 byte MTUs, for instance, did make sense for interactive traffic in the days of 2400 baud modems, but not so much now). Adam ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
