home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / alpha / 131 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.2 KB
  1. Xref: sparky vmsnet.alpha:131 comp.sys.dec:7079
  2. Path: sparky!uunet!usc!cs.utexas.edu!uwm.edu!spool.mu.edu!agate!dog.ee.lbl.gov!randolf!ctday
  3. From: ctday@randolf.lbl.gov (Christopher T. Day)
  4. Newsgroups: vmsnet.alpha,comp.sys.dec
  5. Subject: Re: No 64-bit OpenVMS soon?
  6. Date: 22 Jan 1993 18:44:16 GMT
  7. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  8. Lines: 67
  9. Distribution: world
  10. Message-ID: <28581@dog.ee.lbl.gov>
  11. References: <1993Jan15.194312.3438@sol.UVic.CA> <1993Jan18.172458.24506@eco.twg.com> <1993Jan18.211506.27601@oracle.pnl.gov> <1jg5msINN1mk@manuel.anu.edu.au> <C13yJK.CMJ@dscomsa.desy.de> <1993Jan20.001847.1807@eco.twg.com> <C19M1B.KHM@dscomsa.desy.de>
  12. Reply-To: ctday@randolf.lbl.gov (Christopher T. Day)
  13. NNTP-Posting-Host: 128.3.196.7
  14.  
  15. In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
  16. Hallam-Baker) writes:
  17. |> In article <1993Jan20.001847.1807@eco.twg.com>, reece@eco.twg.com (Reece R.
  18. |> Pollack) writes:
  19. |> 
  20. |> |>In article <C13yJK.CMJ@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
  21. |> |>Hallam-Baker) writes:
  22. |> |>|>What matters a damn sight less than a 64 bit O/S is a 64 bit
  23. database. When
  24. |> |>will
  25. |> |>|>Rdb be 64 bit is the real question.
  26. |> |>
  27. |> |>Not being sarcastic in the least, what part of RDB needs to be 64 bit?
  28. |> |>Expanding the address space from 32 to 64 bits is not in itself going
  29. |> |>to make things better, unless the application is starved for memory.
  30. |> |>Remember that Alpha/VMS doesn't suffer from the Vax/VMS 512Mb physical
  31. |> |>memory limitation, even though any single process is still limited to
  32. |> |>a 2Gb virtual address space.
  33. |> 
  34. |> Each of our events is approx 100Kb
  35. |> 
  36. |> We take 10 million of them per second.
  37. |> 
  38. |> Even with filtering we take Terabytes of data per month.
  39. |> 
  40. |> 2Gb is small beans, we will be getting machines with that sort of
  41. memory within
  42. |> the next few years. The successor machine to ZEUS will be producing 2 GB
  43. |> events.
  44. |> 
  45. |> 
  46. |> |>|>Although it would be handy to do big transfers of data - the VMS
  47. 64K limit
  48. |> |>is
  49. |> |>|>far too small, this is not essential yet. It will become essential once
  50. |> |>alphas
  51. |> |>|>start operating with a 64K page size though!
  52. |> |>
  53. |> |>The limitiation of I/Os to 64Kb was lifted quite some time ago. The
  54. VAX/VMS
  55. |> |>I/O User's Reference Manual: Part 1 for VAX/VMS V4.4 states:
  56. |> |>
  57. |> |>"Non-DSA disk devices can read or write up to 65.535 bytes in a single
  58. |> |> request. DSA devices connected to an HSC50 can transfer up to 4 billion
  59. |> |> bytes in a single request. In all cases, the maximum size of the transfer
  60. |> |> is limited by the number of pages which can be faulted into the process's
  61. |> |> working set and then locked into memory."
  62. |> |>
  63. |> |>The relevant fields of the IRP were expanded to 32 bits during the
  64. V3 -> V4
  65. |> |>enhancements.
  66. |> 
  67. |> Read the device driver manual and look at the format of the QIO. The 16 bit
  68. |> length is hard coded in there.
  69. |> 
  70. |> What I would like to do is to read in single events with single reads.
  71. |> 
  72. |> --
  73. |> 
  74. |> Phill Hallam-Baker
  75.  
  76. Hmmm, it's been awhile since I've looked at this, but I thought the
  77. 16-bit QIO field was a transfer count of _things_, not necessarily
  78. bytes. The driver could convert that number to a larger one for the
  79. IRP's 32-bit field.
  80.  
  81. Chris Day
  82.