Hi!
Trying to kill the keyboard, [EMAIL PROTECTED] produced:
> The solution is to either get a faster computer or don't use X.
> X takes a lot of CPU cycles away from afio and ftape so your errors
> will increase.
You may also want to use buffering, e.g. the program buffer.
This will help as the tape has a bit more reserve to keep
streaming. You could also 'unnice' the backup programs (nice -n
-20, or use renice, top, or qps for that task). And maybe nice X
(at least at startup).
If you don't mind having to reboot if your programs get into
an endless loop (i.e it *is* dangerous!) you could change the
scheduling from the default cooperative method to a 'real-time'
scheduling, so that no other program will get *any* cycles while
the backup programs run.
Alternatively there is a sched_idle kernel patch, so you could
start your X with it and it will only get the cycles *not* used
by *any* other program. Again, you see this can be ... strange.
You can change scheduling modes while the program runs (if you
are root). For example qps does that (but of course would
need a patch for sched_idle, though that is no problem (*I*
managed it)). You could also write a suid-program which could
start/set a program in sched_idle.
-Wolfgang
--
PGP 2 welcome: Mail me, subject "send PGP-key".
Unsolicited Bulk E-Mails: *You* pay for ads you never wanted.
How to dominate the Internet/WWW/etc? Destroy the protocols! See:
http://www.opensource.org/halloween.html
