Re: [OT] Suitable Athlon Motherboard for Linux
Hans-Christian Armingeon wrote: > On Wednesday, 4. July 2001 20:49, Joseph Mathewson wrote: > > Having heard the various horror stories about the VIA PCI data corruption > > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > > motherboard that works reliably under Linux (I don't think all the issues > > have been cleared up in the kernel yet?). There must be quite a few Linux > > Athlon users out there - what boards are you using and with what success? > > > > I can't see much alternative to Via chipsets in the Ahtlon market, other > > than all-in-one-graphics-sound-network jobbies that, from previous > > experience (namely the i810), are also best avoided. What about Ali chipsets, like in ASUS A7A266 ? > > > > > Joe. > > > I think the SIS chipset based mainboards will be at a very good performance, > even faster than VIA. I read it in the german c't magazine. > > Johnny > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
Hans-Christian Armingeon wrote: On Wednesday, 4. July 2001 20:49, Joseph Mathewson wrote: Having heard the various horror stories about the VIA PCI data corruption bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 2.4.3, I was just wondering if anyone had a suggestion for an Athlon motherboard that works reliably under Linux (I don't think all the issues have been cleared up in the kernel yet?). There must be quite a few Linux Athlon users out there - what boards are you using and with what success? I can't see much alternative to Via chipsets in the Ahtlon market, other than all-in-one-graphics-sound-network jobbies that, from previous experience (namely the i810), are also best avoided. What about Ali chipsets, like in ASUS A7A266 ? Joe. I think the SIS chipset based mainboards will be at a very good performance, even faster than VIA. I read it in the german c't magazine. Johnny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE disk slow? There's help...
safemode wrote: > That's what i was thinking, but 30MB/s seems to be quite an exaggeration. > On my > Intel Corporation 82371AB PIIX4 IDE (rev 01), ide chipset my master (10.2GB > maxtor 7200rpm UDMA66) drive i get ~15-16MB/s and on my slave (same > interface, 20.1GB maxtor 7200rpm UDMA66), i get ~13MB/s. This goes against > logic as the bigger the drive the faster the transferrate should be, and > it's about half of your estimate of Michael's 40GB. Is this due to the > slow disk access of 2.4.0-test10-preX ? Or am i experiencing a bug here? > Both drives are operating at UDMA33 mode Isn't it this a reason ? You are not using UDMA66 > (according to hdparm) and both > drives are set to using 32bit, dma, 16 sector read ahead and 16 sector > multi-access mode. I've posted results i've gotten from bonnie and > bonnie++ before, in all cases, the performance seems to be lacking for the > kind of hardware i have. I have 17-18 MB/sec on my Quantum Fireball 6.4GB (5400 rpm) drive attached to UDMA33 and 14-15 MB/sec on another, also 5400 rpm (guess Samsung) drive. Both in -c1 -d1 -m16 mode. Ah, sorry, this is with ancient 2.2.5 kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
Rik van Riel wrote: > On Mon, 9 Oct 2000, Marco Colombo wrote: > > On Fri, 6 Oct 2000, Rik van Riel wrote: > > > > [...] > > > They are niced because the user thinks them a bit less > > > important. > > > > Please don't, this assumption is quite wrong. I use nice just to > > be 'nice' to other users. I can run my *important* CPU hog > > simulation nice +10 in order to let other people get more CPU > > when the need it. > > In that case the time the process has been running and the > CPU time used will save the process if it's been running for > a long time. > > Please read the /entire/ algorithm before making rash > conclusions like this. > > If nice is used for important, long-running tasks, the fact > that they are long-running will save them (and be honest, > would you really care if a simulation would be killed after > 5 minutes? it's only inconvenient if it gets killed after > a few hours...) Main point is that in many enviroments the niced processes are the ones the system exists for in the first place. I.e they are the most important ones. It would be completely unacceptable, say in research enviroment I know, if my computational job will be killed because somebody launches Netscape or some interactive game. The OS which does this is then will not be considered suitable for research. Niced processes are usually the most complex one organizationally, and quite often are fairly complex to launch (not just click a button on your Gnome panel). Moreover background niced processes by definition are typically run unattended so need to relaunch has yet to be detected. I, for example, typically lauch sequence of simulations simultaniously on 20 Alphas running Linux, which then run for 3-4 days. So yes, I do care that simulations are not killed after 5 minutes. because, first I have to notice this (or write and run monitoring program), second I have to find what was exactly run on this specific machine which was killed and so on. > > > > But if you put the logic "niced == not important" somewhere into > > the kernel, nobody will use nice anymore. I'd rather give a > > bonus to niced processes. > > This doesn't make ANY sense at all. The objective is to destroy > the least amount of work, which means giving a bonus to processes > which have used a lot of CPU time already ... regardless of nice > value. > Well, at the given CPU time spent, the niced process used much more real time than unniced. So the loss in terms of human hours is larger when it is killed. It shows quickly when you have some deadline to meet.Believe it is not pleasant to come in the morning and find the simulations you launched overnight disappeared. The day you planned on spending analysis the output results is gone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Rik van Riel wrote: On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please read the /entire/ algorithm before making rash conclusions like this. If nice is used for important, long-running tasks, the fact that they are long-running will save them (and be honest, would you really care if a simulation would be killed after 5 minutes? it's only inconvenient if it gets killed after a few hours...) Main point is that in many enviroments the niced processes are the ones the system exists for in the first place. I.e they are the most important ones. It would be completely unacceptable, say in research enviroment I know, if my computational job will be killed because somebody launches Netscape or some interactive game. The OS which does this is then will not be considered suitable for research. Niced processes are usually the most complex one organizationally, and quite often are fairly complex to launch (not just click a button on your Gnome panel). Moreover background niced processes by definition are typically run unattended so need to relaunch has yet to be detected. I, for example, typically lauch sequence of simulations simultaniously on 20 Alphas running Linux, which then run for 3-4 days. So yes, I do care that simulations are not killed after 5 minutes. because, first I have to notice this (or write and run monitoring program), second I have to find what was exactly run on this specific machine which was killed and so on. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. Well, at the given CPU time spent, the niced process used much more real time than unniced. So the loss in terms of human hours is larger when it is killed. It shows quickly when you have some deadline to meet.Believe it is not pleasant to come in the morning and find the simulations you launched overnight disappeared. The day you planned on spending analysis the output results is gone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
Matti Aarnio wrote: > On Wed, Sep 20, 2000 at 04:38:45PM +0100, Robert Greimel wrote: > > Hi, > > I am just wondering if linux-kernel-digest is going to come back. > > Greetings > > According to DaveM: No. > (Sometimes he holds possibly bad opinnions as ferociously as Linus, >but on the other hand, that Majordomo 1.x digester breaks structured >MIME messages BADLY. It should be trivial to fix, but I don't hack >Md, I hack ZMailer -- and also sometimes the kernel.) > This is very unfortunate, since linux-kernel-digest was the great way to keep many interested people informed about state of Linux development Without it, > 200 mails daily in linux-kernel is fairly prohibitive if you are not an active developer. Dmitri Pogosyan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
Matti Aarnio wrote: On Wed, Sep 20, 2000 at 04:38:45PM +0100, Robert Greimel wrote: Hi, I am just wondering if linux-kernel-digest is going to come back. Greetings According to DaveM: No. (Sometimes he holds possibly bad opinnions as ferociously as Linus, but on the other hand, that Majordomo 1.x digester breaks structured MIME messages BADLY. It should be trivial to fix, but I don't hack Md, I hack ZMailer -- and also sometimes the kernel.) This is very unfortunate, since linux-kernel-digest was the great way to keep many interested people informed about state of Linux development Without it, 200 mails daily in linux-kernel is fairly prohibitive if you are not an active developer. Dmitri Pogosyan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
