The time now is Thu 21 Feb 2019, 22:49
All times are UTC - 4 |
Page 17 of 29 [432 Posts] |
Goto page: Previous 1, 2, 3, ..., 15, 16, 17, 18, 19, ..., 27, 28, 29 Next |
Author |
Message |
heywoodj
Joined: 15 Mar 2009 Posts: 83
|
Posted: Wed 05 Jun 2013, 00:01 Post subject:
|
|
heywoodj wrote: |
Well this wifi problem is turning out to be bigger than I thought at first, as I'm unable to connect to a second wireless router...
|
After trying to connect to a couple more routers as I mentioned here, http://murga-linux.com/puppy/viewtopic.php?t=86425, I concluded that in fact the wireless card was working, but in a very inadequate way. The maximum reliable connection range is about 15 ft (~5 m) and less if walls/floors are involved.
I don't think I ever had such poor wireless performance. I've always had acceptable wireless performance on all other Puppies upto now.
Is there anything to boost the performance close to that achieved by running this laptop on Win8?
For the record, the internal card is a Atheros AR9285 using the ath9k driver.
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Wed 05 Jun 2013, 03:32 Post subject:
Zombie whiteout files Subject description: possible save session bug IDed |
|
Starting at line 739 of system-init:
Code: | fname="${pp%.wh.*}${pp#*.wh.}" # without the .wh. part
if [ -e "$fname" ]; then # if the file exist, then ...
rm -rf "$fname" > /dev/null # delete the file
rm -rf "$pp" > /dev/null # also delete the whiteout
fi
done |
Files deleted are not being written to save file, but the white-out hidden file is. However if file is not found; the white-out hidden file remains behind. If the same named file is recreated, would it not be re-deleted (with the white out now finally be removed). This is exactly the type of behavior I'm experiencing, double saves makes changes stick.
|
Back to top
|
|
 |
Sage
Joined: 04 Oct 2005 Posts: 5442 Location: GB
|
Posted: Wed 05 Jun 2013, 10:34 Post subject:
|
|
Quote: | don't think I ever had such poor wireless performance |
Sounds like a confusion between SW, FW & HW. Try opening up the router and inspecting for bad caps? Try a different filter? Other than that, re-site your router according to the (de)structions that came with it. Place the device as close as possible to the master socket and run cables from there for your wired connections. It's permissible to re-site the master socket, eg into the loft, before running some cabling downstairs. Knock down a few structural walls to improve the wireless signal?!
|
Back to top
|
|
 |
jamesbond
Joined: 26 Feb 2007 Posts: 3219 Location: The Blue Marble
|
Posted: Thu 06 Jun 2013, 05:18 Post subject:
Re: Zombie whiteout files Subject description: possible save session bug IDed |
|
Ted Dog wrote: | Starting at line 739 of system-init:
Code: | fname="${pp%.wh.*}${pp#*.wh.}" # without the .wh. part
if [ -e "$fname" ]; then # if the file exist, then ...
rm -rf "$fname" > /dev/null # delete the file
rm -rf "$pp" > /dev/null # also delete the whiteout
fi
done |
Files deleted are not being written to save file, but the white-out hidden file is. However if file is not found; the white-out hidden file remains behind. If the same named file is recreated, would it not be re-deleted (with the white out now finally be removed). This is exactly the type of behavior I'm experiencing, double saves makes changes stick. |
Thanks Ted Dog, I think you have a point. This would only happen in one particular scenario - when you delete an file that exist in lower SFS layers and later re-create it (e.g. replacing /bin/bash with an updated version). I guess the solution is to check whether the file is newer than the whiteout, if it is then delete the whiteout, otherwise delete both of them.
EDIT: Replace those lines with this:
Code: | if [ -e "$fname" ]; then # if both file and whiteout exist, then ...
if [ "$pp" -nt "$fname" ]; then # delete the older one
rm -rf "$fname" > /dev/null # delete the file if older
else
rm -rf "$pp" > /dev/null # otherwise delete the whiteout
fi
fi
|
Also change line 1041 and 1042 Code: | [ "$MULTI_MOUNT" ] && BRANCHES=$MULTI_MOUNT:$BRANCHES
[ "$SAVEFILE_MOUNT" ] && BRANCHES=$SAVEFILE_MOUNT:$BRANCHES |
with this Code: | [ "$MULTI_MOUNT" ] && BRANCHES=$MULTI_MOUNT=ro+wh:$BRANCHES
[ "$SAVEFILE_MOUNT" ] &&
if [ "$TMPFS_MOUNT" ]; then BRANCHES=$SAVEFILE_MOUNT=ro+wh:$BRANCHES
else BRANCHES=$SAVEFILE_MOUNT:$BRANCHES
fi
|
heywoodj,
"iwconfig" command can be used to adjust the radio power of your wireless, although it doesn't always work.
cheers!
_________________ Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Thu 06 Jun 2013, 14:42 Post subject:
|
|
Thanks for looking into the zombie white-out possibility, your code once located is so easy to follow, so I'm encouraged to try my hand with labelled save session control (allowing user to select which session to skip or group )
However, the remaster process goes really slow due to my CPU's compression/decompression weakness, would there be a way to take the whole files in tmp during remaster, before the sfs compression and gzip them into initrd without sfs file? for a super huge init (actually only 20-25% larger initrd is still gzipped) so that the system would be uncompressed in RAM as an remaster option if machines have massive amounts of RAM, you check the disk usage of the full filesystem and report that before compression, I've still have 7G's free RAM on a fully decompressed FatDog64. Lets make this fat puppy sing....
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Thu 06 Jun 2013, 16:22 Post subject:
Too FAT TOO FURRY-us total raw speed remaster option |
|
Furiously fast program execution, when running from RAM in uncompressed state.
I made this option for myself in order to speed up testing during my early days with puppylinux, so Its do able. Rule of thumb the system should have 9x the RAM size for the size of the gzipped initrd to run nicely ie make large changes, rezip reburn etc. For average user, 4x RAM is needed, no plans to remaster in RAM etc.
For example FatDog64 would be around 285M, so a machine with 2.8G's or more of RAM would be supported nicely and be usable with some headroom restrictions down to around 1.2Gs of RAM.
WARNING: the speed improvement is so drastic you can never be happy going back... Like driving a very fast car, true sports car, you will never be fully satisfied with anything less.....It's additive.
|
Back to top
|
|
 |
