home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6669 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.3 KB

  1. Path: sparky!uunet!gatech!prism!gt7080a
  2. From: gt7080a@prism.gatech.EDU (Nathan I. Laredo)
  3. Newsgroups: comp.os.linux
  4. Subject: Character loss is only less frequent now, not gone.
  5. Message-ID: <64327@hydra.gatech.EDU>
  6. Date: 25 Jul 92 05:13:39 GMT
  7. Organization: Georgia Institute of Technology
  8. Lines: 69
  9.  
  10. Just when I thought all the serial problems were gone with 
  11. the new irq routines, once I downloaded a large enough file
  12. I found the errors were still there, only now less frequently.
  13. Instead of happening every 30 seconds it's happening every 
  14. three minutes in my download, although sometimes it only took
  15. one minute to get an error.   This is using a 14.4k v32bis/v.42bis
  16. link with a 19200 DTE rate (38400 was simply too error prone).
  17.  
  18. The system load was as follows:
  19.  12:59pm  up 2 days, 17:44,  1 user,  load average: 0.05, 0.05, 0.01
  20.  
  21. so it's not attributable to doing other things as it usually is.
  22.  
  23. I've included my rzlog for a 6807187 byte file at the end of this 
  24. file for reference.  The transfer took a total of 1.1 hours, so 
  25. the transfer rate was not excessive at all, or outside acceptable
  26. ranges for my particular UART on a 486DX-50 machine.
  27.  
  28. I believe that here a dos-style approach to serial i/o would be
  29. a good idea.  That being on each serial interrupt, find out which
  30. port generated the interrupt and store the character in the appropriate
  31. buffer and return.  This would also have the side effect of implementing
  32. IRQ sharing if the same handler was used for all ports only checking 
  33. to see which has the interrupt bit set.  This could be accomplished
  34. by a read of the byte at each portbase+3.   Right now I just don't have
  35. the time to implement this, but I would imagine that it'd serve to
  36. both reduce code and also make routines a lot faster at the same time
  37. making those people (I'm not included here) who want irq sharing of
  38. serial ports happy.   This would take me less than a day to implement,
  39. but I thought I'd share the idea so more people might be able to work
  40. on it so that I can neglect it like my studies... Right now I just don't
  41. have the time.
  42.  
  43. --
  44. Nathan Laredo, gt7080a@prism.gatech.edu
  45. Georgia Institute of Technology, Atlanta, Georgia, 30332
  46.  
  47. [RZLOG for 6.8MB download follows, total time 1.1 hours roughly]
  48.  
  49. argv[0]=rz Progname=rz
  50. rz ready. Type "sz file ..." to your modem program
  51. Incoming: man.tar.Z 6807187 5234143701 100644
  52. YMODEM header: 6807187 5234143701 100644
  53.  550912 ZMODEM CRC-32    Retry 0: Bad CRC
  54.  877568 ZMODEM CRC-32    Retry 0: Bad CRC
  55.  960512 ZMODEM CRC-32    Retry 0: Bad CRC
  56. 1435648 ZMODEM CRC-32    Retry 0: Bad CRC
  57. 1518592 ZMODEM CRC-32    Retry 0: Bad CRC
  58. 1647616 ZMODEM CRC-32    Retry 0: Bad CRC
  59. 1727488 ZMODEM CRC-32    Retry 0: Bad CRC
  60. 1956864 ZMODEM CRC-32    Retry 0: Bad CRC
  61. Retry 0: Got ZNAK
  62. 2280448 ZMODEM CRC-32    Retry 0: Bad CRC
  63. 3492864 ZMODEM CRC-32    Retry 0: Bad CRC
  64. 3723264 ZMODEM CRC-32    Retry 0: Bad CRC
  65. 4147200 ZMODEM CRC-32    Retry 0: Bad CRC
  66. 4867072 ZMODEM CRC-32    Retry 0: Bad CRC
  67. 5687296 ZMODEM CRC-32    Retry 0: Bad CRC
  68. 6307840 ZMODEM CRC-32    Retry 0: Bad CRC
  69. 6582272 ZMODEM CRC-32    Retry 0: Bad CRC
  70. 6806528 ZMODEM CRC-32    rz 3.17 10-30-91 finished.
  71.  
  72. [end of rzlog, please don't include it in replies]
  73. -- nil
  74. -- 
  75. Anguna V. Ynerqb
  76. Trbetvn Vafgvghgr bs Grpuabybtl, Ngynagn Trbetvn, 30332
  77. hhpc:      ...!{qrpink,ucynof,apne,cheqhr,ehgtref}!tngrpu!cevfz!tg7080n
  78. Vagrearg: tg7080n@cevfz.tngrpu.rqh
  79.