home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / apollo / 3275 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.9 KB  |  73 lines

  1. Newsgroups: comp.sys.apollo
  2. Path: sparky!uunet!wupost!gumby!destroyer!terminator!pisa.citi.umich.edu!rees
  3. From: rees@pisa.citi.umich.edu (Jim Rees)
  4. Subject: problem with writing large files from Fortran
  5. Message-ID: <5a8e0403.1bc5b@pisa.citi.umich.edu>
  6. Sender: news@terminator.cc.umich.edu (Usenet Owner)
  7. Reply-To: Antonio Hernandez <AVH@IBMA.ipp-garching.mpg.de>
  8. Organization: University of Michigan IFS Project
  9. Date: Fri, 14 Aug 1992 12:56:47 GMT
  10. Lines: 61
  11.  
  12. Can anyone help this guy?
  13.  
  14. Date:         Thu, 13 Aug 92 14:09:14 EST
  15. From: Antonio Hernandez <AVH@IBMA.ipp-garching.mpg.de>
  16. To: Jim Rees <JIM.REES@UMICH.EDU>
  17. Message-Id: <9208140700.AA03976@umich.edu>
  18. Subject:      question
  19.  
  20. Dear Mr.Rees: I have a question Which I would like to formulate to the
  21. Apollo world. If this is not the appropriate channel please forgive me
  22. and let me know how to proceed. Thanks: Antonio Hernandez.
  23. from: Antonio Hernandez
  24. e-mail: avh at ibma.mpa.ipp-garching.mpg.de
  25. subject: question to the apollo world
  26.  
  27.  Question: I have an Apollo DN10000 at the Simon Bolivar University
  28. (USB) in Caracas-Venezuela. It runs under SR.10.2.p and has one
  29. multidisk (w0:0+w1:0) comprising two 700Mb units in a sector-striped
  30. configuration plus a second multidisk (w0:1+w1:1) of two 370Mb units
  31. with the same sector-striped configuration. It also has two processors
  32. and 64Mbytes of RAM:  Let's call this machine "USB" (Fortran Compiler
  33. ftn.v.10.8p).
  34. I also work with a DN10000 at the Max Planck Institute for Astro-
  35. physics in Munich Germany in a colaboration project. This station,
  36. which we can call "MPA", is a one processor machine with a multidisk
  37. (w0:0+w0:1) of two 700Mb units in a cylinder-striped configuration,
  38. with 32Mb RAM and running under SR.10.1.p. (Fortran Comp.:ftn.v.10.7p)
  39. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=======>
  40. The problem is as follows: I run MUNICH code (fortran code for
  41. molecular calculations) on the MPA station without any trouble. This
  42. particular code opens a large file for reading (about 100MB)and
  43. simultaneously opens a file for writing the processed data: this
  44. second file will be also very big at the end of the program  (some
  45. 200MB). The MPA mchine does mostly I/O and expends little CPU time on
  46. this molecular code.
  47. --When I run the same code on the USB machine, a strange thing happens
  48. when half of the output file is written: You can hear large disk
  49. activity but the size of the output file doen not change, i.e, the
  50. machine is writing data to some temporal file (swapping area?) and
  51. from there to god knows where!, but it never writes the final data
  52. to the output file. It seems like there is a limit on the number of
  53. blocks this machine can move, or it lost the address of the last
  54. record read on the first file. Both read and write files are sequential
  55. unformatted with a record length of 1400 integer words.---
  56. I have tried recompiling but when the size of the problem is small the
  57. code runs without problems (small input output files of about 40Mb) and
  58. when the size increases (input output files of about 80Mb) it breaks.
  59. Once I could make it run by running the code on the first multidisk
  60. (I/O also in the first multidisk) and I move all paging (swapping) to
  61. the second multidisk: On other words, I keep the operating system and
  62. the code running on the first multidisk and turn off paging there by
  63. changing the name of the swapping device on /dev directory, and
  64. define new OS paging area only on the on the second multidisk with the
  65. /etc/swap command.
  66. All this is very strange because here in Germany I do not seem to have
  67. any problem with the size of the problem: Right now I am running a
  68. very large case that handles I/O files of 300Mb each!. Is there a
  69. problem with the RS.10.2.p operating system? or with the way it
  70. handles swapping, because the /etc/swap command do not even exist under
  71. RS.10.1.p operating system at the MPA machine. Is there a hardware probl
  72.                        ****PLEASE HELP****Antonio Hernandez.
  73.