Date: Wed, 4 Oct 1995 11:19:42 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: gary@palmer.demon.co.uk (Gary Palmer) Cc: msmith@atrad.adelaide.edu.au, CACHO@mexicano.gdl.iteso.mx, taob@io.org, hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com Message-ID: <199510041619.LAA11600@brasil.moneng.mei.com> In-Reply-To: <1492.812770019@palmer.demon.co.uk> from "Gary Palmer" at Oct 4, 95 02:26:59 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Michael Smith stands accused of writing in message ID > <199510032321.IAA14949@genesis.atrad.adelaide.edu.au>: > >> I think microsoft has won that race, their ftp system told me to go > >> away last week, they had 1250 ftp users on line. > > >Yah, but have you tried to use it past the 600 mark? Whatever it is just > >loses its marbles as far as long-distance connections are concerned. > >(At least, that's been my experience) > > The problem is what network link you have really. If you can get a > fast enough network connection (perhaps FDDI or 100bTX), you should in > theory be able to handle that number without TOO many problems. Of > course, you'll always have problems with people a couple of hops away > on a fast link swamping your network :-( > > Anyone know a way to do traffic limiting? Is it even fair? About a year ago, we had a (*cough*) product related issue where we were arguing for the use of TCP/IP and tftp and another group was arguing for the use of some propietary blinkywink protocol - the advantage of our proposal was that you can go get an arbitrary TCP/IP implementation for a PC, workstation, etc., at the corner store, while a custom blinkywink protocol is something we have to write and is probably only available from us for a single platform. The argument: "tftp cannot be throttled." (the data being transferred was code to be written to a slowish flash RAM card, and there were concerns about the retry times, etc that I don't quite recall). My answer: "Rubbish", and I promptly added a "sleep()" call right after the data read. Wow did that ever do wonders to slow the transfers. :-) You should be able to bandwidth limit any arbitrary connection with a similar concept - it's fast, easy, simple to implement, stupid, and on top of it is not hard on the system. You probably want to be a little smarter than just sticking a fixed-length sleep(), but essentially that is all you NEED to do. You can write a little wrapper that allows X bytes per second through in a given period of time... I also wrote, at one time, a simple "throttle" program that limits bandwidth by malloc()ing a buffer of however many bytes per second I wanted to allow (something like 1KB to 1MB/sec) and sleep(1)ing after each read/write sequence. This is a little more efficient, maybe, when you want to limit bandwidth at high rates of speed - less syscall overhead, but potentially less accurate (it WILL limit you to something LESS than what you specify). Both techniques are trivial to code. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Software Engineer, UNIX/Network Hacker, Etc. 414/362-3617 Marquette Electronics, Inc. - R&D - Milwaukee, WI jgreco@mei.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510041619.LAA11600>