Posts: 8
mrneilypops
Joined: 08 Jul 2011
#1
I was pleasantly surprised with the implementation of toram on antiX.
A really neat info box asking if you would like to remove the media after booting to RAM...followed by another asking if you would like to close the cd tray.

Very cool __{{emoticon}}__

Congratulations on another fine release.
Posts: 1,444
skidoo
Joined: 09 Feb 2012
#2
Searching today for threads having toram in the title
turned up only this thread I'm posting to, plus one other: viewtopic.php?f=3&t=47

When I recently tested toram in antix 14R alpha, the"A really neat info box asking if you would like to remove the media after booting to RAM" was absent.
During boot, while data is being read from the pendrive to populate the ramfs, the reported read speed is ~18Mb/sec (matches my earlier results testing the speed of the drive).
system specs: 2.8GHz Pentium D; 3Gb of 800Mhz RAM (interleaved access? the system bus is only 667MHz)

Not just with antix, when I've tested toram (from a live session) with any distro... I've never noticed any significant speed benefit.
First run, MAYBE iceweasel will launch in 7 seconds (vs 8 without toram) ...and during subsequent launches, MAYBE launch takes 3secs (vs 4secs).
With synaptic and most other preinstalled apps, I've found zero noticeable difference in timings.
Posts: 850
fatmac
Joined: 26 Jul 2012
#3
The 'to ram' option was originally intended for people who wanted to re use their cd drive when booting from a livecd.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#4
skidoo wrote:I've never noticed any significant speed benefit. First run, MAYBE iceweasel will launch in 7 seconds (vs 8 without toram) ...and during subsequent launches, MAYBE launch takes 3secs (vs 4secs). With synaptic and most other preinstalled apps, I've found zero noticeable difference in timings.
You've got 3GB RAM. Anything loaded in from disc will be cached so unless you are using gobs of memory, I wouldn't expect any speedup from toram after the first launch.

A LiveUSB can be much much faster than a LiveCD. For example, a LiveUSB does not have the glacially slow seek times that most cdroms have, on the order of 1/10th of a second (ten times slower than a hard drive, which is usually much slower than a usb stick). On LiveCDs toram can make a huge difference speed-wise and since very little seeking is involved in reading the entire linuxfs file into RAM, it can be a big win overall. It is also useful for freeing up the cdrom drive or the usb port used by the Live media. Sure, there are some circumstances where there is not much benefit from the toram option. That's why it is an option. We have no plans to remove this option just because it is not useful in all circumstances.

LiveUSBs are vastly superior to LiveCDs on many fronts: speed, access time, and write access. That's why the antiX devs have invested a lot of work on LiveUSB-only features. If someone is using an antiX LiveCD on a system without usb ports, they might complain that all of those LiveUSB features are useless. But if they have enough RAM to use the toram option then for them it is the bees knees.
Posts: 1,444
skidoo
Joined: 09 Feb 2012
#5
FWIW, I wasn't suggesting elimination / removal of the toram option

Thanks for providing a succinct & insightful explanation.
Obviously (in hindsight) I had forgotten that toram was intended for use when booting from CD.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#6
It was the subject line"toram implementation" that got my attention. When I saw that I thought maybe I had done something wrong or maybe the implementation needed to be improved.
Posts: 1,444
skidoo
Joined: 09 Feb 2012
#7
When I revisited the prospect of employing toram recently, it was with a (safety, as in, tinfoil hat) interest toward
ejecting the pendrive ~~ until/unless I elected to perform a persist-save operation.

Although I had considered submitting a feature request
"if toram, regardless CD or USB, prompt and offer user an opportunity to eject the boot device"
I realized that being forced to step through that prompt each session would likely be an annoyance.

Maybe I'll roll up my sleeves and attempt to create a custom cheatcode (loadngo? ejtoram?) which, if present in the boot line,
invokes toram AND triggers a conditional prompt during init.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#8
skidoo wrote:if toram, regardless CD or USB, prompt and offer user an opportunity to eject the boot device
Let's see if I understand what you want. With toram + LiveUSB, do you want a window to pop up that says:
It is now safe to remove the LiveUSB
I don't know how to eject a LiveUSB. I can just tell the user it is safe to remove it.
Posts: 1,444
skidoo
Joined: 09 Feb 2012
#9
Because the user might be booting to runlevel 3, I hadn't considered a"popup window".
Just a conditional prompt-and-wait-for-kepress, performed during init and worded generically to cover both cases (CD-ROM, USB)

Code: Select all

printf"\n (loadngo bootcode detected)\n System has been loaded to ramfs.\n You may remove the boot media now, if you wish.\n\n[continue]"
read -p""
Yes, 'eject' would be confusing verbiage. Similarly, 'safe' is already implied; user needn't wonder 'how do i do it safely?'

How to 'eject' USB? I dunno.
I chose that term based on the observation that noeject boot code affects whether or not the
"remove... then press ENTER" prompt displays during shutdown of liveUSB session.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#10
We already have a pop-up window for ejecting the LiveCD when toram is used. It is a little bit more complicated than just a simple message. I think it works well and is very user friendly. YMMV.

I don't like the idea of delaying the boot just for this. I'm sure there will be complaints about the system not booting, especially after screen-blanking kicks in. I see this as a case of a lot of work with very little benefit. Adding a message about it being safe to remove the LiveUSB to the existing pop-up window program might not be difficult.

I'm not claiming what we do now is perfect but I think it is a reasonable compromise. GUI users are treated in the manner they are accustomed to while runlevel-3 folks don't get all the amenities. For most users, doing this during init would be a huge step backward. Even if we integrated the init script haltage with the existing GUI app, I personally would be extremely annoyed by the unnecessary delay. Your suggestion targets a small subset of users and I think it would annoy a majority in that subset.