home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / CIS / CIS-SYS.DOC < prev    next >
Text File  |  2000-06-30  |  7KB  |  113 lines
  1. The  following is a message I recently received on MicroNet from  Russ 
  2. Ranshaw  of  CIS.   It covers some of the  problems  encountered  with 
  3. various network facilities.
  4.  
  5. ----forwarded message follows----
  6.  
  7. Sb: File transfer protocols
  8.     16-Mar-82  13:55:18
  9. Fm: Wiz-10 70000,1
  10. To: Keith Petersen 70535,1245
  11.  
  12. There  are several layers of network and switch gear between the  user 
  13. and  the program running on one of our PDP-10 hosts.   First there  is 
  14. the local node to which he is connected.  If it is a CIS node, then it 
  15. is a PDP-11 or some varient.  That -11 is connected via a long-line to 
  16. another  -11.  Depending on location of the local node,  there may  in 
  17. fact be several -11's by the time the connection ends up in  Columbus.  
  18. Once  here,  the  termination  is in another -11  which  is  cross-bar 
  19. connected  to a set of PDP-15's.   Each -15 services four KI-10 hosts.  
  20. Normally,  the delays from node to host are reasonably small.  Once at 
  21. the host, you are subjected to the problem that there are several jobs 
  22. running, not just yours, and the monitor will schedule your job to run 
  23. under any of several circumstances.   If it is waiting for input, then 
  24. the  job will awaken when input is ready from the terminal.   Here  is 
  25. another  difficulty.   To really do what you indicate,  the job  would 
  26. have to run in what we call "break on all character mode," where  each 
  27. character  input  from the terminal is sent immediately to  the  host.  
  28. The  problem  with this is that it dilutes the bandwidth of  the  9600 
  29. baud  long  lines if there are a lot of jobs doing that.   The  normal 
  30. mode  is  that  characters are assembled into "packets"  of  24  bytes 
  31. before being sent,  and a "break" character (CR,  LF,  ESC, BEL, and a 
  32. few others) will terminate a packet and send it along.   We prefer  to 
  33. run in this mode in order to better utilize the long-lines.
  34.  
  35. Running in 8-bit mode is no problem on CIS nodes,  but it has its  own 
  36. problems.  There are two ways to run in 8-bit image mode: break on all 
  37. characters  or  buffered.   The b.o.a.c.  has the same  difficulty  as 
  38. above,  so we don't want to do it.  The buffered mode suffers from the 
  39. fact  that there is no "break" character because all bit patterns must 
  40. be treated as data, hence the node has to "dummy up" a situation which 
  41. will terminate a packet.  We chose to send the packet if there is a 2-
  42. character time delay with no input.
  43.  
  44. Now for the effect on up/down loading.
  45.  
  46. A  block  of data is transmitted.   The far end (be it host  or  local 
  47. system) sends its ACK.   If uploading,  the ACK enters the node, waits 
  48. for  2  character times,  and is on its way.   It might take  say  1/2 
  49. second to arrive at the host.  The job running on the host has to wake 
  50. up to process the ACK.   If it happens to be swapped out, it has to be 
  51. swapped back in before it can run.  If there is a lot of terminal  I/O 
  52. going on,  then the scheduler queue which services terminal-bound jobs 
  53. is  rather long,  and our transfer probram run request gets stacked on 
  54. the bottom of the queue.   Finally our job can run again,  and manages 
  55. to  send  out the next block of data,  which the network  can  usually 
  56. digest  quite rapidly due to the buffering action of the  intermediate 
  57. nodes.  It now takes maybe another 1/2 second for the data to traverse 
  58. all the nodes and begin arriving at your system.  Typically, the over-
  59. all  delay runs to about 1.5 to 2.5 seconds,  depending on system  and 
  60. network loading.   That delay is going to be there regardless of  what 
  61. protocol you are running.  What can be done?
  62.  
  63. One thing is to transmit larger blocks.  I picked up a lot when I went 
  64. from line-at-a-time to 256-bytes at a time,  in fact,  from an average 
  65. of  8-10 CPS to about 25 CPS.   The block size could be made GIGANTIC, 
  66. like several thousand bytes.   However, the error detection capability 
  67. begins to deteriorate at large block sizes,  and worse,  if you have a 
  68. noisy  local  telephone system/modem/???,  you will  likely  encounter 
  69. frequent  retransmission,  and  it takes a long time  totransmit  long 
  70. blocks.   Incidently, with the current A-protocol and 256-byte blocks, 
  71. the effective thru-put is at best 29.5 CPS;  the above delays  account 
  72. for the difference.
  73.  
  74. Another  thing  which we can try is to employ a  synchronous  protocol 
  75. instead  of an asynchronous one (the A-protocol,  and Ward Christensen 
  76. protocol  are  asynchronous).   This means that we  would  transmit  a 
  77. block,  then  immediately tranmit the next one,  hoping to receive the 
  78. ACK or NAK for the first one before the second one has  finished.  But 
  79. now we have other problems.  What do we do if there is an error in the 
  80. first  block?   We have the choice of holding the second one (if it is 
  81. okay) until the first one gets correctly transmitted,  or we can  toss 
  82. it  away.   If we toss it away,  making the sender resend it,  we have 
  83. diluted  our  thruput.   If  we keep it  for  later,  we  are  opening 
  84. Pandora's box of troubles.   If you are familar with IBM Bisync, there 
  85. are  lots  of  situations where this scheme falls apart  due  to  mis-
  86. understood ACKs or NAKs.  The "toss it away" attitude is the concensus 
  87. of most networkers today.   DDCMP,  one of the most reliable and wide-
  88. spread  network protocols,  does just this.   They opt to reduce their 
  89. thru-put in favor of greater reliability.
  90.  
  91. I  hope all of this indicates to you that our protocols and procedures 
  92. are not random or capricious!
  93.  
  94. I  think  that the best way for us to go is to  get  compressed  files 
  95. working.   If  we can achieve a 30-40% reduction if file size over the 
  96. comm.  link, the transmission time for actual data will in fact exceed 
  97. the link's bandwidth.
  98.  
  99. I forgot the "masking" which we do.  Many of our users (about 25%) use 
  100. Tymnet.   Tymnet does a poor job handling control characters and bit-7 
  101. characters  at times.   In particular,  control-B and control-O  cause 
  102. problems on the Tymcom node.   Telenet has its own problems.  In order 
  103. to get around some of these diffuculties,  we "mask" control codes  by 
  104. sending  them as <DLE><code+040>.   I am currently looking into  bit-7 
  105. masking as well, although it will be employed only in the event of two 
  106. successive retransmissions.
  107.  
  108. I do hope this gives you some insight into our situation and problems.  
  109. Your comments are of course welcome.
  110.  
  111.         Russ
  112.  
  113.