English Amiga Board


Go Back   English Amiga Board > Support > support.Other

 
 
Thread Tools
Old 04 March 2014, 07:33   #1
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
RAM: drive oddity

Hi all,

I get some strange results when stuffing the RAM: drive with junk. I've got some spare time as well as some junk so why not thought I.

Anyway, the system has 2M of Chip RAM and 64M of other memory. The junk file is 14M in size. Three of these accomodate themselves quite comfortably on the RAM: drive, leaving some 19M free. With some windows open and MiamiDX lurking in the background, but anyway.

Quite unexpectedly, there's no place for another 14M of junk on the RAM: drive! One might think 14M file should pretty well fit within 19M of free space, but it just won't. The system complains about either RAM: drive being full, or out of RAM.

Now there's more to it. If I use smaller junk files (sourced from aminet.net btw), I can easily fill up almost all of the rest free space. Well, not really: the Workbench still shows ~2M of Fast RAM available, but the system starts eating Chip RAM instead. Perhaps the system wants to keep the last 2M of Fast mem for its own needs, yet the 14M file should fit within 17M shouldn't it?
tnt23 is offline  
AdSense AdSense  
Old 04 March 2014, 09:31   #2
thomas
Registered User
thomas's Avatar
 
Join Date: Jan 2002
Location: Germany
Posts: 5,661
You are only looking at the total sum of free memory. This is not right. You also have to look at the largest block of free memory or at the fragmemt size in general. An allocation will fail if it cannot be allocated as one continuous block, even if the sum of all free blocks is larger than the demanded amount.

So the 14M file will not fit into 17M if the latter actually is 10M + 7M for example.
thomas is offline  
Old 04 March 2014, 10:11   #3
Bamiga2002
BlizzardPPC'less

Bamiga2002's Avatar
 
Join Date: May 2004
Location: Finland
Age: 40
Posts: 3,210
Send a message via MSN to Bamiga2002
Would "Avail FLUSH" help in this situation?
Bamiga2002 is offline  
Old 04 March 2014, 10:27   #4
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
Thomas, thanks. I should have thought about memory allocation first!

Bamiga2002, I'll give it a try.
tnt23 is offline  
Old 04 March 2014, 10:57   #5
thomas
Registered User
thomas's Avatar
 
Join Date: Jan 2002
Location: Germany
Posts: 5,661
Quote:
Originally Posted by Bamiga2002 View Post
Would "Avail FLUSH" help in this situation?

It does not defragment if you mean that. Avail Flush asks libraries and devices to leave and to free occupied memory. This can surely solve a memory shortage. But it does not necessarily lead to bigger fragments.

Adjacent free memory areas are combined to larger blocks automatically (since Kick 1.3, I think. Earlier versions had a tool for it: MergeMem IIRC).
thomas is offline  
Old 04 March 2014, 12:50   #6
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
With 14M files, it all fits very well. Of those free 19M the biggest chunk is almost exactly 14M, AVAIL reports.

Now, if I try to copy 37,552,706 bytes of another junk file to RAM:, I get 'Volume Ram Disk is full' requester. At the same time, AVAIL reports the largest chunk to be 64,751,280 bytes. I know the RAM drive is not an ordinary disk drive; is there a file size limit with it?
tnt23 is offline  
Old 04 March 2014, 14:30   #7
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,967
My experiences is that "avail flush" does not increase the amount of largest block in memory. Most time the fragmentation raised. But that depends on differnt things and the available size of memory. The more the better results. For example on my A1200 32MB I can easily get >70% fragmentation just by using MiamiDX, IBrowse and YAM2.9.

