Re: [PD] [Gem] pix-native? [RAM disk]
vade wrote:
If you can sustain the datarates for the number of streams you want the
uncompressed will always win with ease of CPU decoding, at the expense
of being NASTILY hard on your drives.
Chris also suggested using a RAM disk, which would save a lot of wear
and tear on the HD in the case of uncompressed video.
I did some research on RAM disks for OS X. Seems like you can skip
buying a license for Rambunctious and just use the command line. I
promised Baruch that I would post on this, so some recipes follow,
copied from various internet sources...
best,
d.
*
#!/bin/sh
NUMSECTORS=524288
# 64mb = 131072
# 128mb = 262144
# 256mb = 524288
# 512mb = 1048576
# 1gb = 2097152
mydev=`hdid -nomount ram://$NUMSECTORS`
newfs_hfs $mydev
mkdir /tmp/ramdrive
mount -t hfs $mydev /tmp/ramdrive
Save the file with a name like 'mkramdisk.sh', and give it executable
permissions:
chmod 755 mkramdisk.sh
Run it. Voila. This script is right out of the man page for hdid. You
can also read about doing this at
http://www.kernelthread.com/mac/osx/arch_fs.html
Creating a RAM disk was easy in 9, and, until now, undocumented in X.
There is a utility called ramBunctious (available at VersionTracker)
that brings this functionality back to X (well, at least it puts a GUI
on it).
For those of you interested in how this works from the command line, its
pretty simple. First, create a read/write disk image (you can do this in
Disk Copy). Next, create the /dev entry for RAM using the hdid tool.
Finally, copy the contents of the disk image to the RAM /dev entry and
mount it. Because the disk image is mounted from the /dev entry, any
changes occur in RAM. Here are the Terminal commands:
[First, calculate the number of 512K blocks you need: numblocks = (image
size in MB) * 2048; for example: 5MB = 10240 blocks]
% hdid -nomount ram://numblocks
[result: /dev/disk1]
% dd if=/path/to/image/file.dmg of=/dev/disk1 bs=512
[result:2866+0 records in
2866+0 records out
1467392 bytes transferred in 1 secs (1467392 bytes/sec)]
% hdiutil mount /dev/rdisk1
You need to change the 1 in disk1 and rdisk1 to whatever number is
returned by the first command.
Please be sure to check out ramBunctious; it has excellent documentation
on the state of RAM disks in X and when you should/should not use them.
The reason I mention it here is because it could have a huge positive
impact on the functionality of a bootable X cd.
**
How to create a RAM disk on OS X
32768 = size in sectors (16MB in this case, a sector is 512 bytes)
$ hdid -nomount ram://32768
/dev/disk1
$ newfs_hfs /dev/disk1
$ mkdir /tmp/ramdisk1
$ mount -t hfs /dev/disk1 /tmp/ramdisk1
To unmount:
hdiutil detach /dev/disk1
to osx files tiger ramdisk ram disk by peter on Thu Mar 30 16:25:22 EST 2006
**
I have thrown together a quick script for anybody that wants to create a
ramdisk regularly. It's flexible enough for me, but can be edited to
offer more options (if u know a little .sh scripting). The disk is
dynamicly named and will show up on the desktop when the script is
finished. Unmounting can be done as any drive in the finder. The major
differences between my and the above approach is that I use diskutil to
mount the created drive, so Finder likes it better, and i give the
volume a label, so it can be better recognized by the user ...
Here it is:
Leila:~ samynew[14:30:55]$ cat ramdisk
#!/bin/bash
if [ -n $2 ]; then ARG_ERR=ERR; fi
if [ -z $1 ]; then ARG_ERR=ERR; fi
if [ -n $ARG_ERR ];
then
echo 1 argument: size in MB
exit
fi
MB_SIZE=$1
let MB_SIZE *= 2048
echo Creating ${MB_SIZE} 512-blocks ramdisk
CREATED_RAMDISK=`hdid -nomount ram://${MB_SIZE}`
echo New block device: ${CREATED_RAMDISK}
DISK_NAME=`basename ${CREATED_RAMDISK}`
echo Creating volume with label: ${DISK_NAME}
newfs_hfs -v ${DISK_NAME} /dev/r$CREATED_RAMDISK
echo Mounting in /Volumes/${DISK_NAME}
mkdir /Volumes/${DISK_NAME}
diskutil mount ${CREATED_RAMDISK}
Make sure it's chmodded to be executable: chmod u+x ramdisk
Run as: ./ramdisk size-in-MB
For those of you interested in how this works from the command line,
it's pretty simple. First, create a read/write disk image (you can do
this in Disk Copy). Next, create the /dev entry for RAM using the hdid
tool. Finally, copy the contents of the disk image to the RAM /dev entry
and mount it. Because the disk image is mounted from the /dev entry, any
changes occur in RAM. Here are the Terminal commands:
First, calculate the number of 512K blocks you need: numblocks = (image
size in MB) * 2048; for example: 5MB = 10240 blocks. Open a terminal and
type:
% hdid -nomount ram://numblocks
[result: /dev/disk1]
Replace numblocks with the number you calculated in the first step. Next
type:
% dd if=/path/to/image/file.dmg of=/dev/disk1 bs=512
[result:2866+0 records in
2866+0 records out
1467392 bytes transferred in 1 secs (1467392 bytes/sec)]
% hdiutil mount
Re: [PD] [Gem] pix-native? [RAM disk]
hi,
some sources suggest that there is no or little advantage to use a
ramdisk in os x because the system caches data which has frequent
access anyway.
so a ramdisk can be counterproductive in a cenario where you have
little ram:
lets say you have one gig memory. 300 mb are used by some
applications which are open, and another 300 by the system. now you
have a video in your ramdisk of also 300. the system tries to cache
it because it wants to accellerate but can't allocate enough anymore
and data will be swaped on the harddisk..
so you end up with less performance and more harddrive access because
of the ramdisk..
i'm curious about your findings.
greetings, m.
http://lowendmac.com/x-basics/02/0201.html
http://www.kernelthread.com/forums/viewtopic.php?t=138
Am 30.07.2007 um 10:08 schrieb Derek Holzer:
vade wrote:
If you can sustain the datarates for the number of streams you
want the
uncompressed will always win with ease of CPU decoding, at the
expense
of being NASTILY hard on your drives.
Chris also suggested using a RAM disk, which would save a lot of wear
and tear on the HD in the case of uncompressed video.
I did some research on RAM disks for OS X. Seems like you can skip
buying a license for Rambunctious and just use the command line. I
promised Baruch that I would post on this, so some recipes follow,
copied from various internet sources...
best,
d.
*
#!/bin/sh
NUMSECTORS=524288
# 64mb = 131072
# 128mb = 262144
# 256mb = 524288
# 512mb = 1048576
# 1gb = 2097152
mydev=`hdid -nomount ram://$NUMSECTORS`
newfs_hfs $mydev
mkdir /tmp/ramdrive
mount -t hfs $mydev /tmp/ramdrive
Save the file with a name like 'mkramdisk.sh', and give it executable
permissions:
chmod 755 mkramdisk.sh
Run it. Voila. This script is right out of the man page for hdid. You
can also read about doing this at
http://www.kernelthread.com/mac/osx/arch_fs.html
Creating a RAM disk was easy in 9, and, until now, undocumented
in X.
There is a utility called ramBunctious (available at VersionTracker)
that brings this functionality back to X (well, at least it puts a GUI
on it).
For those of you interested in how this works from the command
line, its
pretty simple. First, create a read/write disk image (you can do
this in
Disk Copy). Next, create the /dev entry for RAM using the hdid tool.
Finally, copy the contents of the disk image to the RAM /dev entry and
mount it. Because the disk image is mounted from the /dev entry, any
changes occur in RAM. Here are the Terminal commands:
[First, calculate the number of 512K blocks you need: numblocks =
(image
size in MB) * 2048; for example: 5MB = 10240 blocks]
% hdid -nomount ram://numblocks
[result: /dev/disk1]
% dd if=/path/to/image/file.dmg of=/dev/disk1 bs=512
[result:2866+0 records in
2866+0 records out
1467392 bytes transferred in 1 secs (1467392 bytes/sec)]
% hdiutil mount /dev/rdisk1
You need to change the 1 in disk1 and rdisk1 to whatever number is
returned by the first command.
Please be sure to check out ramBunctious; it has excellent
documentation
on the state of RAM disks in X and when you should/should not use
them.
The reason I mention it here is because it could have a huge positive
impact on the functionality of a bootable X cd.
**
How to create a RAM disk on OS X
32768 = size in sectors (16MB in this case, a sector is 512 bytes)
$ hdid -nomount ram://32768
/dev/disk1
$ newfs_hfs /dev/disk1
$ mkdir /tmp/ramdisk1
$ mount -t hfs /dev/disk1 /tmp/ramdisk1
To unmount:
hdiutil detach /dev/disk1
to osx files tiger ramdisk ram disk by peter on Thu Mar 30 16:25:22
EST 2006
**
I have thrown together a quick script for anybody that wants to
create a
ramdisk regularly. It's flexible enough for me, but can be edited to
offer more options (if u know a little .sh scripting). The disk is
dynamicly named and will show up on the desktop when the script is
finished. Unmounting can be done as any drive in the finder. The major
differences between my and the above approach is that I use
diskutil to
mount the created drive, so Finder likes it better, and i give the
volume a label, so it can be better recognized by the user ...
Here it is:
Leila:~ samynew[14:30:55]$ cat ramdisk
#!/bin/bash
if [ -n $2 ]; then ARG_ERR=ERR; fi
if [ -z $1 ]; then ARG_ERR=ERR; fi
if [ -n $ARG_ERR ];
then
echo 1 argument: size in MB
exit
fi
MB_SIZE=$1
let MB_SIZE *= 2048
echo Creating ${MB_SIZE} 512-blocks ramdisk
CREATED_RAMDISK=`hdid -nomount ram://${MB_SIZE}`
echo New block device: ${CREATED_RAMDISK}
DISK_NAME=`basename ${CREATED_RAMDISK}`
echo Creating volume with label: ${DISK_NAME}
newfs_hfs -v ${DISK_NAME} /dev/r$CREATED_RAMDISK
echo Mounting in /Volumes/${DISK_NAME}
mkdir /Volumes/${DISK_NAME}
diskutil mount ${CREATED_RAMDISK}
Make sure it's chmodded to be executable: chmod u+x
Re: [PD] [Gem] pix-native? [RAM disk]
On Mon, 30 Jul 2007, Derek Holzer wrote: Chris also suggested using a RAM disk, which would save a lot of wear and tear on the HD in the case of uncompressed video. What's the difference between a file on the HD that can be cached to RAM, and a file on the ramdisk that can be swapped to the HD ? Both can be in either place depending on OS decisions, so... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Gem] pix-native? [RAM disk]
There is always the possibility of paging RAM to disk at any point for any bit of memory and this goes for something like pix_buffer or Pd's table/array too. Obviously, the machine needs to have not only the free memory for the RAM disk but a comfortable amount of headroom. The OSX memory manager won't always do the right thing, but one can try to minimize its stupidity. A lot of the kernel code is still based on assumptions about ancient hardware and non-existent server scenarios, and it certainly pays the price for it. On 7/30/07, Max Neupert [EMAIL PROTECTED] wrote: hi, some sources suggest that there is no or little advantage to use a ramdisk in os x because the system caches data which has frequent access anyway. so a ramdisk can be counterproductive in a cenario where you have little ram: lets say you have one gig memory. 300 mb are used by some applications which are open, and another 300 by the system. now you have a video in your ramdisk of also 300. the system tries to cache it because it wants to accellerate but can't allocate enough anymore and data will be swaped on the harddisk.. so you end up with less performance and more harddrive access because of the ramdisk.. i'm curious about your findings. greetings, m. http://lowendmac.com/x-basics/02/0201.html http://www.kernelthread.com/forums/viewtopic.php?t=138 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
