lyndon@ncc.UUCP (04/04/87)
In article <7326@boring.mcvax.cwi.nl>, jack@mcvax.cwi.nl (Jack Jansen) writes: > [...] > If you only count the time uucp takes to transfer bytes, this is true. > However, if you add the time taken to deposit files in the appropriate > places, *which kermit does during conversation*, things get far worse. > > I'm not sure how fancy uucp's like honey-danber handle this, but one of > the gross misfeatures of most uucp's is that they deliver files while > they're still eating phone time. This, combined with the fact that, for small > files, the overhead is enourmous (two files transmitted for each tiny > mail message) makes me dislike uucp. Not quite true! When uucp is *receiving* a file, it goes into the spool directory with a name like TM.process_id.sequence. Once the *entire* file is received (correctly we presume), *then* it is renamed to [DX].site_grade_sequence. This involves only a rename of the file (not a copy) which is generally quite efficient under Unix. It also prevents partially sent or corrupted files from showing up as being complete and accurate (think of 'f' protocol which sends only a checksum at the *end* of the file). The overhead of sending the control files is also quite small. A quick scan of our spool directory shows and average byte count of 58 for the D.nccX* files. Remeber that the C.* files are not transferred - they tell the local uucico what files to send where. About the only time "delivering" files becomes a problem is when someone dumps across a large file, and specifies a destination path not in the same file system as your UUCP spool directory. In this case, an explicit copy and delete must take place. After spending quite a bit of time babysitting UUCP and a bunch of news feeds, the big gripe I have with uucico is the time it spends searching the spool directory for work files. In the early days of Bnews 2.11 our main newsfeed had a problem with the HIDDENET code in rnews that caused our system to think that all of the 2 Megs of news we received the previous night had not come through them. Therefore, rnews obediently queued *every* *article* for retransmission back to them. And, no we wern't batching the feed back due to the low return traffic volume. Needless to say, I was quite impressed to see 20+ 'cico jobs running the next morning (we only have two phone lines :-) and was less impressed trying to delete the several THOUSAND files sitting in the spool directory :-( Some of the jobs had spent over 10 hours scanning for work files, and none had even reached the point of calling the remote system! Anyways, I find UUCP throughput to be quite good. We maintain a throughput of 109 cps on all of our 1200 baud links (+- about 2 cps over the last year). I would be interested in seeing some comparitive stat's on Kermit and [XYZ]MODEM. -- Lyndon Nerenberg UUCP: {mnetor!seismo, ihnp4, ubc-vision}!alberta!ncc {pyramid,winfree,bellcore}!ncc!lyndon
tim@ism780c.UUCP (04/06/87)
> This involves only a rename of the file (not a copy) which is > generally quite efficient under Unix. But a busy system will often keep the spool directory and the user directories on different file systems. A rename then involves a copy. I suspect that this is more common then having them on the same file. -- Tim Smith "And if you want to be me, be me uucp: sdcrdcf!ism780c!tim And if you want to be you, be you Compuserve: 72257,3706 'Cause there's a million things to do Delphi or GEnie: mnementh You know that there are"
nerd@percival.UUCP (04/08/87)
In article <5897@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >> This involves only a rename of the file (not a copy) which is >> generally quite efficient under Unix. > >But a busy system will often keep the spool directory and the user >directories on different file systems. I don't know how other systems get configued by the systems I have access to have the directories /usr/spool/uucp/[whatever], /usr/spool/news, and /usr/spool/mail on the same filesystem. Uucp material that is just passing through gets linked to a different file then un-linked (low overhead), but things like mail and news (the biggest part of uucp trafic) all get proccessed (sp) before they are written back out to the same file system they came off of. On a different note, what does all this have to do with minix? This is a horse that has been beeten to death on other newsgroups, why don't we move it back there? -- If my employer knew my opinions he would probably look for another engineer. Michael Galassi, Frye Electronics, Tigard, OR ..!{decvax,ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd
lyndon@ncc.UUCP (04/12/87)
In article <5897@ism780c.UUCP>, tim@ism780c.UUCP (Tim Smith) writes: > > This involves only a rename of the file (not a copy) which is > > generally quite efficient under Unix. > > But a busy system will often keep the spool directory and the user > directories on different file systems. A rename then involves a > copy. I suspect that this is more common then having them on > the same file. MOST systems keep the spool and user partitions seperate. Check your uucp logs and count the number of commands versus the number of uucp's to a location off the spool partition. I don't have exact numbers in front of me, but based on my experience with uucp, 95+% of the files never leave /usr/spool/uucp. On ncc, the breakdown is roughly 80% rmail, 15% rnews, with the remainder being uucp's. Of the uucp commands, at least 90% of those wind up in /usr/spool/uucppublic (in the spooling partition). Anyway, if this *really* bothers you, modify the code to fork a child process to do the copy and delete.