Conference 49.910::kav30

Hi Arancha, 

The amount of VMEBus space you can map to the KAV30 Dual-Ported RAM
is limited by the RAM available on the KAV30.

Also remember that the VAXELN system and programs also reside in the KAV30 
DPM RAM. 

If, however, the customer only wants to map certain 'windows' of the 
32Mb at any one time, then a workaround of mapping and unmapping the required
'windows' can be implemented.

Hope this helps.

Regards

John Cushnie
Digital-PCS
Munich

    Hi,
    
    John is right with his answer... but: if your customer really needs
    32Mb of PHYSICAL(!) RAM, you could ask Roland Svennberg
    (EICMFG::RSVENNBERG) for an upgrade.
    
    Thomas
    

	Thanks for your help .1 and .2

	My customer asks me why the manual (on paged 3.12) said the board can 
map until 256MB. 
	He wants to know how to map the space great than 32MB.
	He has about 20 board's, 7 x KAV30-AA(4MB), 12 or more KAV30-AC (16Mb).
He has a complex topology with vaxstation 4000/90.. and VMEbus.
	
	If he has some boards, the RAM available is the amount of them ?.
	I think he doesn't need upgrade of boards.

	Regards,

	Arancha Nunez
	MCS-Madrid
	

Hi Arancha,

As I said in my first reply, you can only map the physical memory you have 
avaiable on the KAV30 to the VMEBus from the KAV30.

Therefore to map 32MB+ you must first have 32MB+ available to map. 

VAXELN is a memory resident operating system, not a Paging Virtual scheme as 
implemented with OpenVMS.

The KAV30 documentation states that upto 230 MB of S0 space can be mapped 
using the outgoing SGM hardware, but if this amount of physical memory is not 
available then it cannot be mapped.

 What do you mean by the following statement ? I don't understand.

>>
>>	If he has some boards, the RAM available is the amount of them ?.
>>	I think he doesn't need upgrade of boards.
>>


  Regards

John Cushnie.

    Hi,
    
    I think we got confused on what the problem is here:
    
    in 'OUTGOING' mode (KAV_OUT_MAP) you can map up to 230Mb 'virtual'
    memory to the VME, you don't need to have the same amount of 'physical'
    memory available... but you need 'physical' memory for your S/G entries
    as well as PTE's. So what you do is you increase your EBUILD S0
    parameter by 128 for each page you want to map (...I believe it is 128,
    but to be certain, have a look at the documentation...).
    
    Ask your customer for the size of the S0 parameter and also ask him to
    increase it and test it again...
    
    Thomas
    

	Thanks for all.

	My customer tells me the  EBUILD S0 parameter is a maximum value 
	(he thinks)  32767. 

	If the customer needs a new board with 32Mb, which is it the board? 

	Regards,
	Arancha   

    Hi,
    
    your customer is right, 32767 is the maximum page entries allowed in
    EBuild. If you remember that you need 128 pages in S0 for every 64k
    page 'out_mapped', then this gives you a maximum of 16Mbytes you can
    'out_map' (32768 / 128 = 256; 256 * 64kB = 16.384kB). That is an ELN
    restriction, the HW still could handle 230MB through the S/G mechanism.
    
    Upgrading the board to 32MB won't help...
    
    Now why does your customer want to map more than 16Mbytes at once ? Can
    he use a scheme where he, lets say, maps 'chunks' of 4Mbyte only,
    free's them subsequently and maps the next 'chunk' of 4Mbyte ? Yes,
    this increases the overhead, but compared to the time he needs to read
    or write 4/16 Mbyte this is not a big issue...
    
    regards,
    
    Thomas
    

	Thanks.
	
	My customer told me his application needs 16Mb. It's critical by his 
	enviromment.   

	Now, my customer wants to know if there are planning to new version
	of VAXELN. And what happend with the maximum page entries allowed in
	EBuild; by the way the board colud handle 230MB.

	Thanks for all.
	
	Arancha Nunez

Hi Arancha,

 Sorry for being the bearer of bad tidings, but VAXELN
 Engeering are not planning any new major releases of the 
 VAXELN product for the future.

 The earlier suggestions of mapping the 16 or 32 MBs
 of VMEBus space in small chunks seems to be the easiest 
 workaround for your customer's application.

Regards

John Cushnie.

    Thanks for your help John.
    
    Regards,
    	Arancha