If you want some detailed info about fragmentation there is FragMeter and ShowMem in the PoolMem archive.
daxb is offline  
Old 04 March 2014, 17:28   #8
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,937
tnt23: What program are you using to copy files to RAM:?
Quote:
Originally Posted by thomas View Post
Adjacent free memory areas are combined to larger blocks automatically (since Kick 1.3, I think. Earlier versions had a tool for it: MergeMem IIRC).
Exec V36 was the first to coalesce contiguous memory lists automatically. MergeMem does that under Kickstart 1.x. But that doesn't affect fragmentation when the system is in use, it's to (for example) give someone who has four 2MB Zorro II RAM boards an 8MB contiguous region, instead of limiting the maximum contiguous block to <2MB.
mark_k is offline  
Old 05 March 2014, 06:41   #9
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
mark_k, I just type "copy junk.bin ram:"
tnt23 is offline  
Old 05 March 2014, 11:10   #10
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
daxb, thanks for the tip with ShowMem. It does show that over 60M are free, with little to now fragmentation. Yet copying the 37M file fails.

Just in case, gave MBRTEST-2 a couple of full runs (except for destructive tests), all 64M show no errors.

I might try a fresh OS installation, and maybe some RAM drive replacements like RAD:.

(KS 40.68, WB 39.29, A3000)

Last edited by tnt23; 05 March 2014 at 11:19.
tnt23 is offline  
Old 05 March 2014, 12:10   #11
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,937
Quote:
Originally Posted by tnt23 View Post
mark_k, I just type "copy junk.bin ram:"
Which version of the Copy command are you using? I'm wondering whether the behaviour of the AmigaOS 3.5/3.9 one (I use 3.1 here) was changed.

The AmigaDOS Manual 3rd edition (which was written in the Kickstart 2.04 days) explains the BUFFER option for the copy command. That sets the number of 512-byte buffers to use, default 200. Setting BUFFER=0 tells Copy to use a buffer the size of the entire file being copied.

If your version of Copy defaults to the BUFFER=0 behaviour, that could explain the problem you had copying to RAM:. For example if you're copying a 16MB file specifying BUFFER=0, Copy will allocate 16MB for its buffer, plus the RAM: handler will need 16MB for the file data. So unless you have >32MB free, the copy would fail in that case.

You could try manually specifying a smaller buffer size and see whether that makes any difference: Copy largefile.bin RAM: BUFFER=100
mark_k is offline  
Old 05 March 2014, 12:58   #12
Bamiga2002
BlizzardPPC'less

Bamiga2002's Avatar
 
Join Date: May 2004
Location: Finland
Age: 40
Posts: 3,210
Send a message via MSN to Bamiga2002
Quote:
Originally Posted by mark_k View Post
Which version of the Copy command are you using? I'm wondering whether the behaviour of the AmigaOS 3.5/3.9 one (I use 3.1 here) was changed.

The AmigaDOS Manual 3rd edition (which was written in the Kickstart 2.04 days) explains the BUFFER option for the copy command. That sets the number of 512-byte buffers to use, default 200. Setting BUFFER=0 tells Copy to use a buffer the size of the entire file being copied....
Now if that theory holds water, how on earth would you be able to copy eg. a 1.5GB file?
Bamiga2002 is offline  
Old 05 March 2014, 13:47   #13
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,937
If Copy is unable to allocate the requested amount of buffer, it retries allocating successively smaller amounts until the allocation succeeds.
mark_k is offline  
Old 05 March 2014, 15:40   #14
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
mark_k, you are absolutely right! As soon as I set BUFFERS to 100 or 1000, everything copies just fine.

How does one tell the version of copy command? WB "About" window is titled "3.1 ROM", KS 40.68, WB 39.29.
tnt23 is offline  
Old 05 March 2014, 17:55   #15
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,937
Version 39.29 corresponds to Workbench 3.0. Since you're using Kickstart 3.1. I'd recommend using Workbench 3.1 instead.

I wonder whether the Workbench 3.0 Copy command has a bug/problem and maybe defaults to BUFFER=0 if you don't specify it? Or perhaps you're using a third-party replacement for the Copy command?

