Huh? I've run SP5 on two very heavily used SMP workstations (both have SP6 now) and SP6 on one more SMP machine. Had no problems with it. I think your problems are not related to SMP.
Re:"Long uptime is evil" or "gee isnt my system op
on
Server Uptimes Ranked
·
· Score: 1
Oh yes, even the kernel can crash at 497. Been there, had that. Of course, it won't do it every time. For me, it happened with 2.0.34 - Alan says it should be pretty much fixed in 2.2.x. As of the strange things in userland, they already begin taking place after 2^31 Hz (298 days), because some programs use jiffies value as signed. There were problems at least with times() (both in glibc and kernel), select() (kernel) and procutils .
Re:Notice something familiar about MS uptimes?
on
Server Uptimes Ranked
·
· Score: 1
Just that the 49 day thing does not happen everytime (or at all for your boxes) does not mean it does not exist. I had it happen for my SMP workstation (NT 4 SP 5 (at the time)). To be fair, I've also had a UP Linux 2.0.34 box to crash after 497 days when its jiffies wrapped around, and that does not happen for every 2.0 box, either. (NT uses 1024Hz, Linux 100Hz, both have 32bit counter.)
> 7. Viper V770: Go with a Matrox, and a G200 at > least. Better Linux support and a better card > for the money.
nVidia's commitment to Linux support is a good thing. As for better card, I have _very_ good experience with many TNT2's and, lately, G256's. As a matter of fact, I'm running linux/XF-3.3.5 w/g256-patch right now, and it's very stable. And under NT (where the OpenGL driver is ready) is _blazingly_ fast. So I'd even recommend a G256, if you can tolerate waiting few weeks for 3d support, and if you need OpenGL power (depends on your application, of course). XFree 4.0 won't be released for Matrox any sooner than for nVidia.
> 3c905: Go DEC Tulip-based instead. It performs > better under Linux, and the driver is > excellent.
Well, I'm running a bunch of them under Linux right now, and I really can't see how the performance or stability could be any better.
> 9. SB PCI128: Try a standard SB16 instead. > You'll never notice the difference.
Bullocks. Plug them to hifi equipment, and the SB16 will sound like a chainsaw, whereas SB64PCI has fairly good D/A (yes, I am using one right now for mp3 listening). Besides, SB64PCI's go for $30 or something, so why bother. (Do they still sell those SB16's, anyway?)
> Keyboard: Please, if there is to be someone > typing at it night and day, substitute a more > expensive ergo unit.
Agree. While the keyboard preferences vary from person to person, I was supriced to see how good those ergo keyboards can feel right away, when I first tried one.
2x performance increases have been reported on massive disk I/O operations (like cloning disks) by setting the IDE drivers to use DMA and 32-bit transfers. The kernel seems to use more conservative settings unless told otherwise.
The commands are
#/sbin/hdparm -c 1/dev/hda (or hdb, hdc etc)
to use 32-bit I/O over the PCI bus. (The hdparm(8) manpage says that you may need to use -c 3 for some chipsets.)
Use:
#/sbin/hdparm -d 1/dev/hda (or hdb, hdc etc)
to enable DMA. This may depend on support for your motherboard chipset being compiled into your kernel.
You can test the results of your changes by running hdparm in performance test mode:
#/sbin/hdparm -t/dev/hda (or hdb, hdc etc)
When you've found the optimal settings, you should consider doing a
#/sbin/hdparm -k 1/dev/hda (or hdb, hdc etc)
to keep these settings across an IDE reset. I've seen the kernel reset the IDE controller occasionally and if you don't set -k 1, the other settings will be reset to defaults and you'll lose all your performance gains.
The -m option can be used to change the number of sectors transferred on each interrupt. You may get additional gains by tweaking this, but it didn't do anything for me.
Author: Kenn Humborg (Obtained from TuneLinux.com)
Slashdot Mirror
Huh? I've run SP5 on two very heavily used SMP workstations (both have SP6 now) and SP6 on one more SMP machine. Had no problems with it. I think your problems are not related to SMP.
Oh yes, even the kernel can crash at 497. Been there, had that. Of course, it won't do it every time. For me, it happened with 2.0.34 - Alan says it should be pretty much fixed in 2.2.x. As of the strange things in userland, they already begin taking place after 2^31 Hz (298 days), because some programs use jiffies value as signed. There were problems at least with times() (both in glibc and kernel), select() (kernel) and procutils .
Just that the 49 day thing does not happen everytime (or at all for your boxes) does not mean it does not exist. I had it happen for my SMP workstation (NT 4 SP 5 (at the time)). To be fair, I've also had a UP Linux 2.0.34 box to crash after 497 days when its jiffies wrapped around, and that does not happen for every 2.0 box, either. (NT uses 1024Hz, Linux 100Hz, both have 32bit counter.)
> 7. Viper V770: Go with a Matrox, and a G200 at
> least. Better Linux support and a better card
> for the money.
nVidia's commitment to Linux support is a good thing. As for better card, I have _very_ good experience with many TNT2's and, lately, G256's.
As a matter of fact, I'm running linux/XF-3.3.5 w/g256-patch right now, and it's very stable. And under NT (where the OpenGL driver is ready) is _blazingly_ fast. So I'd even recommend a G256,
if you can tolerate waiting few weeks for 3d support, and if you need OpenGL power (depends on your application, of course). XFree 4.0 won't be released for Matrox any sooner than for nVidia.
> 3c905: Go DEC Tulip-based instead. It performs
> better under Linux, and the driver is
> excellent.
Well, I'm running a bunch of them under Linux right now, and I really can't see how the performance or stability could be any better.
> 9. SB PCI128: Try a standard SB16 instead.
> You'll never notice the difference.
Bullocks. Plug them to hifi equipment, and the SB16 will sound like a chainsaw, whereas SB64PCI has fairly good D/A (yes, I am using one right now for mp3 listening). Besides, SB64PCI's go for $30 or something, so why bother. (Do they still sell those SB16's, anyway?)
> Keyboard: Please, if there is to be someone
> typing at it night and day, substitute a more
> expensive ergo unit.
Agree. While the keyboard preferences vary from person to person, I was supriced to see how good those ergo keyboards can feel right away, when I first tried one.
No, Inari is a place in northern Finland.
For those wondering what this is about: in the
original posting Schneier was spelled Schneir.
Roblimo seems to have corrected that already,
though.
Tanenbaum still holds the record for
misspellings. How come nobody misspells
Torvalds?
Perhaps it means this:
2 5/]
/sbin/hdparm -c 1 /dev/hda (or hdb, hdc etc)
/sbin/hdparm -d 1 /dev/hda (or hdb, hdc etc)
/sbin/hdparm -t /dev/hda (or hdb, hdc etc)
/sbin/hdparm -k 1 /dev/hda (or hdb, hdc etc)
[http://www.linux.com/tuneup/articles/19990518/
2x performance increases have been reported on massive disk I/O
operations (like cloning disks) by setting the IDE drivers to use DMA
and 32-bit transfers. The kernel seems to use more conservative
settings unless told otherwise.
The commands are
#
to use 32-bit I/O over the PCI bus. (The hdparm(8) manpage says that
you may need to use -c 3 for some chipsets.)
Use:
#
to enable DMA. This may depend on support for your motherboard
chipset being compiled into your kernel.
You can test the results of your changes by running hdparm in
performance test mode:
#
When you've found the optimal settings, you should consider doing a
#
to keep these settings across an IDE reset. I've seen the kernel reset
the IDE controller occasionally and if you don't set -k 1, the other
settings will be reset to defaults and you'll lose all your performance
gains.
The -m option can be used to change the number of sectors transferred
on each interrupt. You may get additional gains by tweaking this, but it
didn't do anything for me.
Author: Kenn Humborg (Obtained from TuneLinux.com)