I've been a bit amazed over the years, of the intense "updates" that usually are run in the cron, during the night times. Several times, I've been playing games, or just browsing the net on my desktop, during early morning hours, when my computer has gone to sleep when running the cron update. Usually this is a period, of a whole hour, and sometimes more. I've often mentioned it, and despite that this function is reduntant function from the old batch time hours of Unix, nobody has bothered removing it from the desktop linux environment. However, now when I write this, my machine is doing this horrible update of all manuals, which nobody reads anymore. And rebuilding the structure of the entire files system (exageration, running several recursive finds), for what purpose only geniuses can figure. But I've finally been able to work on my machine while it was doing this. On all other occasions, even with a AMD64 3000+, my machine went to sleep ... and I could hardly browse the desktop during this hour of nonsense. But now, yes now I CAN ... but it took a desktop with a dual core CPU to do it. Go figure :-) AMEN!
Orn E. Hansen wrote:
Usually this is a period, of a whole hour, and sometimes more. I've often mentioned it, and despite that this function is reduntant function from the old batch time hours of Unix, nobody has bothered removing it from the desktop linux environment.
If it is truly redundant, which other function is doing the same thing? If you think the function is superfluous, just remove it. But, as we are talking about SUSE Linux, I don't believe there is a tickbox during installation that clearly says "For server use" or "For desktop use" - so SUSE should try to cover most requirements.
However, now when I write this, my machine is doing this horrible update of all manuals, which nobody reads anymore.
Personally, I read some or other man-page at least once every day.
But I've finally been able to work on my machine while it was doing this. On all other occasions, even with a AMD64 3000+, my machine went to sleep ... and I could hardly browse the desktop during this hour of nonsense. But now, yes now I CAN ... but it took a desktop with a dual core CPU to do it. Go figure :-)
There isn't much to figure. Some of those daily runs are obviously quite resource-intensive, so scheduling them for night-time is an attempt to avoid inconveniencing the user. If they always kick in when you're working, why not just reschedule them for a different time? To the advantages of dual-core - provided your workload is concurrent, a dual-core CPU will allow you to get _almost_ twice as much work done. But with less power, less heat and in less space. And less overall cost. /Per Jessen, Zürich
Laugardaginn 27 maí 2006 11:58 skrifaði Per Jessen:
If it is truly redundant, which other function is doing the same thing? If you think the function is superfluous, just remove it.
I know I can remove it, it's not the point. The point is, whenever I update the system, they're just gonna return.
But, as we are talking about SUSE Linux, I don't believe there is a tickbox during installation that clearly says "For server use" or "For desktop use" - so SUSE should try to cover most requirements.
The latest "ideology" is to have A) Server, known as Enterprise Linux, B) Desktop environment, and C) Development environment. On platform A, yes some of these functions may be non-reduntant. On B, they're useless. People will shutoff their machines when not using them, a few will have them up, to avoid going through long "startup" procedures. Which is another reason for "dump state to disk" shutdown. C) A "maybe". The batch processing is an old reduntant feature, and I feel they should be put into a YaST module, where the packages "suggest" cron jobs, and a user selects which he thinks would benefit him. Of course, that's my opinion on the matter.
There isn't much to figure. Some of those daily runs are obviously quite resource-intensive, so scheduling them for night-time is an attempt to avoid inconveniencing the user. If they always kick in when you're working, why not just reschedule them for a different time?
I may be working all hours of the day. I'm an enthusiast, I don't keep scheduled hours for when I work or when I play. I do it, when I got the time.
To the advantages of dual-core - provided your workload is concurrent, a dual-core CPU will allow you to get _almost_ twice as much work done. But with less power, less heat and in less space. And less overall cost.
I've definately noticed... and amen to that. // Orn
On Saturday 27 May 2006 22:39, Orn E. Hansen wrote:
Laugardaginn 27 maí 2006 11:58 skrifaði Per Jessen:
If it is truly redundant, which other function is doing the same thing? If you think the function is superfluous, just remove it.
I know I can remove it, it's not the point. The point is, whenever I update the system, they're just gonna return.
No, findutils-locate is something you installed manually and explicitly. It is not installed by default. It was before, it isn't now.
But, as we are talking about SUSE Linux, I don't believe there is a tickbox during installation that clearly says "For server use" or "For desktop use" - so SUSE should try to cover most requirements.
The latest "ideology" is to have A) Server, known as Enterprise Linux, B) Desktop environment, and C) Development environment.
On platform A, yes some of these functions may be non-reduntant. On B, they're useless. People will shutoff their machines when not using them, a few will have them up, to avoid going through long "startup" procedures. Which is another reason for "dump state to disk" shutdown. C) A "maybe".
The batch processing is an old reduntant feature, and I feel they should be put into a YaST module, where the packages "suggest" cron jobs, and a user selects which he thinks would benefit him. Of course, that's my opinion on the matter.
You seem to have trouble with the definitions of the words "useless" and "redundant". "useless" means literally "without use". It doesn't mean "Orn E Hansen has no use for it". cron is a fully justified feature on any system. And yes, there is even scheduled processing in windows "redundant" means "more than one thing in place for the same feature". For example RAID is redundant storage, as it stores the same thing on more than one disk (at least RAID 1 does) Batch processing is a term derived from the old punch cards, when the operator would put in a whole "batch" of them for processing, instead of putting in one job at a time. This sense doesn't exist today, since any computer will work on multiple "jobs" at any one time. cron is not batch processing. cron is scheduled processing. It has a use on any type of system, server or desktop or whatever.
On Saturday 27 May 2006 16:57, Anders Johansson wrote:
I know I can remove it, it's not the point. The point is, whenever I update the system, they're just gonna return.
No, findutils-locate is something you installed manually and explicitly. It is not installed by default. It was before, it isn't now.
He must have checked off the "experienced user" box. I think that's where it comes in.
On Saturday 27 May 2006 23:15, Bruce Marshall wrote:
On Saturday 27 May 2006 16:57, Anders Johansson wrote:
I know I can remove it, it's not the point. The point is, whenever I update the system, they're just gonna return.
No, findutils-locate is something you installed manually and explicitly. It is not installed by default. It was before, it isn't now.
He must have checked off the "experienced user" box. I think that's where it comes in.
I don't know. The only .sel file that includes findutils-locate is Hacker.sel, and I don't see that included anywhere in YaST. But I'll do a test install in vmware to see if I can find what might bring it in by accident, if anything
Anders Johansson wrote:
He must have checked off the "experienced user" box. I think that's where it comes in.
I don't know. The only .sel file that includes findutils-locate is Hacker.sel, and I don't see that included anywhere in YaST.
I think "Experienced user" = Hacker.sel. /Per Jessen, Zürich
He must have checked off the "experienced user" box. I think that's where it comes in. As I said earlier, I do want the database filled up ... just different
Laugardaginn 27 maí 2006 23:15 skrifaði Bruce Marshall: priorities. And yes, I did check the experienced user ... miss the uemacs program though.
Anders Johansson wrote:
Batch processing is a term derived from the old punch cards, when the operator would put in a whole "batch" of them for processing, instead of putting in one job at a time. This sense doesn't exist today, since any computer will work on multiple "jobs" at any one time.
As an aside - batch still exists - batch is everything that is not realtime or interactive/on-line. An interactive/on-line transaction is something with a less than 3sec response time. Compiling the Linux kernel is batch. /Per Jessen, Zürich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-05-28 at 14:15 +0200, Per Jessen wrote:
As an aside - batch still exists - batch is everything that is not realtime or interactive/on-line. An interactive/on-line transaction is something with a less than 3sec response time. Compiling the Linux kernel is batch.
IMO, batch is anything running under the 'batch' command, nothing else. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeedZtTMYHG2NR9URAl07AJ9h8q/hCE/ULy82EqcVSI1+7ntXOACeNphp TI5bHL13cqtkUZyNmsmV9AI= =l1pW -----END PGP SIGNATURE-----
On Sunday 28 May 2006 20:09, Carlos E. R. wrote:
The Sunday 2006-05-28 at 14:15 +0200, Per Jessen wrote:
As an aside - batch still exists - batch is everything that is not realtime or interactive/on-line. An interactive/on-line transaction is something with a less than 3sec response time. Compiling the Linux kernel is batch.
IMO, batch is anything running under the 'batch' command, nothing else.
No, /usr/bin/batch represents yet another redefinition of the term, bringing it even further away from what it originally meant. A "batch" of jobs is simply a group of jobs run together, usually with some sort of dependency, so that if job n fails, n+1 doesn't run /usr/bin/batch is just a way of running a low priority job when system resources aren't used for something more important
On Sunday 28 May 2006 14:15, Per Jessen wrote:
As an aside - batch still exists - batch is everything that is not realtime or interactive/on-line. An interactive/on-line transaction is something with a less than 3sec response time. Compiling the Linux kernel is batch.
That's a redefinition of the term, it wasn't what "batch" was meant to mean. I know that modern mainframe programmers refer to "batch jobs" meaning as opposed to "online programs", the linux/unix equivalent would be background jobs, jobs that don't interact with anything until they're done. In the sense that a makefile is similar (very loosely) to an IBM JCL card, then yes, compiling anything is "batch" This doesn't mean cron is batch though. cron is scheduling, not batching
Mánudaginn 29 maí 2006 00:32 skrifaði Anders Johansson:
In the sense that a makefile is similar (very loosely) to an IBM JCL card, then yes, compiling anything is "batch"
Although MS-DOS did introduce the .BAT file format, it is not referred to as a batch job. As its initiated by a human, and not by the computer. A batch job is initiated and run in the background.
On Monday 29 May 2006 07:24, Orn E. Hansen wrote:
Mánudaginn 29 maí 2006 00:32 skrifaði Anders Johansson:
In the sense that a makefile is similar (very loosely) to an IBM JCL card, then yes, compiling anything is "batch"
Although MS-DOS did introduce the .BAT file format, it is not referred to as a batch job. As its initiated by a human, and not by the computer. A batch job is initiated and run in the background.
First, .bat isn't a file format, it is a file name extension. Second, it has nothing whatsoever to do with IBM's Job Control Language, which is used to control and coordinate batch jobs on mainframes
Mánudaginn 29 maí 2006 07:50 skrifaði Anders Johansson:
First, .bat isn't a file format, it is a file name extension. Second, it has nothing whatsoever to do with IBM's Job Control Language, which is used to control and coordinate batch jobs on mainframes
I know you're a smart guy, who wants to tell us old school how we did things. But maybe you should read an encyclopedia for a change. http://en.wikipedia.org/wiki/Batch_file http://en.wikipedia.org/wiki/Batch_processing
Orn E. Hansen wrote:
I know you're a smart guy, who wants to tell us old school how we did things. But maybe you should read an encyclopedia for a change.
That page is in need of some editing - there is nothing implicitly sequential about batch-processing - certainly not on a multi-way machine, but even on a uni-processor, batchjobs maybe executing in parallel, even if not concurrently. /Per Jessen, Zürich
Mánudaginn 29 maí 2006 21:31 skrifaði Per Jessen:
That page is in need of some editing - there is nothing implicitly sequential about batch-processing - certainly not on a multi-way machine, but even on a uni-processor, batchjobs maybe executing in parallel, even if not concurrently.
Batch does imply sequentiality, although there's no strict definition that limits it to it.
Orn E. Hansen wrote:
Mánudaginn 29 maí 2006 21:31 skrifaði Per Jessen:
That page is in need of some editing - there is nothing implicitly sequential about batch-processing - certainly not on a multi-way machine, but even on a uni-processor, batchjobs maybe executing in parallel, even if not concurrently.
Batch does imply sequentiality
Having implemented big batch jobs on IBM mainframes, made up from several thousand job steps, under JCL and under CA7, I can assure you that this is no the case. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Joachim Schrod wrote:
Orn E. Hansen wrote:
Mánudaginn 29 maí 2006 21:31 skrifaði Per Jessen:
That page is in need of some editing - there is nothing implicitly sequential about batch-processing - certainly not on a multi-way machine, but even on a uni-processor, batchjobs maybe executing in parallel, even if not concurrently.
Batch does imply sequentiality
Having implemented big batch jobs on IBM mainframes, made up from several thousand job steps, under JCL and under CA7, I can assure you that this is no the case.
That's what I was trying to say - and when I started it was still UCC7 :-) I think what batch perhaps implies is sequentiality within a job, but a pile of batchjobs is certainly not sequential by default. /Per Jessen, Zürich
Per Jessen wrote:
Joachim Schrod wrote:
Orn E. Hansen wrote:
Mánudaginn 29 maí 2006 21:31 skrifaði Per Jessen:
That page is in need of some editing - there is nothing implicitly sequential about batch-processing - certainly not on a multi-way machine, but even on a uni-processor, batchjobs maybe executing in parallel, even if not concurrently.
Batch does imply sequentiality
Having implemented big batch jobs on IBM mainframes, made up from several thousand job steps, under JCL and under CA7, I can assure you that this is no the case.
That's what I was trying to say - and when I started it was still UCC7 :-)
Yes, I agreed with you and wanted to substantiate it.
I think what batch perhaps implies is sequentiality within a job, but a pile of batchjobs is certainly not sequential by default.
Ah, that's one of the reasons to switch to CA7. There you can define that job steps are independent and can be executed in parallel. Some wizards can even bind that parallelization to resource availability; though that's not my level of expertise. Bringing this thread back to SUSE and Linux: Anybody knows a good Open Source scheduler/batch system for Linux? batch and cron are a joke, and LSF is (a) expensive and (b) overshoot for single systems. We always start to write own, more or less application-specific, schedulers in Perl, but that's not a real solution. Integration in fail-over cluster environments (i.e., support for jobs on logical hosts that might or might not be active on a physical node) is a must. Utilizing Petri-Net methods (pre- and postconditions of input and output availability for scheduling and parallelization decisions) would be a definitive plus. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Joachim Schrod wrote:
I think what batch perhaps implies is sequentiality within a job, but a pile of batchjobs is certainly not sequential by default.
Ah, that's one of the reasons to switch to CA7. There you can define that job steps are independent and can be executed in parallel. Some wizards can even bind that parallelization to resource availability; though that's not my level of expertise.
Funny you should mention that - that was _my_ expertise. I spent a couple of years in the late 80s optimising tape-drive resources to the workload - yes, "workload balancing", that what it was called in CA7. Once you'd grasped the concept, you could do some absolute wonders with it. I'm not sure about making jobsteps independent - if they're all in the same JCL-member, there's nothing CA7 can do. I think you might be talking about the situation where each job is a single step? I've never worked with that - we always had several steps in most jobs.
Bringing this thread back to SUSE and Linux: Anybody knows a good Open Source scheduler/batch system for Linux? batch and cron are a joke, and LSF is (a) expensive and (b) overshoot for single systems. We always start to write own, more or less application-specific, schedulers in Perl, but that's not a real solution.
Amen. Do let me know if you ever find something. Occasionally I sorely miss CA7. /Per Jessen, Zürich
Per Jessen wrote:
Joachim Schrod wrote:
I'm not sure about making jobsteps independent - if they're all in the same JCL-member, there's nothing CA7 can do.
Yes, you're right, they need to be in different members. Technically, that makes them different jobs and not different steps, but I never looked at it that way.
Bringing this thread back to SUSE and Linux: Anybody knows a good Open Source scheduler/batch system for Linux? batch and cron are a joke,
Amen. Do let me know if you ever find something. Occasionally I sorely miss CA7.
I'll do so. But don't hold your breath. :-) Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Anders Johansson wrote:
On Sunday 28 May 2006 14:15, Per Jessen wrote:
As an aside - batch still exists - batch is everything that is not realtime or interactive/on-line. An interactive/on-line transaction is something with a less than 3sec response time. Compiling the Linux kernel is batch.
That's a redefinition of the term, it wasn't what "batch" was meant to mean. I know that modern mainframe programmers refer to "batch jobs" meaning as opposed to "online programs",
Also not-so-modern mainframe people will talk about batchjobs - that's the way it's always been, right back to the punchcard days. Maybe it's a redefinition, I don't know. Back in my own IBM system programming days (late 1980s), we'd run up towards 10'000 batchjobs a night.
In the sense that a makefile is similar (very loosely) to an IBM JCL card, then yes, compiling anything is "batch".
Yep. /Per Jessen, Zürich
Orn E. Hansen wrote:
Laugardaginn 27 maí 2006 11:58 skrifaði Per Jessen:
If it is truly redundant, which other function is doing the same thing? If you think the function is superfluous, just remove it.
I know I can remove it, it's not the point. The point is, whenever I update the system, they're just gonna return.
OK, perhaps. My point is - you're in control. No-one is telling you what to do. But if you accept SUSEs defaults, yes, you'll get something you don't want. I generally use the SUSE default ('coz I haven't built my own installation-profiles just yet), and I always get stuff I don't want/need. Samba for instance.
But, as we are talking about SUSE Linux, I don't believe there is a tickbox during installation that clearly says "For server use" or "For desktop use" - so SUSE should try to cover most requirements.
The latest "ideology" is to have A) Server, known as Enterprise Linux, B) Desktop environment, and C) Development environment.
If you're after a Linux specifically for the desktop, maybe NLD is the right option instead of plain SUSE Linux.
and I feel they should be put into a YaST module, where the packages "suggest" cron jobs, and a user selects which he thinks would benefit him. Of course, that's my opinion on the matter.
With SUSE Linux it's a matter of a default that is fairly appropriate for the most people. What's best - that you need to deselect something or that others need to select it? /Per Jessen, Zürich
Per Jessen wrote:
The latest "ideology" is to have A) Server, known as Enterprise Linux, B) Desktop environment, and C) Development environment.
Orn E. Hansen wrote:
If you're after a Linux specifically for the desktop, maybe NLD is the right option instead of plain SUSE Linux.
Plesae correct me if I'm wrong, but NLD and SLES are released after 3-4 SL releases, and change far less. And because they change less, SuSE could then sell Service Level Agreements (SLAs). This "enterprise" model, including Service was actually originated by SuSE, and not Red Hat. Red Hat tried to sell SLAs atop of its last ".2" release -- e.g., Red Hat Enterprise Linux release 1 is retroactively considered Red Hat Linux 6.2E (which included a SLA). And SLES 7 outsold RHL6.2E 5:1 -- hence Red Hat's change to a separate product as of RHL7.x -> RHEL2[.1]. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
On Sat, 2006-05-27 at 08:28 +0200, Orn E. Hansen wrote:
I've been a bit amazed over the years, of the intense "updates" that usually are run in the cron, during the night times. Several times, I've been playing games, or just browsing the net on my desktop, during early morning hours, when my computer has gone to sleep when running the cron update. Usually this is a period, of a whole hour, and sometimes more. I've often mentioned it, and despite that this function is reduntant function from the old batch time hours of Unix, nobody has bothered removing it from the desktop linux environment.
Disable the "anacron" service. That's the service that runs missed "cron" jobs due to downtime/power-off. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
On Saturday 27 May 2006 15:27, Bryan J. Smith wrote:
Disable the "anacron" service. That's the service that runs missed "cron" jobs due to downtime/power-off.
No. The hourly/daily/weekly cron jobs will be run by cron itself, there is a job running every 15 minutes, and this job will look to see if it's overdue (by looking at the age of lock files) and if it is, it will run them anacron, as far as I can see, isn't included in suse
On Sat, 2006-05-27 at 16:53 +0200, Anders Johansson wrote:
No. The hourly/daily/weekly cron jobs will be run by cron itself, there is a job running every 15 minutes, and this job will look to see if it's overdue (by looking at the age of lock files) and if it is, it will run them anacron, as far as I can see, isn't included in suse
Hmmm, I guess the behavior differs on SuSE from Red Hat. If you disable Anacron on Red Hat, no missed cronjobs run. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
Laugardaginn 27 maí 2006 15:27 skrifaðir þú:
Disable the "anacron" service. That's the service that runs missed "cron" jobs due to downtime/power-off.
I'm running SUSE 10.1, and there's no such service here. I've changed the cron.daily to run at a fixed time of day. And I've set it "not" to recreate the mandb.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 22:56 +0200, Orn E. Hansen wrote:
cron.daily to run at a fixed time of day. And I've set it "not" to recreate the mandb.
I'm not sure that is wise. It takes under a minute in my system, which is five years old... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeNYctTMYHG2NR9URAhxTAJ4synV6yESgxXaDfONCJTmc31wwDACfZdud z5aFcUTr+rtVyNCvvg3yZrQ= =Cg40 -----END PGP SIGNATURE-----
Sunnudaginn 28 maí 2006 00:43 skrifaði Carlos E. R.:
I'm not sure that is wise. It takes under a minute in my system, which is five years old...
Doesn't it recreate the mandb, whenever it actually installs new man pages with rpm? I haven't looked lately, but it seems more appropriate to do it at that time, than in a cron ... since, unless I'm "editing" the pages, they're pretty much gonna stay the same.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-05-28 at 02:11 +0200, Orn E. Hansen wrote:
I'm not sure that is wise. It takes under a minute in my system, which is five years old...
Doesn't it recreate the mandb, whenever it actually installs new man pages with rpm? I haven't looked lately, but it seems more appropriate to do it at that time, than in a cron ... since, unless I'm "editing" the pages, they're pretty much gonna stay the same.
Its not so simple. Man pages are expanded and processed to be read; a second read uses the already processed page. After some days not beeing used, the expanded pages get erased. If I'm not mistaken, the index has to track all those pages. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEePUqtTMYHG2NR9URAo2TAJ934dB0OTj6kY2VkZNLxCQdvnSbCgCfYWvU luti4TVfT4oCOR2CQeyIFpw= =vyXC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 08:28 +0200, Orn E. Hansen wrote:
However, now when I write this, my machine is doing this horrible update of all manuals, which nobody reads anymore.
I do.
And rebuilding the structure of the entire files system (exageration, running several recursive finds), for what purpose only geniuses can figure.
Then I must be a genius :-P It runs "updatedb", so that you can later run "locate". If you don't want it, uninstall findutils-locate...rpm (it is not installed by default, you selected it manually), or dissable the automatic update - but I will not tell you how, I'll leave that as an exercise for the reader :-P The other search is the cleanup of leftovers temporary files and coredumps, if any. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeF2ztTMYHG2NR9URAuKsAJ96pMTk9iQR8t6JP3qsOgFcxbl81ACeMYz9 qjpc+2tUyOSV97XzX7xzGvY= =oYR5 -----END PGP SIGNATURE-----
On Saturday 27 May 2006 10:09, Carlos E. R. wrote:
The Saturday 2006-05-27 at 08:28 +0200, Orn E. Hansen wrote:
However, now when I write this, my machine is doing this horrible update of all manuals, which nobody reads anymore.
I do.
Me too!
And rebuilding the structure of the entire files system (exageration, running several recursive finds), for what purpose only geniuses can figure.
Then I must be a genius :-P
Me too! ;-)
It runs "updatedb", so that you can later run "locate". If you don't want it, uninstall findutils-locate...rpm (it is not installed by default, you selected it manually), or dissable the automatic update - but I will not tell you how, I'll leave that as an exercise for the reader :-P
The other search is the cleanup of leftovers temporary files and coredumps, if any.
Don't forget Beagle... it's also sometimes a resource hog... regards, Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 10:28 -0400, Carl Hartung wrote:
Don't forget Beagle... it's also sometimes a resource hog...
True. I haven't met it yet, I'm still using 9.3, till I have time for the update. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeLIvtTMYHG2NR9URAhq4AKCIL4hK7jwfbGYcbU0fyJOp/x+DuACeMXt6 CvdGA6Qm353aH0c2ofEtg+k= =RRBm -----END PGP SIGNATURE-----
Laugardaginn 27 maí 2006 16:09 skrifaði Carlos E. R.:
Then I must be a genius :-P
You've got a clear advantage over me :-)
It runs "updatedb", so that you can later run "locate". If you don't want it, uninstall findutils-locate...rpm (it is not installed by default, you selected it manually), or dissable the automatic update - but I will not tell you how, I'll leave that as an exercise for the reader :-P
Oh, I've turned the feature off ... usually I just do a "rm -f /etc/cron.*/*" it's much simpler really ... bummer is, it's being recreated every time I update. Maybe someday I'll figure out how to "ln -sd /etc/cron.* void".
On Saturday 27 May 2006 23:00, Orn E. Hansen wrote:
Oh, I've turned the feature off ... usually I just do a "rm -f /etc/cron.*/*" it's much simpler really ... bummer is, it's being recreated every time I update. Maybe someday I'll figure out how to "ln -sd /etc/cron.* void".
Yes, leaving packages installed that you don't want to have, and then complaining when the system repairs what you broke, that's much simpler than just uninstalling what you don't want to have (or, perhaps, just not installing them in the first place - you did do it manually)
Laugardaginn 27 maí 2006 23:06 skrifaði Anders Johansson:
Yes, leaving packages installed that you don't want to have, and then complaining when the system repairs what you broke, that's much simpler than just uninstalling what you don't want to have (or, perhaps, just not installing them in the first place - you did do it manually)
Oh, it's not a case of "I don't want it". It's a case of "I don't want it to kill my machine" thing. There's a difference. Obviously, I want to be able to locate files, emails and stuff like that. And I can remove it all, renice it and stuff ... it's not a question of what I want here. It's a question of a system, that is trying to make it into the desktop world. And I'm just pointing out a fact ... and when I say it's reduntant, I don't mean it's unwanted ... I mean it's low priority.
Orn E. Hansen wrote:
And I can remove it all, renice it and stuff ... it's not a question of what I want here. It's a question of a system, that is trying to make it into the desktop world.
The SUSE Linux distro is not specifically trying to make it onto the desktop, it's trying to do everything. Server, workstation, desktop, mediacenter, whathaveyou.
And I'm just pointing out a fact ... and when I say it's reduntant, I don't mean it's unwanted ... I mean it's low priority.
OK, that was difficult to guess :-) /Per Jessen, Zürich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 23:00 +0200, Orn E. Hansen wrote:
Oh, I've turned the feature off ... usually I just do a "rm -f /etc/cron.*/*" it's much simpler really ... bummer is, it's being recreated every time I update. Maybe someday I'll figure out how to "ln -sd /etc/cron.* void".
Ah... so, someday you will notice that your log files use hundred of megabytes and they do not rotate. Or that some fonts do not work correctly. Or that your tmp directories are full. Or... Ok, it's your machine. But don't complain later. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeNfRtTMYHG2NR9URAnvbAKCNh82G2S/VpfY5VtSzFtne2+NRUACfQAvV T2ZewUv0Q1/EZ47KAwggs5A= =mVhZ -----END PGP SIGNATURE-----
Hi, Carlos, On Saturday 27 May 2006 15:50, Carlos E. R. wrote:
The Saturday 2006-05-27 at 23:00 +0200, Orn E. Hansen wrote:
Oh, I've turned the feature off ... usually I just do a "rm -f /etc/cron.*/*" it's much simpler really ... bummer is, it's being recreated every time I update. Maybe someday I'll figure out how to "ln -sd /etc/cron.* void".
Ah... so, someday you will notice that your log files use hundred of megabytes and they do not rotate. Or that some fonts do not work correctly. Or that your tmp directories are full. Or...
Ok, it's your machine. But don't complain later.
As I like to say, after deleting some element of your computer's operating system because it offended you, go out to your car, open the hood and select a part, say, one whose shape bothers you, and rip it out. Doing that would rightly seem absurd to people, yet they'll do the equivalent to their computers with hardly a second thought. It's hard enough to make computers work well without having them sabotaged by their owners!
-- Cheers, Carlos Robinson
Randall Schulz
Sunnudaginn 28 maí 2006 00:50 skrifaði Carlos E. R.:
Ah... so, someday you will notice that your log files use hundred of megabytes and they do not rotate. Or that some fonts do not work correctly. Or that your tmp directories are full. Or...
Ok, it's your machine. But don't complain later.
However, your point about the log rotate is quite ok. Problem is, that despite all this cronjob stuff, I still have to do a "rm -f /var/log/*.gz" from time to time, as they're getting filled up. So, even if I do allow the cron job to continue, it won't stop my harddisk from filling up, it'll just delay it. The same applies to the job that's supposed to "clear" the tmp directories. Most files in there will be owned be root jobs, they'll remain, and won't be cleared on startup. Ok, I stated in the subject field that I was ranting. I'm simply pointing out, that on a modern desktop machine, it going asleep for an hour is something that in my mind has the word "oobs" written all over it. A cron job, is something that is to be done at lowest possible priority, imo. And I'm just pointing out the irritating effects, not wether it can or can't be "removed" from the system.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-05-28 at 02:25 +0200, Orn E. Hansen wrote:
However, your point about the log rotate is quite ok. Problem is, that despite all this cronjob stuff, I still have to do a "rm -f /var/log/*.gz" from time to time, as they're getting filled up.
Then change the configuration: they are first compressed, then deleted after some months.
So, even if I do allow the cron job to continue, it won't stop my harddisk from filling up, it'll just delay it. The same applies to the job that's supposed to "clear" the tmp directories. Most files in there will be owned be root jobs, they'll remain, and won't be cleared on startup.
Then just tell it to delete those! Hint: /etc/sysconfig/cron
Ok, I stated in the subject field that I was ranting. I'm simply pointing out, that on a modern desktop machine, it going asleep for an hour is something that in my mind has the word "oobs" written all over it. A cron job, is something that is to be done at lowest possible priority, imo. And I'm just pointing out the irritating effects, not wether it can or can't be "removed" from the system.
I agree that it slows the system some; but if your system is so slow as to be unusable, you have something wrong there. I will have a look at ionice when I install 10.1, it will be interesting. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEePattTMYHG2NR9URAgpaAKCYYcmHKYBdcPDpgmAj2MqdyNVg/ACbBHtf e7jNdYdmDCan3KcIHF7/Sio= =Vf1q -----END PGP SIGNATURE-----
Sunnudaginn 28 maí 2006 03:02 skrifaði Carlos E. R.:
I agree that it slows the system some; but if your system is so slow as to be unusable, you have something wrong there.
It's been doing it since 1999 (my first SuSE), and it usually doesn't bother me as it takes place during the early morning hours (5 am, if I'm not mistaken).
I will have a look at ionice when I install 10.1, it will be interesting.
Same here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-05-28 at 14:47 +0200, Orn E. Hansen wrote:
It's been doing it since 1999 (my first SuSE), and it usually doesn't bother me as it takes place during the early morning hours (5 am, if I'm not mistaken).
It varies. If you power off your computer for a sufficient period of time, it will start in the first 15 minutes after powering up, and the same hour thereafter - unless the cronjob is edited to run at a fixed time, which is probably better for an always on system. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeeTEtTMYHG2NR9URApy8AJwNfdUgyIvLwwBuWfu6n7spkHI0lQCfTJ9T Gfc0B2d+pYAmfKcm72ItJA0= =l6ac -----END PGP SIGNATURE-----
Orn E. Hansen wrote:
Ok, I stated in the subject field that I was ranting. I'm simply pointing out, that on a modern desktop machine, it going asleep for an hour is something that in my mind has the word "oobs" written all over it. A cron job, is something that is to be done at lowest possible priority, imo.
Definitely not. Why should something that's being done regularly be low priority? I'd like my nightly backups to be over as fast as possible for instance. As a normal user I also have one or two things that are started with @reboot in my crontab - they too should have normal priority. I understand your ranting, I do so myself occasionally, but some of what you complain about is easily taken care by configuring your system as you want it. The YaST installer cannot guess your usage pattern, nor what you intend to use the machine for, so SUSE has probably chosen what they consider a reasonable compromise. /Per Jessen, Zürich
Sunnudaginn 28 maí 2006 13:52 skrifaði Per Jessen:
I understand your ranting, I do so myself occasionally, but some of what you complain about is easily taken care by configuring your system as you want it. The YaST installer cannot guess your usage pattern, nor what you intend to use the machine for, so SUSE has probably chosen what they consider a reasonable compromise.
Most of the time I avoid doing too much to my system, there are a few reasons why. 1. To me, an OS should be a stable core on which I build something else. I've always find Linux somewhat a Rock and a Hard place, because the updates to the core are far too often. They break something too often, which is always blamed on everyone else, not holding some standard nobody heard of, until after the fact (Yeah, I know I'm exagerating a bit). 2. A desktop system, should be setup for users who use it for other purposes than tweaking the OS for optimal personal use. Linux isn't Unix, and it isn't a batch OS ... batch operating isn't cool stuff, and it isn't a measurement of your greatness like some guys think about "knowing all the cool command line options", it isn't being a geek. A computer is a tool, you don't get yourself a toolbox ... just to have a toolbox, you get it to eventually use it create something else. Some of that stuff need to be done, but when doing it "now" means someone has to take a lunch break from their work, that's an "oobs" to me. I remember the good old PS/2 systems, with IBM's OS/2. They proclaimed it could do two things at the same time. I once tried to format a floppy, and do something else at the same time ... wanna guess how long it took to format the floppy? Try guessing an hour. That wasn't impressive, even in those days. On a desktop computer, there are a few things that don't need prioritation, and there are those that do. A computer doesn't have to react to the user, more quickly than the user does in human terms. But a computer, where a user has to wait for the interface ... and on a system, that has time and time again, stated it's "faster than windows", "better than windows", "fancier than windows" ... makes it neither funny, nor impressive. It's not a reasonable thing, to demand that some user "tweaks" his system, to get rid of the slowness ... it's reasonable to say that the users who know what they're doing, change the system, to make it slow to obtain some other purpose. The default should be user friendly, not geek friendly.
/Per Jessen, Zürich
Orn E. Hansen wrote:
Sunnudaginn 28 maí 2006 13:52 skrifaði Per Jessen:
I understand your ranting, I do so myself occasionally, but some of what you complain about is easily taken care by configuring your system as you want it. The YaST installer cannot guess your usage pattern, nor what you intend to use the machine for, so SUSE has probably chosen what they consider a reasonable compromise.
Most of the time I avoid doing too much to my system, there are a few reasons why.
1. To me, an OS should be a stable core on which I build something else. I've always find Linux somewhat a Rock and a Hard place, because the updates to the core are far too often. They break something too often, which is always blamed on everyone else, not holding some standard nobody heard of, until after the fact (Yeah, I know I'm exagerating a bit).
That's Microsoft model for an OS, clean, bold and useless without more money on extra software. Linux it's different, they put all the options and you need to "fine tune" the systems. "Just for Power Users", this way has too many benefits and only one difficulty: The fine tunning.
2. A desktop system, should be setup for users who use it for other purposes than tweaking the OS for optimal personal use.
Linux isn't Unix, and it isn't a batch OS ... batch operating isn't cool stuff, and it isn't a measurement of your greatness like some guys think about "knowing all the cool command line options", it isn't being a geek. A computer is a tool, you don't get yourself a toolbox ... just to have a toolbox, you get it to eventually use it create something else. Some of that stuff need to be done, but when doing it "now" means someone has to take a lunch break from their work, that's an "oobs" to me. I remember the good old PS/2 systems, with IBM's OS/2. They proclaimed it could do two things at the same time. I once tried to format a floppy, and do something else at the same time ... wanna guess how long it took to format the floppy? Try guessing an hour. That wasn't impressive, even in those days.
I'm not a toolbox... but I know were is every tool and I know how to use all my tools. Using Windows as "MyToolbox" it's the same as doing it without a toolbox at all! I don't think there is a Universal Tool Box that fits all your hand work and, at the same time, it's not biag as your wall, heavy as your car and complex to manage. Beside there are specialized Linux distributions all over the world, SuSE needs and ask fine tunning for what-do-you-exactly-want-to-do(TM).
On a desktop computer, there are a few things that don't need prioritation, and there are those that do. A computer doesn't have to react to the user, more quickly than the user does in human terms. But a computer, where a user has to wait for the interface ... and on a system, that has time and time again, stated it's "faster than windows", "better than windows", "fancier than windows" ... makes it neither funny, nor impressive. It's not a reasonable thing, to demand that some user "tweaks" his system, to get rid of the slowness ... it's reasonable to say that the users who know what they're doing, change the system, to make it slow to obtain some other purpose. The default should be user friendly, not geek friendly.
/Per Jessen, Zürich
Orn E. Hansen wrote:
Most of the time I avoid doing too much to my system, there are a few reasons why.
1. To me, an OS should be a stable core on which I build something else. I've always find Linux somewhat a Rock and a Hard place, because the updates to the core are far too often.
I guess it's time to get a little philosophical :-) A Linux distro is a bundling of an OS, a GUI and a whole pile of applications with an incredibly wide scope. Personally I think of the OS as the kernel, the modules and system utilities (e.g. modprobe), plus the minimal set of utilities and libraries that enable it to run applications, plus the networking stack. And that really doesn't change that much unless you want it to e.g. to get support for the latest fantastic Wifi interface. The GUI is KDE (for me), all the X-stuff, the artwork and all that jazz. Again, unless you want to be right at the bleeding edge, it doesn't change much. The applications, mostly due to the vast numbers, change much more often. For SUSE 10.1, I've been quite active in the beta-tests and I had a few systems that changed a lot every two weeks. Apart from that exceptional exercise, I've kept my systems on mostly 9.0, some 8.2 and even a single one at 7.1. They've required quite a few applications updates, and because I like to, I've also been keeping up with the kernel releases. As to "avoiding doing too much to your system", I fully agree, but at installation time you _do_ determine what you want your system to do and look like. You choose between thousands of packages, you choose the GUI etc. SO at that time, you already do a LOT to your system. The key thing is that there is no single Linux distro that could possibly cater to all of its users equally well. Therefore, unlike certain OS'es and GUI'es from certain wellknown vendors, you get a wide choice in customising your system. Linux is the diametrically opposite of "one size fits all", although a distro vendor will need to achieve some level of that.
2. A desktop system, should be setup for users who use it for other purposes than tweaking the OS for optimal personal use.
Agree. But SUSE Linux is not and does not purport to be just a desktop system. I could perhaps be tempted to rant about lack of JFS install support, that smartd isn't started by default, that NTP isn't running by default, that samba is always installed, but ...
Linux isn't Unix, and it isn't a batch OS ... batch operating isn't cool stuff,
You're somehow hung up about this batch stuff and UNIX. Linux does quite well processing batch-type workloads, whether or not it's a batch OS. Even IBMs z/OS, perhaps _the_ archetypical batch OS, does very well in running OLTP systems. As to Linux not being UNIX - who really cares?
A computer is a tool, you don't get yourself a toolbox ... just to have a toolbox, you get it to eventually use it create something else. Some of that stuff need to be done, but when doing it "now" means someone has to take a lunch break from their work, that's an "oobs" to me.
You've decided to use a tool that was not custom-designed for your intended purpose - and you complain that you need to tweak it a bit? Frankly, that's a bit of an ooops to me.
On a desktop computer, there are a few things that don't need prioritation, and there are those that do. A computer doesn't have to react to the user, more quickly than the user does in human terms. But a computer, where a user has to wait for the interface ... and on a system, that has time and time again, stated it's "faster than windows", "better than windows", "fancier than windows" ... makes it neither funny, nor impressive.
It does to me. In my shop, SUSE Linux is both faster and better than Windows - not sure what I'm to do with "fancier", but it's a lot cheaper too. That's pretty impressive.
It's not a reasonable thing, to demand that some user "tweaks" his system, to get rid of the slowness
But it is reasonable to make me tweak my system to have it use NTP? Or connect to a VPN?
... it's reasonable to say that the users who know what they're doing, change the system, to make it slow to obtain some other purpose. The default should be user friendly, not geek friendly.
Well, define "user" then. My typical user is an employee that uses a workstation from 0800 to 1700. Or perhap a salesman with a laptop on the road all day. What you're asking is utopia. /Per Jessen, Zürich
Mánudaginn 29 maí 2006 00:16 skrifaði Alvaro Kuolas:
Funny, that's the way Bill Gates calls Windows.
You're a funny guy ... Mr. BIll Gates is a buisness man, and I'll tell you what ... he's a very good one at that. But he ain't a visionary, nor an artist. And please post a link, where he claims to be one.
On Sat, 2006-05-27 at 08:28 +0200, Orn E. Hansen wrote:
entire files system (exageration, running several recursive finds), for what
I would still like to see a way to prioritise disc assess. So that I can say process "updatedb" and anything it calls, will get nothing but the leftover cycles. If it's alreay running, and something else comes up, like say, ls -lh, then ls -lh will immediately be given priority. You can nice -n 19 updatedb until the cows come home, it still kills your machine. I have disabled updatedb completely, and only run manually before I go to bed from time to time, because, with a 5400rpm hard disc, my notebook becomes useless while running. On my desktop, with a 7200rpm/16mb SATA disc, with SUSE 10.0, updatedb comes on when I switch it on. The box is useless until updatedb is done. Hans
On Saturday 27 May 2006 16:35, Hans du Plooy wrote:
On Sat, 2006-05-27 at 08:28 +0200, Orn E. Hansen wrote:
entire files system (exageration, running several recursive finds), for what
I would still like to see a way to prioritise disc assess. So that I can say process "updatedb" and anything it calls, will get nothing but the leftover cycles. If it's alreay running, and something else comes up, like say, ls -lh, then ls -lh will immediately be given priority.
There is a way, it's called ionice. Have a look at "man ionice" for details
On Sat, 2006-05-27 at 17:02 +0200, Anders Johansson wrote:
I would still like to see a way to prioritise disc assess. So that I can say process "updatedb" and anything it calls, will get nothing but the leftover cycles. If it's alreay running, and something else comes up, like say, ls -lh, then ls -lh will immediately be given priority.
There is a way, it's called ionice. Have a look at "man ionice" for details
Oh nice! I'll give that a try... Thanks Hans
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 17:02 +0200, Anders Johansson wrote:
There is a way, it's called ionice. Have a look at "man ionice" for details
It must be new, it is not included in 9.3 - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeLK1tTMYHG2NR9URAgGPAJ9Xq/Efd3wnWuJ77x26n9OQo94r7ACeKsAL lXNuAK8mLTsNg9V5pykD7IA= =FXcF -----END PGP SIGNATURE-----
On Saturday 27 May 2006 22:12, Carlos E. R. wrote:
The Saturday 2006-05-27 at 17:02 +0200, Anders Johansson wrote:
There is a way, it's called ionice. Have a look at "man ionice" for details
It must be new, it is not included in 9.3
As far as I can see, it was added Aug. 1 2005
Hans du Plooy wrote:
I would still like to see a way to prioritise disc assess. So that I can say process "updatedb" and anything it calls, will get nothing but the leftover cycles.
nice and ionice will help you.
You can nice -n 19 updatedb until the cows come home, it still kills your machine.
Maybe change your preemption-setting as well. /Per Jessen, Zürich
On Saturday 27 May 2006 08:28, Orn E. Hansen wrote:
I've been a bit amazed over the years, of the intense "updates" that usually are run in the cron, during the night times. Several times, I've been playing games, or just browsing the net on my desktop, during early morning hours, when my computer has gone to sleep when running the cron update. Usually this is a period, of a whole hour, and sometimes more. I've often mentioned it, and despite that this function is reduntant function from the old batch time hours of Unix, nobody has bothered removing it from the desktop linux environment.
Er, yes they have, it's disabled by default and only enabled if you expressly install the findutils-locate package manually Personally I like locate, it's by far the fastest way to find a file I have at my disposal
However, now when I write this, my machine is doing this horrible update of all manuals, which nobody reads anymore.
Call me nobody
And rebuilding the structure of the entire files system (exageration, running several recursive finds), for what purpose only geniuses can figure.
Updating the locate database
But I've finally been able to work on my machine while it was doing this. On all other occasions, even with a AMD64 3000+, my machine went to sleep ... and I could hardly browse the desktop during this hour of nonsense. But now, yes now I CAN ... but it took a desktop with a dual core CPU to do it. Go figure :-)
No, I would say the CPU has next to nothing to do with this. The job is so heavily I/O bound that your CPU power is almost irrelevant. If you have problems working while the job is running, you might want to have a look at your DMA settings for the hard drives
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 16:56 +0200, Anders Johansson wrote:
No, I would say the CPU has next to nothing to do with this. The job is so heavily I/O bound that your CPU power is almost irrelevant.
Some cpu applets can show that; for instance, the gnome system applet, if you change the color used for "IOWait", which by default is black and therefore invisible. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeLURtTMYHG2NR9URAp6+AKCXK9Idjzcy/3JEq7tGoqDKc2kevwCfSVDR b93dF3Yi2qtJ6qlE8lNy91o= =5+28 -----END PGP SIGNATURE-----
Laugardaginn 27 maí 2006 16:56 skrifaði Anders Johansson:
No, I would say the CPU has next to nothing to do with this. The job is so heavily I/O bound that your CPU power is almost irrelevant.
This has always been the problem, the I/O traffic has top priority, so no matter how you prioritise the darned doodly doo ... you're just gonna have to take a break for an hour. However a dual CPU core, does help ... although I didn't expect it to.
On Saturday 27 May 2006 23:06, Orn E. Hansen wrote:
Laugardaginn 27 maí 2006 16:56 skrifaði Anders Johansson:
No, I would say the CPU has next to nothing to do with this. The job is so heavily I/O bound that your CPU power is almost irrelevant.
This has always been the problem, the I/O traffic has top priority, so no matter how you prioritise the darned doodly doo ... you're just gonna have to take a break for an hour. However a dual CPU core, does help ... although I didn't expect it to.
I still think it's a problem with your DMA settings. If you have DMA enabled on your hard drives, they can read from and write to your hard drives without using the CPU. Without DMA, on the other hand, everything has to go through the CPU, and that will seriously kill any system, regardless of the CPU power Compare with viewing DVDs, for example. With DMA, you can view a DVD on a relatively low end system. Without it, you get stuttering on even very good systems
On Saturday 27 May 2006 23:12, Anders Johansson wrote:
I still think it's a problem with your DMA settings. If you have DMA enabled on your hard drives, they can read from and write to your hard drives without using the CPU.
argh. should have read "read from and write to your memory"
Laugardaginn 27 maí 2006 23:12 skrifaði Anders Johansson:
Compare with viewing DVDs, for example. With DMA, you can view a DVD on a relatively low end system. Without it, you get stuttering on even very good systems
It's a SATA drive ... haven't seen any DMA settings for that yet.
Orn E. Hansen wrote:
Laugardaginn 27 maí 2006 23:12 skrifaði Anders Johansson:
Compare with viewing DVDs, for example. With DMA, you can view a DVD on a relatively low end system. Without it, you get stuttering on even very good systems
It's a SATA drive ... haven't seen any DMA settings for that yet.
I'm not sure, but I suspect the SATA interface chips use only DMA. I see no reason why the SATA standard would include PIO support or any such ancient stuff. /Per Jessen, Zürich
Anders Johansson:
Compare with viewing DVDs, for example. With DMA, you can view a DVD on a relatively low end system. Without it, you get stuttering on even very good systems
Software RAID-5 writes are essentially PIO. And the worst thing about it is that you won't see the bottleneck in CPU load or even CPU I/O serving. But it essentially brings any desktop system down to 20-30MBps during writes. Orn E. Hansen wrote:
It's a SATA drive ... haven't seen any DMA settings for that yet.
Per Jessen wrote:
I'm not sure, but I suspect the SATA interface chips use only DMA. I see no reason why the SATA standard would include PIO support or any such ancient stuff.
SATA is DMA-only. That's one of the reasons why you can only have 1 device per channel. Now also remember that there is ATA (simple block -- e.g., hard drive) and then ATAPI (rich block command set -- e.g., optical) -- ATAPI is a _super_set of ATA. SATA ATAPI devices are very _problematic_ right now, because most are using ATA-to-SATA converters. The result is not only do many SATA drivers lack support for the full ATAPI command set, but sometimes these ATAPI devices slip into PIO mode. That's why most SATA ATAPI devices only work on select ATA controllers -- like the Intel ICH6+. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-05-28 at 08:25 -0400, Bryan J. Smith wrote:
Software RAID-5 writes are essentially PIO.
Why is that? I'm curious. Can't it use dma, even if it uses smaller writes? Just guessing. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeeYbtTMYHG2NR9URAlEZAJ45JS4cbGskwLoKj4nSlGEneyRSkACbBKNa cz1cojTcyenAKJaLRdsaayA= =/0qh -----END PGP SIGNATURE-----
On Sun, 2006-05-28 at 20:04 +0200, Carlos E. R. wrote:
Why is that? I'm curious. Can't it use dma, even if it uses smaller writes? Just guessing.
Because all writes are Programmed I/O (PIO) through the CPU. XOR might be simple, but attempting to deal with the traditional LOAD/EXEC/STOR through the CPU -- even using streamed XOR operations -- at hundreds of MBps is still damn slow through. CPUs are not I/O processors (IOP). And such IOP operations take away from other operations. So unless your system is a dedicated storage device, and not servicing anything else (which is fine), you're taking away from your other operations. And, again, it's virtually _impossible_ to measure these metrics in the current Linux kernel. All you can find out is I/O wait and servicing for processes, not the I/O latency and throughput itself. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-05-29 at 11:22 -0400, Bryan J. Smith wrote:
On Sun, 2006-05-28 at 20:04 +0200, Carlos E. R. wrote:
Why is that? I'm curious. Can't it use dma, even if it uses smaller writes? Just guessing.
Because all writes are Programmed I/O (PIO) through the CPU.
XOR might be simple, but attempting to deal with the traditional LOAD/EXEC/STOR through the CPU -- even using streamed XOR operations -- at hundreds of MBps is still damn slow through.
CPUs are not I/O processors (IOP). And such IOP operations take away from other operations. So unless your system is a dedicated storage device, and not servicing anything else (which is fine), you're taking away from your other operations.
And, again, it's virtually _impossible_ to measure these metrics in the current Linux kernel. All you can find out is I/O wait and servicing for processes, not the I/O latency and throughput itself.
That I understand. But my question was in the line of why raid-5 uses, or has to use, PIO instead of DMA. What is so different for raid-5. I can guess, but I don't know. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEe0BGtTMYHG2NR9URAmIqAJ9jq6gzzRBYVHMG3g5MtOz/DQcrlwCfTkdc zppT79H4GxKiuHek5hy6Y/I= =00IB -----END PGP SIGNATURE-----
Carlos E. R. wrote:
That I understand. But my question was in the line of why raid-5 uses, or has to use, PIO instead of DMA. What is so different for raid-5. I can guess, but I don't know.
I'm guessing what Bryan is trying to say is that every RAID5 write requires CPU-cycles, even if the resulting data-write is almost certainly done with DMA. So in effect RAID5 sort of becomes a little like PIO. /Per Jessen, Zürich
participants (12)
-
Alvaro Kuolas -
Anders Johansson -
Bruce Marshall -
Bryan J. Smith -
Carl Hartung -
Carlos E. R. -
Hans du Plooy -
Hans du Plooy -
Joachim Schrod -
Orn E. Hansen -
Per Jessen -
Randall R Schulz