Date: Thu, 9 Feb 1995 08:53:44 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>, hackers@freefall.cdrom.com Subject: Re: Please? Whine.. Sup project.. Message-ID: <199502091553.IAA12682@trout.sri.MT.net> In-Reply-To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> "Please? Whine.. Sup project.." (Feb 9, 5:11am)
next in thread | previous in thread | raw e-mail | index | archive | help
> ever looked at how horribly inefficient sup is at this kind of thing! ;( > It takes very bad advantage of low bandwidth lines It took me 5 hours to sync up my tree with a 14.4K line running with no compression. (The sup ran with compression, the phone line wasn't tuned at the time and MNP compression was turned off) > (look at your modem > sometime - very poor utilization!) by not batching transfers and there's > no true checksumming of files. What do you mean by 'not batching transfers'? > 1) It has to be trustworthy (md5) Agreed, this is it's biggest problem IMHO. However, adding cksumming to the files will ADD overhead. Currently, it is very difficult to screw up sup *IF* everything works right. SUP relies on TCP/IP to do all the data checking, and if something gets screwed up on either end it doesn't know about it. > 2) It has to make optimum use of available bandwidth (fast) With my compression patches, it does a pretty good job. > 3) It has to make minimal demands on the server (not murder freefall) > 4) It has to be easy to set up. This could be improved, but right now things are fairly trivial to setup. Agreed, the client side might be easier to setup, but that should be fairly easy to fix. The host-side complexity doesn't need to change since it works fairly well and once it's setup, it's easy to modify. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502091553.IAA12682>