On 18.08.2007 01:43, Marek Artur Penther wrote:
I think there, about support for every clock chip (like l9248). I think this will help to overclock and/or underclock and/or for (most important) properly set speed of CPU and FSB and PCI and AGP. If you have any trouble in find datasheets about clock chips I know few web sites where anyone can download datasheets for free.
Do you offer to write some code? Back in 2005, we had some code to over-/underclock hypertransport links. That code has been dropped, though.
Even if some new code for overclocking will be written, there is still the question whether we want such code in LinuxBIOS. Usually people blame the stuff which gives them the ability to shoot themselves in the foot. I don't want people blaming LinuxBIOS because it allowed them to overclock their machines until the hardware failed.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 18.08.2007 01:43, Marek Artur Penther wrote:
I think there, about support for every clock chip (like l9248). I think this will help to overclock and/or underclock and/or for (most important) properly set speed of CPU and FSB and PCI and AGP. If you have any trouble in find datasheets about clock chips I know few web sites where anyone can download datasheets for free.
Do you offer to write some code? Back in 2005, we had some code to over-/underclock hypertransport links. That code has been dropped, though.
Even if some new code for overclocking will be written, there is still the question whether we want such code in LinuxBIOS. Usually people blame the stuff which gives them the ability to shoot themselves in the foot. I don't want people blaming LinuxBIOS because it allowed them to overclock their machines until the hardware failed.
Yeah, agree with that ;-). It shouldn't be given to the unknowns.
But, what about an "overclocking/underclocking branch" for LinuxBIOS? I mean maybe someone interested to maintain such a branch of LinuxBIOS? Only, a naive idea though ;-).
Regards, Darmawan
On 18.08.2007 04:55, Darmawan Salihun wrote:
Carl-Daniel Hailfinger wrote:
On 18.08.2007 01:43, Marek Artur Penther wrote:
I think there, about support for every clock chip (like l9248). I think this will help to overclock and/or underclock and/or for (most important) properly set speed of CPU and FSB and PCI and AGP. If you have any trouble in find datasheets about clock chips I know few web sites where anyone can download datasheets for free.
Do you offer to write some code? Back in 2005, we had some code to over-/underclock hypertransport links. That code has been dropped, though.
Even if some new code for overclocking will be written, there is still the question whether we want such code in LinuxBIOS. Usually people blame the stuff which gives them the ability to shoot themselves in the foot. I don't want people blaming LinuxBIOS because it allowed them to overclock their machines until the hardware failed.
Yeah, agree with that ;-). It shouldn't be given to the unknowns.
But, what about an "overclocking/underclocking branch" for LinuxBIOS? I mean maybe someone interested to maintain such a branch of LinuxBIOS? Only, a naive idea though ;-).
Please call the branch/fork UnreliableBIOS :-P
Regards, Carl-Daniel
* Darmawan Salihun darmawan.salihun@gmail.com [070818 04:55]:
But, what about an "overclocking/underclocking branch" for LinuxBIOS? I mean maybe someone interested to maintain such a branch of LinuxBIOS? Only, a naive idea though ;-).
I think that is a nice idea. Any takers?
On Sat, Aug 18, 2007 at 11:21:22AM +0200, Stefan Reinauer wrote:
The value of overclocking is very questionable
It has huge educational value, which is why I think it's important that LB can do it. ..or maybe not..
On Sat, Aug 18, 2007 at 09:55:02AM +0700, Darmawan Salihun wrote:
Yeah, agree with that ;-). It shouldn't be given to the unknowns.
I disagree. Let user shoot self in foot. Maybe politely warn though.
But, what about an "overclocking/underclocking branch" for LinuxBIOS?
My idea is that these tweaks are contained in a separate piece of software. Maybe lbmenu. There's a certain point in letting LB stay LB and just do a very safe, always known-working setup. Then add fancy schmancy on top of that.
This is also important because we may like to have fallback use different performance profiles. Easily done with tweaks in a payload.
//Peter
* Peter Stuge peter@stuge.se [070818 11:42]:
But, what about an "overclocking/underclocking branch" for LinuxBIOS?
My idea is that these tweaks are contained in a separate piece of software. Maybe lbmenu. There's a certain point in letting LB stay LB and just do a very safe, always known-working setup. Then add fancy schmancy on top of that.
The main code needs to support the fact that it's values are overwritten at some point.
For example, HT speed only gets active when you do a reset (or LDTSTOP). Imagine lbmenu overclocks the HT bus and does a reset. LinuxBIOS will see the reset and see that it would run he HT bus with different values. It'll change the values and.... do a reset.
This is also important because we may like to have fallback use different performance profiles. Easily done with tweaks in a payload.
This means lbmenu would get another task: Setting the HW up according to its settings. This requires a lot of HW knowledge per board within lbmenu.
I like the idea of capsulating this functionality. I am not sure whether lbmenu is the right place for the magic. (definitely for the visualization!)
Stefan
is setting memory timings considered overclocking, too? for all memory modules before sdram the user should be able to alter those settings because those modules do not have spd.
the clock chips sit on top of the smbus and it should be simple to program them to whatever the user thinks he needs (and the chip supports).
there are so many options that may (positivly) influence performance on chipsets in general. i don't see the point why LB should hide them. to be honest that is why i started developing for LB in the first place. there are so many ugly bios implementations for older boards that make chipset and mainboard unusably slow (have a look at pcchips boards). i will include performance options in all my drivers. if they are not user adjustable i would have to enforce them. i don't think that telling the user to read the source code and uncomment some performance options is a real solution. who wants/can to read the source code anyway?
i agree that all those options should be in an 'expert' menu and a warning should be shown on entering it, but that's all. every single option should be there. i think that we as the programmers should know best but the user should still be able to know better.
since we have the datasheets and the programming skills to adjust (almost) anything on the supported chipsets we should share it. this is not a risk, it is a feature! if anyone really needs links to performance gains beyond the 10% mark i'll post some on the mailing list.
* popkonserve popkonserve@gmx.de [070818 12:19]:
user adjustable i would have to enforce them. i don't think that telling the user to read the source code and uncomment some performance options is a real solution. who wants/can to read the source code anyway?
Basically those people who understand what those options are for. I doubt anyone who knows that is unable to read a config file.
The question is: Why would you set your system up in a non-optimal way in the first place.
If a setting is possible, stable and performance-improving, lets always set it. If not, it is no good?
since we have the datasheets and the programming skills to adjust (almost) anything on the supported chipsets we should share it. this is not a risk, it is a feature! if anyone really needs links to performance gains beyond the 10% mark i'll post some on the mailing list.
I do agree here. Please do post those links, if possible.
Stefan
user adjustable i would have to enforce them. i don't think that telling the user to read the source code and uncomment some performance options is a real solution. who wants/can to read the source code anyway?
Basically those people who understand what those options are for. I doubt anyone who knows that is unable to read a config file.
people knowing chipset options are not necessarily programmers. a menu like the current bios implementations offer would be nice to have.
The question is: Why would you set your system up in a non-optimal way in the first place.
because there are chipset options that shouldn't be set according to the manufacturer but they do have in fact an impact on performance. the best example are ALi chipsets: if you leave everything unconfigured the chipset will be dead slow. if you set everything to optimal performance some (pci) devices could run into problems. the user should have at least the options to flip some bits if something isn't working correctly.
If a setting is possible, stable and performance-improving, lets always set it. If not, it is no good?
agree! i wish the chipset manufacturers would have written those information in their chipset documentation. that would make things so much easier. i guess the main reason why they made those options adjustable is the fact that there is so much different hardware out there that cling to different (more or less officical) specifications. that makes it almost impossible to find the optimal setting for every possible combination.
I do agree here. Please do post those links, if possible.
celeron 600@1008 (by cranking up the fsb from 66 to 112MHz): http://www.thetechzone.com/reviews/cpu/oc_warehouse1000/page3.shtml
ram interleaving on VIA chipsets: http://www.georgebreese.com/net/software/readmes/venabler_v015_readme.htm http://www.overclockers.com/tips105/index03.asp
register tweaking the Intel BX chipset: http://www.overclockers.com/tips607/index03.asp
register tweaking a PcChips mainboard with SIS chipset: http://m571.com/m571/tweek.htm
power saving (not performance, but still useful): http://members.jcom.home.ne.jp/jacobi/linux/softwares.html#athcool
enable UDMA on a PcChips mainboard: http://www.rainbow-software.org/hardware/m726tune.html
and there are so many more..i didn't find anything on PCI performance benchmarks but some tweaks modify pci performance registers, too. i should definately do some tests on a pcchips board regarding pci performance.. Holger
On Sat, Aug 18, 2007 at 02:29:27PM +0200, popkonserve wrote:
a menu like the current bios implementations offer would be nice to have.
I disagree. I want something much better. Me and Uwe share this idea about a (tree?) view of the complete system, where the user is free to change every single adjustable setting.
Yes, it needs some work.
//Peter
Peter Stuge wrote:
I disagree. I want something much better. Me and Uwe share this idea about a (tree?) view of the complete system, where the user is free to change every single adjustable setting.
That's the kind of menu i thought of :) but changing every adjustable setting could mean overclocking or should we say running the hardware out of specs (which specs exactly?). anyway i think this is the way to go. full control for the user.
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070818 04:49]:
Even if some new code for overclocking will be written, there is still the question whether we want such code in LinuxBIOS. Usually people blame the stuff which gives them the ability to shoot themselves in the foot. I don't want people blaming LinuxBIOS because it allowed them to overclock their machines until the hardware failed.
One thing I am concerned is that adding all the hooks for overclocking snafus the algorithms we implemented to do things in a "optimal but not overclocking" way.
If people come up with patches that allow overclocking without making the code hard to understand and follow, I would vote for it to go into the tree.
The value of overclocking is very questionable in times where hardware is so fast and cheap and has so little scope left for gains. This was way different back when you could overclock a 68000 from 8 to 28 MHz and just add passive cooling. Or wire your 68882 from 25 to 50MHz. Nowadays you sit for quite some hours before you get a half ways stable setup which gives you a speed gain of 10%. If some master overclocker can prove me wrong, please do :-)
Stefan
-
Carl-Daniel Hailfinger -
Darmawan Salihun -
Marek Artur Penther -
Peter Stuge -
popkonserve -
Stefan Reinauer