mp@mit-eddie.UUCP (Mark Plotnick) (03/01/84)
We've also had problems with uucp since converting to 4.2bsd. When talking with a 4.1bsd system that runs honey danber, we sometimes get into a mode where the effective transfer rate is 11 cps over a 1200-baud line. It always happens just after the other system has sent a file, sends H, we send HN and begin to transfer a file. A portion of the AUDIT shows that (I think) a good deal of retransmission is going on: send 37777777610 rec h->cntl 21 send 37777777620 state - 10 send 37777777630 send 37777777640 rec h->cntl 42 send 40 state - 10 send 37777777650 rec h->cntl 43 state - 10 send 37777777660 rec h->cntl 44 state - 10 send 37777777670 rec h->cntl 45 state - 10 send 37777777600 alarm 133 send 37777777660 rec h->cntl 26 send 37777777670 state - 10 send 37777777600 send 37777777610 rec h->cntl 47 send 40 state - 10 A good healthy transmission with the same machine looks something like: state - 10 send 37777777653 rec h->cntl 43 state - 10 send 37777777663 rec h->cntl 44 state - 10 send 37777777673 rec h->cntl 45 state - 10 send 37777777603 rec h->cntl 46 state - 10 send 37777777613 rec h->cntl 47 state - 10 send 37777777623 rec h->cntl 40 state - 10 send 37777777633 rec h->cntl 41 state - 10 send 37777777643 rec h->cntl 42 state - 10 send 37777777653 rec h->cntl 43 state - 10 send 37777777663 rec h->cntl 44 state - 10 send 37777777673 rec h->cntl 45 state - 10 send 37777777603 rec h->cntl 46 state - 10 Note that we're not having timeout problems like the people at PSU. The honey danber system has sometimes been logged in for over 24 hours before somebody notices it! We've also had problems communicating with a Eunice system. They time out waiting for a CY message. That problem seems to have been fixed by re-linking our uucp with the 4.1 signal.o module (when in doubt, blame the 4.2bsd signal mechanism). Mark