I asked:
> This is probably the reverse of what most people want to accomplish, but...
>
> I have a couple dozen SS5 machines to which I rcp files to on Friday
> mornings. The problem is that these machines share their 10Mbit ethernet
> segment with other machines that are part of a different and unrelated
> project. Because rcp takes all available bandwidth, the users of this
> other project will notice my code push if they try to do something network
> related after the code push starts. They have a momentary slowdown while
> their machine contends with my rcp for bandwidth. The rcp will back down
> and let the other protocol through (its mostly IPX while I'm entirely IP,
> by the way), but there is that delay before the rcp stands down.
>
> What I am looking for is a way to throttle my rcp commands so that they
> will never use more than a small percentage of the bandwidth. The fact
> that it will take longer to push out the code is not a problem. Can anyone
> suggest a good way to reduce the bandwidth of this file transfer? A
> SunSolve and SunManagers' Archive search didn't turn up anything.
The suggestions:
It looks like a product called _Sun Bandwidth Allocator_ does what I want.
I have contacted my local Sun Sales Rep to get a 30 day demo of the product,
and I'm hoping that this is what I'll go with. Product info is at
http://www.sun.com/software/band-allocator
Some other suggestions that I received:
* change my network topology (switches, further subnetting, vlan, etc..).
I'd love to, but the network is another department's budget and
responsibility, and they aren't planning to do any upgrades anytime soon.
* a commercial product called Floodgate, made by Checkpoint. I'm familiar
with this, and I believe it is even used here, but you have to have a
firewall / chokepoint upon which to install it. Won't work for my
topology.
* use NFS, or tar & rsh, or some other protocol instead of rcp. That
won't really address the bandwith usage, though.
* modify tcp kernel parameters.
* use "fsp", a hacked version of ftp that is designed to be low-bandwidth.
This is definitely something I'll look into if this bandwidth allocator
falls through.
* "The latest SunExpert has an article on PD s/w 'rsync' - check it out."
I did not investigate this further; I don't get SunExpert.
* Get the BSD sources to rcp and code in a delay of some sort. I only wish
I had that kind of time on my hands... ;^)
* "nice" the rcp process. CPU utilization on the client isn't a problem.
That won't really address bandwidth usage.
* Michael Maciolek forwarded me a routine he wrote called "flicker" that
slows down a process by sending it repeated "stop" and "resume" signals.
Thanks to:
gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Dan Hubbard <dhubbard@netpart.com>
Daniel Dunn <dunn@sled.gsfc.nasa.gov>
"Ian Wallace" <iwallace@bcoe.bm>
Gene Rackow <rackow@mcs.anl.gov>
Rich Pieri <rich.pieri@prescienttech.com>
Rick Osteen <rosteen1@elp.rr.com>
Richard J Niziak <rickn@ziplink.net>
Eugene Kramer <eugene@uniteq.com>
Michael Pavlov <misha@etsd.ml.com>
Daniel Kluge <danielk@tibco.com>
Seth Rothenberg <SROTHENB@montefiore.org>
bismark@alta.Jpl.Nasa.Gov (Bismark Espinoza)
Dennis Martens <MARTENSD@health.qld.gov.au>
Ramindur Singh <ramindur@zuno.com>
Michael Maciolek <mikem@centerline.com>
+-----------------------------------------------------------------------+
| Christopher L. Barnard O When I was a boy I was told that |
| cbarnard@tsg.cbot.com / \ anybody could become president. |
| (312) 347-4901 O---O Now I'm beginning to believe it. |
| http://www.cs.uchicago.edu/~cbarnard --Clarence Darrow |
+----------PGP public key available via finger or PGP keyserver---------+
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:36 CDT