In a CLI/Shell window type this:
Which Copy
That will tell you where the Copy command is (e.g. for me it says System3.1:C/Copy).
Version [location of your Copy command] FULL
will show you the version.

Also, type Alias and see if there are any Copy-related aliases. For example, someone could have put
Alias Copy "Copy BUFFER=0 "
in your S:Shell-Startup file.
mark_k is offline  
Old 06 March 2014, 06:45   #16
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
Must have installed WB3.0, that was six years ago

Code:
5.Rescue:> which copy
Rescue:C/Copy
5.Rescue:> version rescue:c/copy full
copy 38.1 (05/20/92)
5.Rescue:>
ALIAS only sets XCopy for Copy CLONE and Clear for Echo with some parameters, no other references to BUFFER anywhere.

If the WB 3.0 Copy command indeed defaults to BUFFER=0, then it should fail if I try to copy big file from non-RAM drive to non-RAM drive given the file is bigger than available memory space. Somebody would have hit this issue already.
tnt23 is offline  
Old 06 March 2014, 12:32   #17
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,967
Update to at least OS 3.1 as recommended
daxb is offline  
Old 06 March 2014, 13:35   #18
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,937
Quote:
Originally Posted by tnt23 View Post
If the WB 3.0 Copy command indeed defaults to BUFFER=0, then it should fail if I try to copy big file from non-RAM drive to non-RAM drive given the file is bigger than available memory space. Somebody would have hit this issue already.
Assuming Copy version 38.1 (which is the same as on Workbench 2.1 btw) has the same fallback code as Copy on Workbench 3.1, if it can't allocate the full file size it keeps trying successively smaller sizes until the allocation succeeds. In practice that means it uses a buffer size roughly equal to the largest contiguous chunk of memory.

Because of that, ironically you probably wouldn't notice a problem copying a large file to RAM: if your memory is very fragmented (because then the largest chunk will be quite small).

Edit to add: I looked at the Copy 38.1 code and it does have this bug. If you don't specify a number of buffers, it tries to allocate a buffer as big as the entire file (and as explained if that allocation fails, it ends up allocating the largest free block instead). I could post a patch/fix for it, but you might as well just copy C/Copy from a Workbench 3.1 disk and use that instead.

I just noticed that the bug was mentioned in the V38_V39_OS_Changes document on the Amiga Developer CD 2.1:
Code:
  o The default size for the buffers used was always equivalent to (BUF=0)
    which caused the buffers to be the size of the files being copied.
    This was contrary to the docs, and caused problems when copying large
    files through Envoy, as it could easily eat up all the memory in the
    system, not leaving enough for the memory needed by Envoy.  The
    default size is now BUF=128 which gives a 64K buffer.

Last edited by mark_k; 06 March 2014 at 14:18.
mark_k is offline  
Old 06 March 2014, 17:08   #19
tnt23
Registered User
tnt23's Avatar
 
Join Date: Feb 2008
Location: Saint-Petersburg / Russia
Posts: 312
mark_k, excellent explanation and analysis.

Replacing the Copy program with a more recent one will be simpler than going for full 3.1 installation. I only use this Rescue: system for troubleshooting and debugging my Zorro memory boards, and usially run memory testing programs and do LHA packing/unpacking with RAM: drive. Running upon this Copy issue was my very own luck
tnt23 is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
SCSI DVD-Ram Drive and DVDs Info-Seeker support.Hardware 6 04 May 2017 17:17
Amiga 1000, RAM and Hard Drive Support JohnnyL support.Hardware 1 13 September 2010 00:21
RAM for A590 hard drive John request.Other 4 18 January 2010 14:40
Need a slimline drive or 128mb ram ? adonay MarketPlace 0 21 November 2007 17:08
WinUAE 1.3.4.0 (maybe older versions?) oddity? Mclane support.WinUAE 2 03 January 2007 11:30

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08838 seconds with 15 queries