home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12697 < prev    next >
Encoding:
Text File  |  1992-08-20  |  3.1 KB  |  63 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!odin!sgihub!zola!zuni!anchor!olson
  3. From: olson@anchor.esd.sgi.com (Dave Olson)
  4. Subject: Re: ec0: too many oflows, changing modes?
  5. Message-ID: <or2pgqs@zuni.esd.sgi.com>
  6. Sender: news@zuni.esd.sgi.com (Net News)
  7. Organization:  Silicon Graphics, Inc.  Mountain View, CA
  8. References: <1992Aug20.091238.17149@news.uni-stuttgart.de>
  9. Date: Fri, 21 Aug 92 02:07:29 GMT
  10. Lines: 51
  11.  
  12. In <1992Aug20.091238.17149@news.uni-stuttgart.de> andreas@awstar.rus.uni-stuttgart.de (Andreas Wierse) writes:
  13.  
  14. | Hi,
  15. | 
  16. | when I did "ifconfig debug" the following entries appeared in the SYSLOG:
  17. | 
  18. | Aug 20 02:43:48 awstar unix: ec0: too many oflows, changing modes
  19. | Aug 20 03:48:13 awstar unix: ec0: dma stopped, rstat = 0x11, crbdp = 0x8015FAE0
  20. | Aug 20 04:49:18 awstar last message repeated 2 times
  21. | Aug 20 04:49:18 awstar unix: ec0: too many oflows, changing modes
  22. | Aug 20 09:21:42 awstar unix: ec0: dma stopped, rstat = 0x11, crbdp = 0x8015FB40
  23. | 
  24. | Can anyone explain what these messages mean? I didn't find anything in
  25. | the manual pages that could help me.
  26.  
  27. They are debug messages, not surprisingly.  The interesting one is the
  28. 'too many oflows' message.  Basicly, we are working around a chip bug
  29. by putting the ethernet chip into promiscuous mode, and leaving in that
  30. mode for a while.  Some nets run into this a lot, others don't.  When
  31. the mode switches, and how long it stays that way can be controlled
  32. by the variables in /usr/sysgen/master.d/if_ec2.
  33.  
  34. Later versions of the ethernet chip have some changes to remove this
  35. problem.  There are no real problems associated with running the
  36. chip in promiscuous mode, aside from more interrupts, which have
  37. negligible impact on performance (the chip is run in promiscuous mode
  38. anyway, if you use the network monitoring prodcut).
  39.  
  40. | Additionally we have a problem with NFS in that it transfers data
  41. | (write only) in a kind of burst mode.  This is like: two or three
  42. | hundred KB are transferred, then there are a few seconds delay, then
  43. | the next some hundred KB are transfered and so on. Watching this with
  44. | nfsstat shows that everytime when it stops for a while afterwards
  45. | timeout and retrans are incremented by one. Maybe the reason for the
  46. | timeout has something to do with the ifconfig error messages. (they
  47. | don't coincide in time).
  48.  
  49. It is possible that they are related, but more likely you are having
  50. physical network problems resulting in dropped packets.  It is surprising
  51. how significant an impact a few dropped packets will have on NFS performance.
  52. One of the symptoms of the problem that the promiscuous mode workaround
  53. fixes was in fact dropped packets, but it doesn't sound like they match
  54. up in your case.  You could reconfigure your kernel to remain in
  55. promiscuous mode for longer periods once entered, and see if that has
  56. an effect on your performance; you could also look around for other
  57. network problems.
  58.  
  59. --
  60. Let no one tell me that silence gives consent,  |   Dave Olson
  61. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  62.     Maria Isabel Barreno                        |   olson@sgi.com
  63.