jhc@mtunx.ATT.COM (Jonathan Clark) (03/10/88)
This one is really for Peter Honeyman to answer, since it is claimed that he did the relevant bit of the Telebit firmware, but the answer may prove to be of general interest. Many of us have tweaked our uucico's to use a window of 7 outstanding packets, rather than 3. Given this, does it make sense to have two Telebit modes for the 'g'-protocol spoof (one for each window size); and iff it does, are there any plans to implement this? -- Jonathan Clark jonathan.clark@mtune.att.com, attmail!jonathan Any affiliation is given for identification purposes only. The Englishman never enjoys himself except for some noble purpose.
honey@umix.cc.umich.edu (Peter Honeyman) (03/10/88)
window size doesn't affect trailblazer throughput -- a window size of 1 gives the same performance as 3 or 7. in fact, the modem converts a request for a large window size into a request for a window size of 3. it does this transparently, but you can watch it happen with -x9 debugging on. we considered knocking the window size down to 1 in all cases, as this eliminates the windowing inside the spoof code, but we were unable to assert unequivocally that all versions of uucp would work with a window size of 1. (we tested against a long list of uucp versions, but there are versions to which we didn't have access.) we were confident that 3 would work in all cases, so we stuck with that. so to answer the question, no, you don't need multiple versions of spoof code to accommodate window size variants, the modem takes care of that (too!) for you. peter
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/12/88)
In article <3830@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >window size doesn't affect trailblazer throughput -- a window size of 1 >gives the same performance as 3 or 7. Peter and I have argued this one in private before -- and I still disagree. I know the modem is perfectly capable of running flat out with window size 1. But a lot of computers are not -- and in fact, window size 3 at 9600 or 19200 bps is too small. We have many connections where the throughput is obviously constrained by the system's ability to get ack packets out; I think a bigger window size would help immensely. Of course, a lot of machines that can barely buffer 3 packets at 19200 are going to gag on 7. No problem; they don't have to run a uucico with the window size pushed up. <csg>
honey@umix.cc.umich.edu (Peter Honeyman) (03/12/88)
carl, i'd buy your argument if uucico's throughout the land knew how to piggyback acks. it's admitted by the chesson spec, but i've never seen a version that does it. if you're not convinced, why not recompile uucico with a window size of one and compare? i'm sure the results would be interesting. peter
jerry@oliveb.olivetti.com (Jerry Aguirre) (03/12/88)
In article <16750@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >In article <3830@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >>window size doesn't affect trailblazer throughput -- a window size of 1 >>gives the same performance as 3 or 7. > >I know the modem is perfectly capable of running flat out with window size 1. >But a lot of computers are not -- and in fact, window size 3 at 9600 or 19200 >bps is too small. We have many connections where the throughput is obviously >constrained by the system's ability to get ack packets out; I think a bigger >window size would help immensely. I have to agree. If the host were talking at 19200 and able to generate acks reasonably fast then throughput shouldn't suffer. But I have to run my interface at 9600 bps, to a heavily loaded slow CPU. While it might be able to generate acks fast enough on average to keep the line going it can't do so at any given instant. There are other things like disks and other serial lines to service. Remember that the acks are not being generated by the tty driver at interupt level. They are being generated by a user process. It reduces overhead if the process can process and ack several packets at each context switch. The suggestion that full speed is possible with a window of 1 is ludicrous. The modem would be able to send only 1 packet. It would then have to wait for an ack before it could send another. At a minimum that means 8 bytes of idle time for every 64 bytes received. The line would be idle for 12% of the time. Any time to process the incomming packet and generate the ACK would add to that. If the connection from the modem to the computer has additional delay then performance really suffers. By example consider dialing into a packet switched network like tymnet or PC persuit. Before switching to a window size of 7, I and others experienced terrible thruput on networks like that. I also run UUCP over lines with a satellite delay. Again, thruput is terrible without a window of 7. 3 packets * 64 char/packet * 10 bits/char = 1920 bits 1920 bits / 19200 bps = .1 second to send 3 packets. If the system takes more than 100 ms. to return any ack then performance suffers. (Actually it is 66 ms. because I can't begin generating an ack until after the first packet is received.) A satellite circuit has 700 ms. of delay. Many packet switched networks have several hundred ms. of round trip delay. If the modem really negotiates the window size with the host then why can't it use the value each host asks for? That way systems that can't buffer 7 packets can leave their window at 3 and systems that need a larger window can do so. (No, 3 is the magic number. Count ye not to 2, nor on to 4 ...... :-) You are too locked into what the modems are doing internally and not to the host interface. If I ask for a window of 7 then you should give me a window of 7, I might have a good reason. Jerry Aguirre
honey@umix.cc.umich.edu (Peter Honeyman) (03/12/88)
if the wire is slower than the host, windowing is a clear win. but here, the wire is faster than the host, usually a lot faster. the modem immediately fills the window, whatever its size. thereafter, the modem sees a window of one -- host acks, modem sends a packet to fill the window. your point about context switches is well taken -- it depends on the scheduler's behavior when the host calls write(ack). you can probably convince me that a window of two is worthwhile, but i don't see this argument extending to anywhere near seven. someone should run an experiment here. (i can't, because i don't have a fast computer with a serial board.) peter
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/15/88)
In article <17965@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: | [...] | The suggestion that full speed is possible with a window of 1 is | ludicrous. The modem would be able to send only 1 packet. It would | then have to wait for an ack before it could send another. At a minimum | that means 8 bytes of idle time for every 64 bytes received. The line | would be idle for 12% of the time. Any time to process the incomming | packet and generate the ACK would add to that. If the feed to the modem is at 19.2k, since the ack is generated at the modem, and accepted at the modem, the two systems should be able to drive the actual line at the maximum of 11-14k (depending on who's figures you see). I completely agree that this is not a desirable thing from the standpoint of interrupt overhead. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me