The 05/09/12, Dale wrote:
Michael Mol wrote:
On Wed, Sep 5, 2012 at 11:17 AM, Neil Bothwick n...@digimed.co.uk wrote:
On Wed, 05 Sep 2012 07:52:45 -0500, Dale wrote:
I might also add, I see no speed improvements in putting portages
work directory on tmpfs. I have tested this a few
Neil Bothwick wrote:
On Wed, 05 Sep 2012 12:54:51 -0500, Dale wrote:
I might also add, I see no speed improvements in putting portages
work directory on tmpfs. I have tested this a few times and the
difference in compile times is just not there.
Probably because with 16GB everything stays
Nicolas Sebrecht wrote:
The 05/09/12, Dale wrote:
Michael Mol wrote:
On Wed, Sep 5, 2012 at 11:17 AM, Neil Bothwick n...@digimed.co.uk wrote:
On Wed, 05 Sep 2012 07:52:45 -0500, Dale wrote:
I might also add, I see no speed improvements in putting portages
work directory on tmpfs. I have
On Thu, 06 Sep 2012 04:15:23 -0500, Dale wrote:
You missed the point. One of the first thing emerge will do is to
uncompress the package. At this time, all the files are cached in RAM.
Hence, everything needed for the build/compilation will come from the
cache like it would do with tmpfs.
Neil Bothwick wrote:
On Thu, 06 Sep 2012 04:15:23 -0500, Dale wrote:
You missed the point. One of the first thing emerge will do is to
uncompress the package. At this time, all the files are cached in RAM.
Hence, everything needed for the build/compilation will come from the
cache like it
Neil Bothwick wrote:
On Thu, 06 Sep 2012 04:15:23 -0500, Dale wrote:
You missed the point. One of the first thing emerge will do is to
uncompress the package. At this time, all the files are cached in RAM.
Hence, everything needed for the build/compilation will come from the
cache like it
On Thu, 06 Sep 2012 05:03:55 -0500, Dale wrote:
You miss this point not me. I *cleared* that cache. From
kernel.org:
Sorry Dale, but you are missing the point. You cleared the cache
before running emerge, then ran emerge. The first thing emerge did
was unpack the tarball and
On Thu, 06 Sep 2012 05:11:01 -0500, Dale wrote:
You need to run free, run the command to clear and then run free again
so you can see for yourself. If it was just me, I could think I am
wrong but this was tested by others too with the same results.
I'm not saying your test results are wrong,
The 06/09/12, Dale wrote:
Then explain to me why it was at times slower while on tmpfs? Trust me,
I ran this test many times and in different orders and it did NOT make
much if any difference.
As explained, this is expected if you have enough RAM.
I didn't check but I would expect that
Neil Bothwick wrote:
On Thu, 06 Sep 2012 05:11:01 -0500, Dale wrote:
You need to run free, run the command to clear and then run free again
so you can see for yourself. If it was just me, I could think I am
wrong but this was tested by others too with the same results.
I'm not saying your
Neil Bothwick wrote:
On Thu, 06 Sep 2012 05:03:55 -0500, Dale wrote:
You miss this point not me. I *cleared* that cache. From
kernel.org:
Sorry Dale, but you are missing the point. You cleared the cache
before running emerge, then ran emerge. The first thing emerge did
was unpack the
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
Then explain to me why it was at times slower while on tmpfs? Trust me,
I ran this test many times and in different orders and it did NOT make
much if any difference.
As explained, this is expected if you have enough RAM.
I didn't check
The 06/09/12, Dale wrote:
The point was
whether having portages work directory on tmpfs resulted in speed
increases. If you have portages work directory on tmpfs, of course it
uses ram. That's what tmpfs is. It's taking what might
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
The point was
whether having portages work directory on tmpfs resulted in speed
increases. If you have portages work directory on tmpfs, of course it
uses ram. That's what tmpfs is.
The 06/09/12, Dale wrote:
The point you are missing is this. Between those tests, I CLEARED that
cache. The thing you and Neil claim that makes a difference does not
exist after you clear the cache. I CLEARED that cache between EACH and
every test that was ran whether using tmpfs or not.
Hello,
I've installed Gentoo into VirtualBox. I want it to has static IP address and
I've followed Hand book instructions and the OpenRC/net.example. After reboot
there's a warning: WARNING: net.lo has already been started and each network
depending service failes to start with: service_name:
2012/9/6 pat p...@xvalheru.org
Hello,
I've installed Gentoo into VirtualBox. I want it to has static IP address
and
I've followed Hand book instructions and the OpenRC/net.example. After
reboot
there's a warning: WARNING: net.lo has already been started and each
network
depending service
On Thu, 06 Sep 2012 06:31:24 -0500, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster. If
you have portages work directory on disk, it will be slower because the
disk is slower.
But the disk
On Thu, 6 Sep 2012 14:10:21 +0200, Michael Hampicke wrote
2012/9/6 pat p...@xvalheru.org
Hello,
I#39;ve installed Gentoo into VirtualBox. I want it to has static IP address
and
I#39;ve followed Hand book instructions and the OpenRC/net.example. After
reboot
there#39;s a warning: WARNING:
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
The point you are missing is this. Between those tests, I CLEARED that
cache. The thing you and Neil claim that makes a difference does not
exist after you clear the cache. I CLEARED that cache between EACH and
every test that was ran
The 06/09/12, Neil Bothwick wrote:
The only real benefit of using tmpfs is the one you mentioned elsewhere,
that the disks don't get bothered at all.
Benefits also depends of what the system does during the emerge. If
another process is intensively using the kernel cache and the kernel
cache
Neil Bothwick wrote:
On Thu, 06 Sep 2012 06:31:24 -0500, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster. If
you have portages work directory on disk, it will be slower because the
disk is
On Thu, 6 Sep 2012 13:21:43 +0100, pat wrote:
Yes, I did. When the Gentoo boots to shell there#39;s only loop back
interface.
Please post contents of /etc/conf.d/net
--
Neil Bothwick
Top Oxymorons Number 5: Twelve-ounce pound cake
signature.asc
Description: PGP signature
On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote:
I don't think that is correct. I am clearing the files in ram. That's
the point of drop_caches is to clear the kernels cache files. See post
to Nicolas Sebrecht a bit ago.
Take a step back Dale and read the posts again. This is not about the
On Thu, 6 Sep 2012 14:00:22 +0100, Neil Bothwick wrote
On Thu, 6 Sep 2012 13:21:43 +0100, pat wrote:
Yes, I did. When the Gentoo boots to shell there's only loop back
interface.
Please post contents of /etc/conf.d/net
--
Neil Bothwick
Top Oxymorons Number 5: Twelve-ounce pound
The 06/09/12, Dale wrote:
I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not
large enough here to matter. So, it is left with #5.
See the point? The test was a NORMAL emerge with portages work
directory on tmpfs and a NORMAL emerge with portages work directory on
The 06/09/12, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster.
No! This is too much simplistic view to explain what you see.
In practice, _all_ the writes always happen in RAM whatever backend
Neil Bothwick wrote:
On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote:
I don't think that is correct. I am clearing the files in ram. That's
the point of drop_caches is to clear the kernels cache files. See post
to Nicolas Sebrecht a bit ago.
Take a step back Dale and read the posts again.
Try `emerge -pvT $foo`. With whatever package $foo you are trying to
install.
That is already solved (I had selected it somehow) by simply deselecting it.
But is now a little OT. I now try to compile x11-libs/libxcb, and
dev-python/elementtree is not installed on my system.
Regards,
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster.
No! This is too much simplistic view to explain what you see.
In practice, _all_ the writes always
Yes, I did. When the Gentoo boots to shell there's only loop back
interface.
Are you sure that the kernel module for your network interface is loaded?
What's the output of ifconfig -a after a reboot?
On Thu, Sep 6, 2012 at 10:07 AM, Dale rdalek1...@gmail.com wrote:
Neil Bothwick wrote:
On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote:
I don't think that is correct. I am clearing the files in ram. That's
the point of drop_caches is to clear the kernels cache files. See post
to Nicolas
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not
large enough here to matter. So, it is left with #5.
See the point? The test was a NORMAL emerge with portages work
directory on tmpfs and a NORMAL emerge with
On Thu, Sep 6, 2012 at 10:20 AM, Dale rdalek1...@gmail.com wrote:
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster.
No! This is too much simplistic view
On Thu, 06 Sep 2012 09:07:30 -0500, Dale wrote:
I don't care if emerge uses cache
DURING the emerge process because it is always enabled in both tests.
The point is whether portage's work directory is on tmpfs or not makes
emerges faster.
It does not, if you have enough RAM, precisely
The 06/09/12, Dale wrote:
Then take a look at it this way. If I emerge seamonkey with portage's
work directory on disk and it takes 12 minutes, the first time. Then I
clear the caches and emerge seamonkey again while portage's work
directory is on tmpfs and it is 12 minutes. Then repeat
On Wed, Sep 5, 2012 at 5:42 PM, Roland Häder r.hae...@web.de wrote:
Hi all,
I finally got libxml2 compiled, first I had to do this:
# emerge expat
# emerge python
# cd /usr/portage/dev-lang/python/
# emerge python-2.7.3-r2.ebuild
# cd -
This makes sure that libexpat is there. Now the
Weird, I'm on 2.8.0-r1 and didn't have to do any hoop jumping to get
there (~amd64).
Yes, it is really weird thing. :/ I use x86 (i686, my laptop does only support
32 bit; it is a Thinkpad R51).
Regards,
Roland
That is already solved (I had selected it somehow) by simply deselecting it.
But is now a little OT. I now try to compile x11-libs/libxcb, and
dev-python/elementtree is not installed on my system.
There is hope for this matter, see my forum posting:
On Thu, Sep 6, 2012 at 4:33 AM, pat p...@xvalheru.org wrote:
Hello,
I've installed Gentoo into VirtualBox. I want it to has static IP address and
I've followed Hand book instructions and the OpenRC/net.example. After reboot
there's a warning: WARNING: net.lo has already been started and each
On Thu, Sep 6, 2012 at 9:20 AM, Dale rdalek1...@gmail.com wrote:
OK. Step by step here so hopefully you and Neil can follow.
Freshly booted system.
Clear caches just to be sure
emerge foo with portages work directory on tmpfs
clear caches again
emerge foo with portages work directory on
On Thu, 6 Sep 2012 16:23:57 +0200, Michael Hampicke wrote
Yes, I did. When the Gentoo boots to shell there's only loop back interface.
Are you sure that the kernel module for your network interface is loaded?
What's the output of ifconfig -a after a reboot?
ifconfig -a gives:
On Thu, 6 Sep 2012 08:37:33 -0700, Mark Knecht wrote
On Thu, Sep 6, 2012 at 4:33 AM, pat p...@xvalheru.org wrote:
Hello,
I've installed Gentoo into VirtualBox. I want it to has static IP address
and
I've followed Hand book instructions and the OpenRC/net.example. After
reboot
Michael Mol wrote:
On Thu, Sep 6, 2012 at 10:07 AM, Dale rdalek1...@gmail.com wrote:
Neil Bothwick wrote:
On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote:
I don't think that is correct. I am clearing the files in ram. That's
the point of drop_caches is to clear the kernels cache files. See
Neil Bothwick wrote:
On Thu, 06 Sep 2012 09:07:30 -0500, Dale wrote:
I don't care if emerge uses cache
DURING the emerge process because it is always enabled in both tests.
The point is whether portage's work directory is on tmpfs or not makes
emerges faster.
It does not, if you have
Michael Mol wrote:
On Thu, Sep 6, 2012 at 10:20 AM, Dale rdalek1...@gmail.com wrote:
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
Not quite. The theory is that if you put portages work directory on
tmpfs, then all the writes and such are done in ram which is faster.
No! This is too
Paul Hartman wrote:
On Thu, Sep 6, 2012 at 9:20 AM, Dale rdalek1...@gmail.com wrote:
OK. Step by step here so hopefully you and Neil can follow.
Freshly booted system.
Clear caches just to be sure
emerge foo with portages work directory on tmpfs
clear caches again
emerge foo with
Nicolas Sebrecht wrote:
The 06/09/12, Dale wrote:
Then take a look at it this way. If I emerge seamonkey with portage's
work directory on disk and it takes 12 minutes, the first time. Then I
clear the caches and emerge seamonkey again while portage's work
directory is on tmpfs and it is 12
On Thu, 06 Sep 2012 11:44:07 -0500, Dale wrote:
I kind of get what they are saying but at the same time using tmpfs
doesn't matter. Once the tarball is read off the drive, it doesn't
matter whether portage is run on a tmpfs or not.
Reading the tarball has nothing to do with this, we are
On Thu, 06 Sep 2012 11:32:41 -0500, Dale wrote:
Others ran their own tests and got the same results.
No one is denying the results, only the reasons given for them.
--
Neil Bothwick
If you can't be kind, be vague.
signature.asc
Description: PGP signature
Neil Bothwick wrote:
On Thu, 06 Sep 2012 11:44:07 -0500, Dale wrote:
I kind of get what they are saying but at the same time using tmpfs
doesn't matter. Once the tarball is read off the drive, it doesn't
matter whether portage is run on a tmpfs or not.
Reading the tarball has nothing to do
On Thu, 06 Sep 2012 16:09:12 -0500, Dale wrote:
Reading the tarball has nothing to do with this, we are discussing
filesystems for PORTAGE_TMPDIR, not DISTDIR. It's where the source is
unpacked, the object files compiled to, the executables linked to and
the install image created that is
Neil Bothwick wrote:
On Thu, 06 Sep 2012 16:09:12 -0500, Dale wrote:
Reading the tarball has nothing to do with this, we are discussing
filesystems for PORTAGE_TMPDIR, not DISTDIR. It's where the source is
unpacked, the object files compiled to, the executables linked to and
the install
On Thu, Sep 06, 2012 at 02:13:04PM +0100, pat wrote
On Thu, 6 Sep 2012 14:00:22 +0100, Neil Bothwick wrote
Please post contents of /etc/conf.d/net
--
Neil Bothwick
Top Oxymorons Number 5: Twelve-ounce pound cake
Here it is.
config_eth0=192.168.74.101 netmask 255.255.255.0
54 matches
Mail list logo
