INFO-VAX Fri, 23 Nov 2007 Volume 2007 : Issue 642 Contents: Re: Putting a throttle on Apache (CSWS), or all of TCP Re: Putting a throttle on Apache (CSWS), or all of TCP Re: Putting a throttle on Apache (CSWS), or all of TCP Re: Rsync on VMS ---------------------------------------------------------------------- Date: Fri, 23 Nov 2007 07:28:45 -0000 From: "John Wallace" Subject: Re: Putting a throttle on Apache (CSWS), or all of TCP Message-ID: <13kd09j66ikm20e@corp.supernews.com> "Keith Lewis" wrote in message news:61688852-fcec-4438-93ed-2856fad6d308@i12g2000prf.googlegroups.com... > On Nov 21, 8:22 pm, "John Wallace" > wrote: > > "Keith Lewis" wrote in message > > > > news:d5e40952-c9f6-44e1-9037-158f90fbefc8@b15g2000hsa.googlegroups.com... > > > > > I have one of my VMS boxes set up to record and save a certain radio > > > show. As a service to my fellow fans out of the area, I make it > > > available for download on the web, over my relatively slow DSL > > > connection. > > > > Is there a particular reason you do it this way rather than uploading it to > > some web/ftp space hosted somewhere where bandwidth is less of an issue? > > Cost may be one reason. Time is money. You can fix this one of two ways; > > spend time, or spend money (option 3, spend both, also applies). > > > > > > > > > The problem is I got a new ethernet switch. > > > > Understood. Does it replace a previous one, or is the network config now > > different? If config unchanged, can you put the old switch back, what > > behaviour is observed? > > > > > which seems to have a big > > > buffer. > > > > That's a bit of a surprise. Need to see some hard evidence if possible that > > this really is the cause, unsure how VMS users get that (tcpdump equivalent? > > Ethereal/wireshark?) > > > > >It is killing the latency from my other machines. > > > > Not 100% sure which machines are seeing excessive latency, and/or to where? > > Intra-LAN latencies from anything on the LAN to anything on the LAN are > > high? VMS to outside world latencies are high while LAN latencies are OK? > > Does the latency depend on whether anybody's actively copying the > > files/streams from you? Different situations, fix may depend on which one it > > is. > > > > > > > > > The ideal solution to this (short of IPv6 packet prioritization) would > > > be to limit the Apache web server to a certain fixed bandwidth lower > > > than my total available on DSL, so then the buffer would not fill up. > > > > IPv6. It's the next big thing. ISTR it was the next big thing in the 1980s > > (shortly after OSI networks solved the same classes of problem but went > > nowhere despite DEC's efforts) and IPv6 is still the next big thing :) Do > > any ISPs in the US actually support IPv6? The UK didn't have many last time > > I looked (a year or three ago). > > > > Anyway, IPv6 or not, upstream bandwidth management is a popular approach to > > managing a DSL connection so that upstream traffic (from you to the outside > > world) does not slow down (or seriously increase latency for) your > > downstream traffic, but this is more usually related to "ack starvation", > > which wouldn't necessarily be related to a new switch with big buffers. > > > > > A less desireable solution would be to put the bandwidth limit on > > > TCPIP Services for OpenVMS as a whole. > > > > Indeed. Sledgehammer to crack nut, probably even if this has to be a "pure > > VMS" solution. > > > > What other resources are available to you on the LAN? What DSL router are > > you using? Does it have a built-in switch? > > > > Y'know, given the picture as described, the first thing I'd do would be to > > *closely* observe any LEDs on NICs and switch ports, and maybe keep an eye > > on any VMS "line up"/"line down" (or is it circuit up/circuit down) events, > > to make sure that the traditional silliness associated with auto-negotiate > > and incompatible physical layer implementations isn't occuring here. If it > > is occuring, the typical symptom is a short burst of traffic, a slightly > > longer pause while (re)negotiation takes place, a burst of traffic, a pause, > > etc. This isn't *quite* the same as steady traffic with daft latency, but > > may occasionally appear that way, so please accept my apologies if it's not > > what you're seeing. If it is occuring, you can try to fix it by forcing the > > VMS NICs to a fixed speed of your choice. I'm not 100% sure that's a > > guaranteed fix though, especially as your unmanaged switch won't have a > > fixed speed option. > > > > You also might want to temporarily connect your VMS web box direct to your > > DSL router, *without* going via the new Trendnet switch, if this is an > > option. Similarly, if the DSL router has a built in switch (as many do), you > > might want to try moving stuff between the DSLrouter switch and the Trendnet > > switch, see if anything improves. I've seen cases where cascaded switches > > don't behave as you'd hope (a D-Link and something else), and cases where > > they do (a pair of Netgear FS10x), and this reconfiguration may also help > > eliminate any issues with incompatible autonegotiate setups. > > > > Assuming it's not autonegotiate silliness, if there was scope for a > > Linux-based router (either an actual SoHo router reflashed, or a > > PC/oldlaptop, or similar) I'd probably look at Linux and some of the "DSL > > bandwidth management howtos" scattered around the Internerd (based on > > IPtables and QoS and stuff). Or at least seek advice from someone who > > understands these things properly (I don't). Another option could be to look > > at DSL routers supplied with "Turbo TCP" (Westell's name) or something > > equivalent, which is allegedly a ready-made solution to the problem of "ack > > starvation". > > > > If it has to be a VMS-based solution, JF has some interesting thoughts > > around using 2 separate NICs, and reducing what the rest of the world calls > > RWIN. Another possible option might to be to force a low MTU for traffic > > going via your DSL router, while retaining default MTU for on-LAN traffic, > > which *might* give you the necessary control. Not sure of the exact TCP > > services incantation for that, but if TCP services can't do it, a decent DSL > > router (with configurable MTU) should be able to do it instead, so long as > > Path MTU Discovery is working correctly between you and the folks you > > connect to. In fact if your router can easily change its MTU, this might be > > something to try earlier rather than later. > > > > Best of luck > > John Wallace > > OK, more details on the network change that (I assume) led to the > problem. > > I built myself a new Linux box. The switch in my Linksys router was > already full, so I bought an additional 8-port switch. > > Since the new Linux system has a second ethernet interface, I seized > the opportunity to set it up as a network monitor. I moved all my > computers to the new switch and connected the switch to the router > through an old 10Mb half-duplex hub. Then I connected the second > interface of the new Linux box to the dumb hub, so it gets mirrored > copies of every external packet. > > The latency problem only happens when somebody is doing a big download > from my web site, and it only affects external communications. I > notice it mostly from my Windows PC, which I use for gaming and VNC > over VPN. If I fire up etherape on the Linux system, I see a large, > steady, volume of outgoing web traffic. If I shut down Apache on VMS, > or if the download finishes, the problem clears up. > > Failed auto-negotiation is a potential problem here. Probably not on > my alphas but on the dumb hub. If I'm reading the LEDs on the router > right, it has correctly selected 10-half for its connection to that > hub. The Trendnet switch on the other side doesn't give as much > info. > > The idea of testing what happens when the VMS server is plugged > directly into the router is a good one. I hesitate to do that because > then I'd be sending my LAVC traffic through the 10Mb hub. I may need > what JF suggested -- a second interface on the server. Plug one into > the dumb hub for web-server traffic and leave the oy (option 3, spend both, also applies). > > > > > > > > > The problem is I got a new ethernet switch. > > > > Understood. Does it replace a previous one, or is the network config now > > different? If config unchanged, can you put the old switch back, what > > behaviour is observed? > > > > > which seems to have a big > > > buffer. > > > > That's a bit of a surprise. Need to see some hard evidence if possible that > > this really is the cause, unsure how VMS users get that (tcpdump equivalent? > > Ethereal/wireshark?) > > > > >It is killing the latency from my other machines. > > > > Not 100% sure which machines are seeing excessive latency, and/or to where? > > Intra-LAN latencies from anything on the LAN to anything on the LAN are > > high? VMS to outside world latencies are high while LAN latencies are OK? > > Does the latency depend on whether anybody's actively copying the > > files/streams from you? Different situations, fix may depend on which one it > > is. > > > > > > > > > The ideal solution to this (short of IPv6 packet prioritization) would > > > be to limit the Apache web server to a certain fixed bandwidth lower > > > than my total available on DSL, so then the buffer would not fill up. > > > > IPv6. It's the next big thing. ISTR it was the next big thing in the 1980s > > (shortly after OSI networks solved the same classes of problem but went > > nowhere despite DEC's efforts) and IPv6 is still the next big thing :) Do > > any ISPs in the US actually support IPv6? The UK didn't have many last time > > I looked (a year or three ago). > > > > Anyway, IPv6 or not, upstream bandwidth management is a popular approach to > > managing a DSL connection so that upstream traffic (from you to the outside > > world) does not slow down (or seriously increase latency for) your > > downstream traffic, but this is more usually related to "ack starvation", > > which wouldn't necessarily be related to a new switch with big buffers. > > > > > A less desireable solution would be to put the bandwidth limit on > > > TCPIP Services for OpenVMS as a whole. > > > > Indeed. Sledgehammer to crack nut, probably even if this has to be a "pure > > VMS" solution. > > > > What other resources are available to you on the LAN? What DSL router are > > you using? Does it have a built-in switch? > > > > Y'know, given the picture as described, the first thing I'd do would be to > > *closely* observe any LEDs on NICs and switch ports, and maybe keep an eye > > on any VMS "line up"/"line down" (or is it circuit up/circuit down) events, > > to make sure that the traditional silliness associated with auto-negotiate > > and incompatible physical layer implementations isn't occuring here. If it > > is occuring, the typical symptom is a short burst of traffic, a slightly > > longer pause while (re)negotiation takes place, a burst of traffic, a pause, > > etc. This isn't *quite* the same as steady traffic with daft latency, but > > may occasionally appear that way, so please accept my apologies if it's not > > what you're seeing. If it is occuring, you can try to fix it by forcing the > > VMS NICs to a fixed speed of your choice. I'm not 100% sure that's a > > guaranteed fix though, especially as your unmanaged switch won't have a > > fixed speed option. > > > > You also might want to temporarily connect your VMS web box direct to your > > DSL router, *without* going via the new Trendnet switch, if this is an > > option. Similarly, if the DSL router has a built in switch (as many do), you > > might want to try moving stuff between the DSLrouter switch and the Trendnet > > switch, see if anything improves. I've seen cases where cascaded switches > > don't behave as you'd hope (a D-Link and something else), and cases where > > they do (a pair of Netgear FS10x), and this reconfiguration may also help > > eliminate any issues with incompatible autonegotiate setups. > > > > Assuming it's not autonegotiate silliness, if there was scope for a > > Linux-based router (either an actual SoHo router reflashed, or a > > PC/oldlaptop, or similar) I'd probably look at Linux and some of the "DSL > > bandwidth management howtos" scattered around the Internerd (based on > > IPtables and QoS and stuff). Or at least seek advice from someone who > > understands these things properly (I don't). Another option could be to look > > at DSL routers supplied with "Turbo TCP" (Westell's name) or something > > equivalent, which is allegedly a ready-made solution to the problem of "ack > > starvation". > > > > If it has to be a VMS-based solution, JF has some interesting thoughts > > around using 2 separate NICs, and reducing what the rest of the world calls > > RWIN. Another possible option might to be to force a low MTU for traffic > > going via your DSL router, while retaining default MTU for on-LAN traffic, > > which *might* give you the necessary control. Not sure of the exact TCP > > services incantation for that, but if TCP services can't do it, a decent DSL > > router (with configurable MTU) should be able to do it instead, so long as > > Path MTU Discovery is working correctly between you and the folks you > > connect to. In fact if your router can easily change its MTU, this might be > > something to try earlier rather than later. > > > > Best of luck > > John Wallace > > OK, more details on the network change that (I assume) led to the > problem. > > I built myself a new Linux box. The switch in my Linksys router was > already full, so I bought an additional 8-port switch. > > Since the new Linux system has a second ethernet interface, I seized > the opportunity to set it up as a network monitor. I moved all my > computers to the new switch and connected the switch to the router > through an old 10Mb half-duplex hub. Then I connected the second > interface of the new Linux box to the dumb hub, so it gets mirrored > copies of every external packet. > > The latency problem only happens when somebody is doing a big download > from my web site, and it only affects external communications. I > notice it mostly from my Windows PC, which I use for gaming and VNC > over VPN. If I fire up etherape on the Linux system, I see a large, > steady, volume of outgoing web traffic. If I shut down Apache on VMS, > or if the download finishes, the problem clears up. > > Failed auto-negotiation is a potential problem here. Probably not on > my alphas but on the dumb hub. If I'm reading the LEDs on the router > right, it has correctly selected 10-half for its connection to that > hub. The Trendnet switch on the other side doesn't give as much > info. > > The idea of testing what happens when the VMS server is plugged > directly into the router is a good one. I hesitate to do that because > then I'd be sending my LAVC traffic through the 10Mb hub. I may need > what JF suggested -- a second interface on the server. Plug one into > the dumb hub for web-server traffic and leave the other on the switch > for internal use. > > Hosting the files on a bigger site wouldn't help much. It would add a > delay for the people I'm trying to help out, and it would still use > lots of bandwidth while it was uploading to that site for a couple of > hours a day. At least I could control when it ran. > > Dirk, thanks for the hardware suggestion. > > Shimmyshack, I'll take a look at mod_bw. Thanks for the detailed update. The symptoms do now sound probably consistent with maxing out your upstream DSL bandwidth while folks are downloading from you. The good news is that you seem to have all the ingredients in place to fix it without major investments of time or money, possibly without fussing about auto-negotiate or whether switch->hub connections are behaving badly, and possibly without needing a 2nd NIC for LAVC traffic too (the 2nd NIC is a fine idea in principle, and in a production environment, but how much LAVC traffic is really in this picture?) From my understanding of the updated picture, I still have two little puzzles: 1) Hosting a website on a DSL line isn't ideal when there's significant bulk traffic going on. External hosting would mean that you only ever "upload" (from your LAN to external host) one copy of the data being hosted. E.g. if two (or more) people download the radio programme via DSL, you've saved on your DSL traffic (in bytes) by using external hosting. If two (or more) people download the radio programme *simultaneously* via DSL, you're saving on your DSL *bandwidth* (in bits/second) by using external hosting. Your users may also get faster downloads from an external hosting service than they would from you. Obviously you've got to pay for external hosting, but given your apparent need to throttle/deprioritise your upstream bulk traffic to maintain decent service for your interactive apps, something is going to have to suffer, and (afaict) the least suffering overall occurs if you move your website off your LAN to an external host, and then you control the way the website is updated and you and your website's users aren't quite so constrained by your limited DSL bandwidth. 2) I'm not sure why you wouldn't plan to retire the old faithful 10Mbit hub, and use the dual-networked Linux box as a firewall/router/QoS box, with one NIC connected to the new switch (with all the computers on it) and one NIC as the only device connected directly to your DSL box. The Linux box would seem to have all the right bits (in principle) to monitor *and control* traffic between your LAN and the outside world, and all it would need is time+expertise to set it up. You could do this whether or not you choose to go for external hosting of your website. It does make your Linux box a single point of failure in your outside world connection, but if your website was hosted externally your users wouldn't be affected if your Linux box was down, downtime would only affect you? You have the full picture, I don't, but that's the way it currently looks from here. Regards John ------------------------------ Date: Fri, 23 Nov 2007 04:44:11 -0500 From: JF Mezei Subject: Re: Putting a throttle on Apache (CSWS), or all of TCP Message-ID: John Wallace wrote: > 2) I'm not sure why you wouldn't plan to retire the old faithful 10Mbit hub, On a managed switch, you usually have the ability to use one port to monitor the activity of other ports. iN my case, I setup a "PPPOE" VLAN and a "TCPIP" VLAN. My lan is in the TCPIP VLAN. And the link between the router and the modem is in the PPPOE VLAN. And I have designeted one VMS host to be in noth the TCPIP and PPPOE VLANS so that it can then monitor the activity between the router and the modem. In an unmanaged switch, you have no ability to monitor traffic, hence the need for a hub. ------------------------------ Date: Fri, 23 Nov 2007 14:29:57 -0000 From: "John Wallace" Subject: Re: Putting a throttle on Apache (CSWS), or all of TCP Message-ID: <13kdovcbqq4ro5d@corp.supernews.com> "JF Mezei" wrote in message news:cb254$4746a0ec$cef8887a$5790@TEKSAVVY.COM... > John Wallace wrote: > > 2) I'm not sure why you wouldn't plan to retire the old faithful 10Mbit hub, > > On a managed switch, you usually have the ability to use one port to > monitor the activity of other ports. > > iN my case, I setup a "PPPOE" VLAN and a "TCPIP" VLAN. > > My lan is in the TCPIP VLAN. And the link between the router and the > modem is in the PPPOE VLAN. And I have designeted one VMS host to be in > noth the TCPIP and PPPOE VLANS so that it can then monitor the activity > between the router and the modem. > > > In an unmanaged switch, you have no ability to monitor traffic, hence > the need for a hub. Well yes indeed, in the general case. In this specific case we already know there's a concern about putting the LAVC traffic on a 10Mbit LAN. My suggested config allows the Linux box to monitor (and control) traffic to and from the router, but (as you rightly point out) the Linux box won't see intra-LAN traffic such as the LAVC traffic, or any other traffic that isn't to/from the outside world (or the Linux box itself), because the switch should/will filter it out. I'd see that as a small price to pay to get the 10Mb hub completely out of the picture and have everything on a 100Mb LAN, without the expense of a managed switch (unless decent managed switches with mirror ports are now dirt cheap). Limiting lots of things to 10Mb purely to allow traffic monitoring of all of them wouldn't suit me, it would get seriously irritating every time I wanted to copy a file from box to box, or equivalent. I've been there, done that, probably still got the 3Com hub I was using at the time, in case I ever need a Thinwire connection again, but in the meantime everything here is on unmanaged switches and I "manage" without being able to do LAN-wide traffic monitoring. Others with different needs may want to choose a different compromise :) Have a good weekend, John Wallace ------------------------------ Date: Fri, 23 Nov 2007 09:17:53 -0800 (PST) From: Keith Cayemberg Subject: Re: Rsync on VMS Message-ID: <5fdd01db-70d1-428d-804d-c919b3672ad7@s12g2000prg.googlegroups.com> On Nov 22, 11:06 am, "Andrew Black (delete obvious bit)" wrote: > Is Rsync or anything equivalent available on VMS and what are peoples > exeperience. > I am trying to synchronise files between different disks (same and > different machines) > > Andrwe rsync for OpenVMS - ported by John Malmberg http://eisner.encompasserve.org/~malmberg/rsync/ rsync (for unix) homepage http://rsync.samba.org/ * Also... COMPARE_DIR Compare two directories, reporting missing files, etc. http://vms.process.com/scripts/fileserv/fileserv.com?COMPARE_DIR http://h71000.www7.hp.com/freeware/freeware80/compare_dir/ Guiffy - Advanced Cross-Platform Diff/Merge software http://www.guiffy.com/ see screen shot of Guiffy 5.0 on OpenVMS http://www.guiffy.com/shots.html * Here are some DCL Procedures that may suffice or be adapted for your purpose... COPY_IF_NEWER http://dcl.openvms.org/stories.php?story=03/09/23/4479412 List_unique_files.com http://dcl.openvms.org/stories.php?story=07/03/12/9626497 List_unique_files.com part II http://dcl.openvms.org/stories.php?story=07/03/22/8049141 * Some tools that may be useful to roll your own Dir Compare/Merge Utility... CMPDIR Compare two directories like DCL DIFFERENCES http://vms.process.com/scripts/fileserv/fileserv.com?CMPDIR http://h71000.www7.hp.com/freeware/freeware80/cmpdir/ diffutils - TU Delft - HREM http://nchrem.tnw.tudelft.nl/openvms/software2.html#DFU diffutils - OpenVMS Freeware CD v5 http://h71000.www7.hp.com/freeware/freeware50/gnudiffutils/ GNUDIFFUTILS - pdv-systeme ftp://ftp.pdv-systeme.de/vms/ * The original Norton Utilities for DOS had a nice Directory Merge/ Compare function, so one or more of the following NU-like clones may have the capability as well... CRS - Norton Commander-style directory browser for VMS http://vms.process.com/scripts/fileserv/fileserv.com?CRS http://h71000.www7.hp.com/freeware/freeware80/crs/ VTFM - Norton Commander-Style File Manager http://vms.process.com/scripts/fileserv/fileserv.com?VTfm http://h71000.www7.hp.com/freeware/freeware80/vtfm/ * Some other File Managers for OpenVMS... FilesPlus - by WDA System Software http://www.dempsey.com/prodsvms.html#abv flist - TPU-based directory and file manager http://h71000.www7.hp.com/freeware/freeware80/flist/ http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=FLIST&description=&author=&system=Either&language=All&RD=&RM=&RY= http://invisible-island.net/flist/flist.html FILEMASTER - Diskeeper Corp. http://www.execsoft.com/products/vms-vax/vms-vax.asp DX - Directory eXtension (File and Directory Manager) http://vms.process.com/scripts/fileserv/fileserv.com?DX http://h71000.www7.hp.com/freeware/freeware80/dx/ C SWING with MOST http://www-rak.sggw.waw.pl/info/tools/SWING/ http://vms.process.com/ftp/vms-freeware/NARNIA/ Cheers! Keith Cayemberg ------------------------------ End of INFO-VAX 2007.642 ************************