jamesbond
Joined: 26 Feb 2007 Posts: 3219 Location: The Blue Marble
|
Posted: Fri 07 Jun 2013, 04:19 Post subject:
|
|
That is a fun idea, I can't resist
Here's one way you can do it.
1. Open terminal (call this as terminal #1), launch sandbox.sh, choose the layers you want to include in the "remaster". You will need to include all the bottom 3 layers (pup_init, pup_ro and kernel-modules).
2. Open another terminal (call this as terminal #2)
3. Run the following script inside terminal #2 - important, in terminal #2, NOT in the sandbox itself.
4. You will get initrd.gz in /tmp
5. I assume you know what to do with that initrd.gz
6. Close terminal #1 and #2.
The resulting initrd booted on my 2GB virtualbox instance, so it's not too bad
Expect some scripts to fail because when run this way, you're actually running without basesfs (all the files are in initrd).
Code: | #!/bin/sh
# undo sandbox modifications
cd /mnt/fakeroot
cp /etc/profile etc/profile
cp /etc/shinit etc/shinit
cp /usr/bin/xwin usr/X11R7/bin/xwin
cp /usr/bin/wmexit usr/X11R7/bin/wmexit
cp /usr/bin/X usr/X11R7/bin/X
rm etc/BOOTSTATE
# prepare for bootup
ln -s sbin/system-init init
ln -s usr/share/blank.sfs kernel-modules.sfs
sed 's/ mount / busybox mount /; s/^mount /busybox mount /; s_cp -a /bin _cp -a /bin /lib64 /libexec /archive _' init > sbin/system-init.new
mv sbin/system-init.new sbin/system-init
chmod +x sbin/system-init
# generate new giant initrd
find | grep -Ev '^./usr/lib/|^./usr/X11R7/lib/|^./dev/|^./tmp/|^./proc/|^./sys/|^./aufs/' | cpio -o -H newc | gzip > /tmp/initrd.gz
|
EDIT: code should cd to /mnt/fakeroot, not /mnt/sandbox.
_________________ Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
|
Back to top
|
|
 |
jamesbond
Joined: 26 Feb 2007 Posts: 3219 Location: The Blue Marble
|
Posted: Fri 07 Jun 2013, 09:15 Post subject:
|
|
Here is another idea how you can do it.
Instead of making squashfs of the root filesystem, you could create an ext2 image file large enough to hold the stuff (about 700MB at the moment), and put the content of squashfs there, uncompressed. Name the image file as "fd64-620.sfs" and put it in initrd, and then "cpio -o -H newc | gzip" as usual to produce the initrd stuff.
This is "more compatible" than the above because it still runs with basesfs, but the basesfs is uncompressed. The entire initrd is still compressed but it will be decompressed only once during boot-up. In my brief test this seems to have a better boot speed.
Note: just because the extension is "SFS", it doesn't mean it has to be squashfs file
Instruction:
1. Open terminal (call this as terminal #1), launch sandbox.sh, choose the layers you want to include in the "remaster". Only include pup_ro layers onwards, *DO NOT* include the bottom 2 layers (pup_init and kernel-modules).
2. Open another terminal (call this as terminal #2)
3. Type the commands in the following script one-by-one inside terminal #2 - important, in terminal #2, NOT in the sandbox itself.
4. Replace /path/to/original/initrd with - well, the path your original initrd. Its contents will be changed so make sure you have a handy backup copy, and it must be on a writable medium.
5. Replace /tmp/initrd-XXXXX with the random path generated by filemnt.
6. At the end of the script, the your /path/to/original/initrd would have been updated, which then you can use for making iso etc.
7. Close terminal #1 and #2.
Code: | #/bin/sh
# undo sandbox modifications
cp /etc/profile etc/profile
cp /etc/shinit etc/shinit
cp /usr/bin/xwin usr/X11R7/bin/xwin
cp /usr/bin/wmexit usr/X11R7/bin/wmexit
cp /usr/bin/X usr/X11R7/bin/X
rm etc/BOOTSTATE
# make the imagefile
head -c 700M /dev/zero > /tmp/fd64-620.sfs
mke2fs /tmp/fd64-620.sfs
# mount the image file
mount -o loop /tmp/fd64-620.sfs /mnt/data
# copy the files
find | grep -Ev '^./usr/lib/|^./usr/X11R7/lib/|^./dev/|^./tmp/|^./proc/|^./sys/|^./aufs/' | cpio -p /mnt/data
# umount the imagefile
umount -d /mnt/data
# open the original initrd
filemnt /path/to/original/initrd
# replace the fd64-200.sfs with
cp /tmp/fd64-620.sfs /tmp/initrd-XXXXX # where XXXX is the location in which filemnt has opened the initrd
# re-pack initrd
/tmp/initrd-XXXXX/repack-initrd # you will end up with 700+ MB of initrd, in the original /path/to/original/initrd location
# gzip the initrd
gzip /path/to/original/initrd
|
EDIT: Typed the script but forgot to include the instruction, doh!
_________________ Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
|
Back to top
|
|
 |
gcmartin
Joined: 14 Oct 2005 Posts: 6730 Location: Earth
|
Posted: Fri 07 Jun 2013, 13:57 Post subject:
|
|
This is a great idea for a "local" adaptation of FD. It offers the creation of an ISO by the local user which will run a system minus the overhead of compression, once booted.
Excellent insight from @TedDog and implementation examples from @JamesBond.
I wonder if this could be a future addition to the general system or an option to the Remaster tool.
I do understand the RAM impact, but, the performance offers a positive impact and user experience. Would this qualify as a "Real-Time" category?
Thanks.
_________________ Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Fri 07 Jun 2013, 15:32 Post subject:
|
|
Should also be possible without having to rebuild it uncompressed, if the entire contents of regular SFS would be copied into RAM (decompressing) at the time prior to switch-root, and then the SFS could be deleted, or if in my case just remain behind to aid in compatibility I've got the RAM room to spare. RAM would need to be 10X the size of compressed SFS to function without issue.
When I did my methods years ago I used 10X size is a warning layer since I found scripting x10 math easier than x9 I slapped a character for the letter zero to the end of the string and use that to compare.
I had a single script closer to the last one above that then created an on the fly iso and burned it to the DVD+RW, then called the reboot command. It was nice, hit the icon on the desktop, leave to eat or due something else for a few minutes. If my desktop was in view then that test was successful.
A single bootcode could be added to do this.
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Fri 07 Jun 2013, 16:32 Post subject:
|
|
Actually you should make running slow as a boot flag not FAST.
I always have to add a waitdev of 2 to 4 seconds for my machine to function correctly.
Those 2 to 4 seconds would be all we need to decompress the sfs if it already loaded in RAM.
Check for 10x RAM and decompress unless they told us not too.
Its the repetitively decompressing the same files when accessed individually that slows the system.
Also this reminds me of something I read online ( can't recall source ) that redhat uses sfs as a package container for a single file which is a filesystem like ext2 that is used by the system like a block device, so that different layer of reading code is used by kernel drivers and a performance is increased since the files most likely to be used next are within the block driver RAM buffer.
I did not understand how that actually worked but if you are already so close to reproduce that method why not see if this holds true.
|
Back to top
|
|
 |
jamesbond
Joined: 26 Feb 2007 Posts: 3219 Location: The Blue Marble
|
Posted: Sat 08 Jun 2013, 01:59 Post subject:
|
|
Replace process_base2ram with this one.
Beware that the initial expansion process is a bit slow.
To use, boot with base2ram=expand
Code: | process_base2ram() {
local mntdev size avail
# can only do it when basesfs exist and is not bind-mounted
if [ "$BASE_SFS_MOUNT" -a -z "$BASE_SFS_BIND" ]; then
# setup
case $base2ram in
yes)
echo Copying $BASE_SFS_PATH to RAM ...
mntdev=$(awk -v MNT=$BASE_SFS_MOUNT '$2 == MNT {print $1; exit}' /proc/mounts)
BASE_SFS_PATH=$BASE_SFS_DEFAULT_PATH
dd if=$mntdev of=$BASE_SFS_PATH bs=1M
;;
expand)
size=$(du -sm $BASE_SFS_MOUNT); size=${size%%/*}
size=$(( ( $size * 110 ) / 100 )) # make it 10% larger to account for ext2 overheads
avail=$(df -m $BASELINE_MOUNT | awk 'NR==2 {print $2}')
if [ $avail -gt $size ]; then
echo "Expanding $BASE_SFS_PATH ($size MB) to RAM ..."
BASE_SFS_PATH=${BASE_SFS_DEFAULT_PATH%.sfs}.ext2
dd if=/dev/zero of=$BASE_SFS_PATH bs=1M count=0 seek=$size 1>&2
mke2fs -m 0 -F $BASE_SFS_PATH 1>&2
mkdir /tmp/newbase; mount -o loop $BASE_SFS_PATH /tmp/newbase
cp -a $BASE_SFS_MOUNT/* /tmp/newbase
umount -d /tmp/newbase; rmdir /tmp/newbase
else
echo "base2ram: not expanding, needed $size MB but only $avail MB available."
base2ram=no
fi
;;
esac
# shared yes/expand cleanup
case $base2ram in
yes|expand)
BASE_SFS_DEVICE=
umount -d $BASE_SFS_MOUNT
if [ -e $BASE_SFS_DEV_MOUNT ]; then
umount -d $BASE_SFS_DEV_MOUNT
rmdir $BASE_SFS_DEV_MOUNT
fi
# use RAM copy instead
! mount_loop $BASE_SFS_PATH $BASE_SFS_MOUNT -o ro && BASE_SFS_MOUNT=
;;
esac
fi
}
|
_________________ Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
|
Back to top
|
|
 |
heywoodj
Joined: 15 Mar 2009 Posts: 83
|
Posted: Sat 08 Jun 2013, 11:12 Post subject:
|
|
Sage wrote: | Quote: | don't think I ever had such poor wireless performance |
Sounds like a confusion between SW, FW & HW... |
You're probably right, but the thing that gets me is that the same machine at the same location does wireless fine in @#!&&^* Win8. So, yeah SW, HW & FW are not playing nice together with the Atheros card in FD620.
Since this seems to be one of the only versions to have UEFI support, it's what I've been using.
Quote: | Knock down a few structural walls to improve the wireless signal?! |
I'm getting the sledge hammer now!
jamesbond wrote: | "iwconfig" command can be used to adjust the radio power of your wireless, although it doesn't always work. |
Do you mean boosting the transmission power from the router? Seems on my older reflashed Linksys router with dd-wrt, there were adjustable power settings, but don't know about the other routers, most which are not mine!
I found iwconfig has a txpower parameter but about all I can do is turn it on and off, not adjust the power. If I were to try to set txpower, I get:
Code: | # iwconfig wlan0 txpower 30
Error for wireless request "Set Tx Power" (8B26) :
SET failed on device wlan0 ; Invalid argument.
|
Is my syntax right?
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Sat 08 Jun 2013, 11:26 Post subject:
|
|
Great, a turbo boost option from the start, without a remaster for the next version of FatDog. I think this will become popular since most 64bit computers come with enough RAM.
I, of course, will try this first, then stair-step the fast remaster option to solve my original issue. Thanks for all the scripts and how-to knowledge...
|
Back to top
|
|
 |
Ted Dog

Joined: 13 Sep 2005 Posts: 4013 Location: Heart of Texas
|
Posted: Sat 08 Jun 2013, 15:06 Post subject:
|
|
Boot option base2ram=expand works nice, it does not work in a huge init without editing the code that resets base2ram=no. since its already loaded
But so far, loading apps with lots of files SeaMonkey, Gimp etc. its very noticeable in a good way. System over all seems a bit less clogged.
|
Back to top
|
|
 |
|
Page 17 of 29 [432 Posts] |
Goto page: Previous 1, 2, 3, ..., 15, 16, 17, 18, 19, ..., 27, 28, 29 Next |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|