Active Topics
-
Maemo repository (8)
to Community by Maemish - 1 day, 3 hrs ago -
Porting apps to Leste (44)
to Maemo 7 / Leste by norayr - 1 day, 7 hrs ago -
List of well performing apps on Leste (35)
to Maemo 7 / Leste by smatkovi - 4 days, 5 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (13)
to SailfishOS by edp17 - 5 days, 3 hrs ago -
Sailfish OS for the Samsung Galaxy Note 4 (SM-N910C) - (treltexx) (79)
to SailfishOS by edp17 - 5 days, 3 hrs ago -
U-Boot for Nokia RX-51 with BootMenu (updated version 2012.10-rc3-1) (843)
to Alternatives by Arno_11 - 5 days, 8 hrs ago - more...
| The Following User Says Thank You to joerg_rw For This Useful Post: | ||
 |
|
2011-10-21
, 01:54
|
|
Posts: 568 |
Thanked: 969 times |
Joined on Dec 2009
@ Toronto
|
#43
|
On the one hand, I've learned quite a bit reading the to-and-fro in this thread (and others) between individuals who know far more about the subject than I ever will.
On the other hand, my brain told me "hey, there's probably a small-but-acceptable risk!" so I just did it.
Hahahaha!
On the other hand, my brain told me "hey, there's probably a small-but-acceptable risk!" so I just did it.
Hahahaha!
__________________
tinfoilhat.dll: Trojan horse detected
Sailfish want list: calendar bugfixes, glanceable agenda, Swype or similar
Evolution continues (but we're still pre-Cambrian)
Sailfish want list: calendar bugfixes, glanceable agenda, Swype or similar
Evolution continues (but we're still pre-Cambrian)
| The Following 2 Users Say Thank You to shallimus For This Useful Post: | ||
|
|
2011-10-21
, 06:54
|
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#44
|
See, if I agreed with people that I'd probably be using my N900 for a couple years at most, I would totally overclock the **** out of both that I have right now. Here's the problem though - what equally capable device is even remotely on the horizon? No mainstream manufacturer is going to be making anything like it again any time soon that we know of, and the N9 certainly ain't the replacement the power users of the N900 were hoping for.
I started overclocking my first N900 now that I've bought my second one, as my first isn't in a state to be used as my phone anyway. Still uncommitted to overclocking my replacement one though, because honestly, most of the time processing power isn't the cause of slowness on my N900 anyway, it's almost always RAM/swap space needs causing I/O thrashing.
I started overclocking my first N900 now that I've bought my second one, as my first isn't in a state to be used as my phone anyway. Still uncommitted to overclocking my replacement one though, because honestly, most of the time processing power isn't the cause of slowness on my N900 anyway, it's almost always RAM/swap space needs causing I/O thrashing.
| The Following 4 Users Say Thank You to Mentalist Traceur For This Useful Post: | ||
|
|
2011-10-21
, 07:32
|
|
Posts: 1,427 |
Thanked: 2,077 times |
Joined on Aug 2009
@ Sydney
|
#45
|
Originally Posted by Mentalist Traceur
We need to overclock the RAM also.
Still uncommitted to overclocking my replacement one though, because honestly, most of the time processing power isn't the cause of slowness on my N900 anyway, it's almost always RAM/swap space needs causing I/O thrashing.
Jokes aside, yeah, I wish we could just upgrade the RAM on N900 to 1GB of RAM. That would make the N900 just fly.
| The Following User Says Thank You to jakiman For This Useful Post: | ||
|
|
2011-10-21
, 08:28
|
|
Posts: 3,074 |
Thanked: 12,964 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#46
|
Originally Posted by joerg_rw
How are internal flash I/O errors related to EM? Or you are trying to say that it is possible to break flash by OC ARM core? God knows what is the reason for problems of those guys, it could be OC (if they OC at all) if they push their devices above what they can handle, but that is a completely different story.
Sure you can turn off the automatic control of the regulators in twl4030 from SoC via serial line. And I guess that'S what you found in kernel about SR turn-on/off. This is absolutely unrelated though to other aspects of SR, which are implemented inside SoC and not at all controllable.
/j
[edit]
I stopped to ask them. Just I really dunno where from others here in this thread get their figures about the percentage number of OC'd devices, not to mention the % of OC'd with problems so far.
<quote #maemo>
[2011-10-21 01:57:16] <UberNeo> Guys .. I have teh problem with my mmcblk0p2 on N900 .. as mentioned in the post .. http://talk.maemo.org/showthread.php?t=50506 please help as i have followed that post but nothing works
[2011-10-21 01:57:31] <UberNeo> its getting restarted .. again n again ...
[2011-10-21 01:57:55] <UberNeo> dmesg shows lots of errors for mmcblk0
...
[2011-10-21 03:52:47] <ultra420> my N900 get errors,dmesg shows lots of : "end_request: I/O error, dev mmcblk0, sector 59312105"..and it will crash, boot loops without boot success ,i have flashed at least 30 times i thought...any help plz?
</quote>
(dunno why the nicks and diction make me think I already know the answer when I would ask "did you OC?")
[/edit]
Are you sure about SR? I would really appreciate if you point where it is stated in documentation. Because what we have in n900 kernel is software SR , where it is all up to kernel to decide about OPPs and such. Real SR (i.e. level 3) is not implemented in kernel. And real SR uses efuse calibration values, which noone cares about in n900 kernel(AFAIK). How will you explain the fact that in official TI documentation there is a formula to calculate nvalue (that is SR calibration) for 720/800MHz speeds? Yeah they say that is overdrive frequency, and it is only for ES3.1.2 and 3530 which are marked as 720MHz capable, but tell me, do you really think we have new die in those? I don't believe we have, it is all marketing bu||****. And being an engineer ( I am too) you know that taking responsibility in official documentation is something engineers hate more than promising deadlines and writing documentation
. BTW in TI documentation lifespan is given with SR turned off. Anyway, as soon as my DSP driver saga ends I will try to backport SR driver from harmattan, as it seems that SR (when implemented as it should) will have tremendous effect on battery life. And will propose to pali to limit max OC frequency to 800/900 with SR always turned on. But that is offtopic here.
| The Following User Says Thank You to freemangordon For This Useful Post: | ||
|
|
2011-10-21
, 10:28
|
|
Posts: 1,033 |
Thanked: 1,013 times |
Joined on Jan 2010
|
#47
|
I knew I read this somewhere which proves my point:
http://www.droidforums.net/forum/dro...tml#post117541
EDIT: 3430 chips capable of running at 800MHz stable are sold as 3440.
Last edited by patlak; 2011-10-21 at 18:31.
http://www.droidforums.net/forum/dro...tml#post117541
EDIT: 3430 chips capable of running at 800MHz stable are sold as 3440.
Last edited by patlak; 2011-10-21 at 18:31.
 |
|
2011-10-21
, 12:17
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#48
|
Originally Posted by freemangordon
Well, not sure about eMMC, but for sure the interface in OMAP may suffer from EM.
How are internal flash I/O errors related to EM? Or you are trying to say that it is possible to break flash by OC ARM core? God knows what is the reason for problems of those guys, it could be OC (if they OC at all) if they push their devices above what they can handle, but that is a completely different story.
Originally Posted by freemangordon
About SR being a bunch of loosely or not related different measures, yes I'm rather sure. As I am about the regulation of working point. Alas I can't really tell where in the several dozen of documents with up to 4000 pages from TI I found it all, anyway it's not all in one place, you have to collect the pieces from press releases, marketing papers, and of course white papers and user manuals/DS. Here's just one link I see in my bookmarks tagged "SmartReflex" http://focus.ti.com/general/docs/wtb...contentId=4609, to give you a good kickoff about all the SR stuff.
Are you sure about SR? I would really appreciate if you point where it is stated in documentation.
Originally Posted by freemangordon
Well, "real SR" doesn't need much of any kernel implementation, apart from enabling it, which is what I thought these sysnodes do. AIUI SR auto-regulator-control was disabled in PR1.0..1.1.1 at least, as it been considered unstable, which is easily understood seeing what this detail of SR does: rapid change in Vcore and other voltages regulated in twl4030 GAIA and then provided to OMAP SoC. If some detail of PCB layout, buffer capacitors and their ESR etc, whatnot else, is not like TI specified it or just thought was implicitly obvious, then you can easily figure how enabling SR auto VDD regulation can cause CPU instability or even slow damage (by introducing short overvoltage when SR regulates down but buffer capacitors store up the higher VDD for too long).
Because what we have in n900 kernel is software SR , where it is all up to kernel to decide about OPPs and such. Real SR (i.e. level 3) is not implemented in kernel. And real SR uses efuse calibration values, which noone cares about in n900 kernel(AFAIK). How will you explain the fact that in official TI documentation there is a formula to calculate nvalue (that is SR calibration) for 720/800MHz speeds? Yeah they say that is overdrive frequency, and it is only for ES3.1.2 and 3530 which are marked as 720MHz capable, but tell me, do you really think we have new die in those? I don't believe we have, it is all marketing bu||****. And being an engineer ( I am too) you know that taking responsibility in official documentation is something engineers hate more than promising deadlines and writing documentation
For the "new die" I for sure don't think they created a set of completely new chip masks, but a few small changes in mask, process, QA and of course different bins in selection at end of QA will nevertheless cause the products shipped to differ in some of their properties.
And now I'll stop contributing here, as it's pretty obvious that a lot of posters here (not you though) refuse to understand the true implications of statistical QA and lifetime warranty, just seem to feel embarrassed or insulted when more savvy users try to explain about it, about Gauss' distribution and random variations in even same wafer of chips etc pp, all the time argue by pulling random numbers outa their a*** while same time accusing me to do exactly that when I quote TI datasheets, and generally don't like to adhere to any of http://fun.sdinet.de/pics/english/co...-flowchart.jpg (404 when you click here. Create bookmark for it and open it in new window).
Anybody who wants to see will see how their statements "OC is safe!!1!11 I'm doing it since months now!" are based on poor knowledge and ignorance, and those who don't want to see are going to do whatever they want to do anyway and are not really interested in the true implications of OC regarding lifespan and reliability. So I suggest you slightly switch topic here to define and debate about definition of "safe" while I follow more promising things than this thread.
/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2011-10-21 at 12:28.
| The Following 4 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2011-10-21
, 13:01
|
|
Posts: 1,225 |
Thanked: 1,905 times |
Joined on Feb 2011
@ Quezon City, Philippines
|
#49
|
Originally Posted by jakiman
That would be easy-peasy, if the RAM wasn't POP.
We need to overclock the RAM also.
Jokes aside, yeah, I wish we could just upgrade the RAM on N900 to 1GB of RAM. That would make the N900 just fly.
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
|
|
2011-10-21
, 14:35
|
|
Posts: 3,074 |
Thanked: 12,964 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#50
|
@joerg_rw: I think the document here will be an interesting reading for you, especialy this part:
Because AFAIK this is the SmartReflex type that is implemented in n900 kernel. And AIUI by setting sr_vddX to zero, we disable the part "the new voltage command to be send...", thus leaving OPP voltage constant.
And maybe while reading through this document you will finally get the fact that there are no magical voltage regulators/level shifters at every transistor gate/drain/source, just good old negative feedback :P and several power domains.
TBH I don't get it why you are leaving this conversation, but anyway it is your right to choose so. I will just ask you to look at the above document (when you have time free from more promising things) and to make a post here if you have feeling that maybe your statements so far were wrong.
1.1.5.1 Manual SmartReflex Voltage Control
In manual voltage control, the SmartReflex module interrupts the MPU when the voltage level crosses the
defined voltage limits (minimum/maximum). The MPU reads the error value and determines the new
voltage command to be sent to the SMPS to return the voltage to within the limits. The new voltage
command is sent to the voltage controller, which passes the command to the SMPS and acknowledges its reception.
And maybe while reading through this document you will finally get the fact that there are no magical voltage regulators/level shifters at every transistor gate/drain/source, just good old negative feedback :P and several power domains.
TBH I don't get it why you are leaving this conversation, but anyway it is your right to choose so. I will just ask you to look at the above document (when you have time free from more promising things) and to make a post here if you have feeling that maybe your statements so far were wrong.
| The Following User Says Thank You to freemangordon For This Useful Post: | ||
/j
[edit]
I stopped to ask them. Just I really dunno where from others here in this thread get their figures about the percentage number of OC'd devices, not to mention the % of OC'd with problems so far.
<quote #maemo>
[2011-10-21 01:57:16] <UberNeo> Guys .. I have teh problem with my mmcblk0p2 on N900 .. as mentioned in the post .. http://talk.maemo.org/showthread.php?t=50506 please help as i have followed that post but nothing works
[2011-10-21 01:57:31] <UberNeo> its getting restarted .. again n again ...
[2011-10-21 01:57:55] <UberNeo> dmesg shows lots of errors for mmcblk0
...
[2011-10-21 03:52:47] <ultra420> my N900 get errors,dmesg shows lots of : "end_request: I/O error, dev mmcblk0, sector 59312105"..and it will crash, boot loops without boot success ,i have flashed at least 30 times i thought...any help plz?
</quote>
(dunno why the nicks and diction make me think I already know the answer when I would ask "did you OC?")
[/edit]
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2011-10-21 at 03:10.