home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / fortran / 2794 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.0 KB
  1. Path: sparky!uunet!mcsun!sun4nl!cwi.nl!dik
  2. From: dik@cwi.nl (Dik T. Winter)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: Week days
  5. Message-ID: <6739@charon.cwi.nl>
  6. Date: 22 Jul 92 01:55:19 GMT
  7. References: <1992Jul21.200531.6612@ac.dal.ca>
  8. Sender: news@cwi.nl
  9. Organization: CWI, Amsterdam
  10. Lines: 34
  11.  
  12. In article <1992Jul21.200531.6612@ac.dal.ca> indran@ac.dal.ca writes:
  13.  >     I am running a fortran program which is relativly huge and 
  14.  > require nearly 30 hrs of cpu time, on VAX 8800.TDuring 
  15.  > week days (when there are many users) the program crashes 
  16.  > very easly with the error arithematic overflow. The same 
  17.  > program without any change will run during weekends. Could 
  18.  > someone tell me what is going on ? If the results depend on 
  19.  > week days can I trust them ?. 
  20.  > 
  21. Did you also look at the phase of the moon?  They have also a profound
  22. influence.
  23.  
  24. But seriously.  I do not know under what circumstances you are running
  25. your program.  It may be that it generates some traffic on ethernet
  26. for data/results/swap, etc.  Not everything is 100% save.  Just an
  27. hour ago I did edit a file, and when writing it back one bit was
  28. flipped (changing the letter 'r' to 'b').  Such things can happen,
  29. and may be more frequent when there are a lot of users.  Other things
  30. you might think about is obscure bugs in the operating system where,
  31. under some conditions, the wrong data is paged in or somesuch.  (Yes,
  32. all operating systems contain bugs.)  Those bugs especially show up on
  33. heavily loaded systems.
  34.  
  35. Now I do not know whether you should trust your results.  There is still
  36. another possibility, you know.  Uninitialized data.  Running on an idle
  37. processor might very well produce the same initial values on every run,
  38. while this is less likely if the processor is busy.
  39.  
  40. Not much help, I am afraid.  But my motto is: never trust the results
  41. produced by a computer.
  42. -- 
  43. dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
  44. home: bovenover 215, 1025 jn  amsterdam, nederland
  45. dik@cwi.nl
  46.