Guest ykk_five Posted August 21, 2010 Report Share Posted August 21, 2010 (edited) details Edited August 21, 2010 by ykk_five Link to comment Share on other sites More sharing options...
Guest ykk_five Posted August 21, 2010 Report Share Posted August 21, 2010 pls read my newly added comments at the 1st page EDITED 21AUG 2018HKT Link to comment Share on other sites More sharing options...
Guest Andrew Luecke Posted August 22, 2010 Report Share Posted August 22, 2010 pls read my newly added comments at the 1st page EDITED 21AUG 2018HKT I said this on the original thread.. But: 1) If the benchmarks are true, it shows that Lag is NOT caused by I/O. I said AGES ago people need to stop jumping to conclusions (and yet, welcome to the internet, where it keeps happening) 2) However, it's a benchmark.. The bigger score might be caused by something basic such as more caching. More analysis is needed in regards to lag and filesystem speed.. Link to comment Share on other sites More sharing options...
Guest ykk_five Posted August 22, 2010 Report Share Posted August 22, 2010 More analysis is needed in regards to lag and filesystem speed.. sorry, i don understand it very clearly (sorry for my bad english, may be i've misunderstandings) yeh, i agree that more analyzes are required for the lag things. but for the filesystem, it should be clear enough that rfs is causing the problem with the way it performs reads/writes. so, i think it's only a matter of which fs to choose from now, and of coz it's a trade offs between safety/stability and performance Link to comment Share on other sites More sharing options...
Guest Andrew Luecke Posted August 22, 2010 Report Share Posted August 22, 2010 (edited) sorry, i don understand it very clearly (sorry for my bad english, may be i've misunderstandings) yeh, i agree that more analyzes are required for the lag things. but for the filesystem, it should be clear enough that rfs is causing the problem with the way it performs reads/writes. so, i think it's only a matter of which fs to choose from now, and of coz it's a trade offs between safety/stability and performance Check the benchmark, it clearly shows that the Galaxy S by default has better I/O than the Nexus One, but the Nexus one has higher CPU. The higher CPU though is possibly because of JIT in 2.2. Either way, it shows I/O is NOT the issue (unless the RFS filesystem is using excessive CPU). But that's assuming benchmarks are accurate, which they aren't... Edited August 22, 2010 by Andrew Luecke Link to comment Share on other sites More sharing options...
Guest DistortedLoop Posted August 22, 2010 Report Share Posted August 22, 2010 (edited) Check the benchmark, it clearly shows that the Galaxy S by default has better I/O than the Nexus One, but the Nexus one has higher CPU. The higher CPU though is possibly because of JIT in 2.2. Either way, it shows I/O is NOT the issue (unless the RFS filesystem is using excessive CPU). But that's assuming benchmarks are accurate, which they aren't... The Nexus One (2.2)'s higher CPU benchmark is obviously from JIT, since the Nexus One without 2.2 is a much lower CPU score, and they're the exact same hardware. The only change there is JIT, isn't it? With that in mind you can argue that the N1's 2.2 is cheating the benchmark for CPU the same way some are arguing that the lag fixes are cheating the i/o benchmarks. But since the benchmarks are always a combination of the OS and the hardware, unless you boot a benchmark only OS, then it's not really cheating, in my opinion, if the fixes you're doing affect daily real-world use of the phone. It's not like we're tweaking video drivers on an PC to score higher on standard benchmark apps; we're making real changes to the time it takes to run a program with JIT, and real changes to the way we read/write data with the lag-fixes. i/o is the issue with the phone, and it is because of RFS. RyanZA finally explained it to me in the xda thread in a way that makes me understand what the real issue is, assuming he's correct! :huh: RFS essentially stops multitasking on i/o the phone when it's writing data: So why does the EXT2 make everything on the phone seem faster? RFS blocks ALL read/writes whenever a write is being done. RFS does zero buffering at all! So if you change your test to doing the following: 5 threads. 4 threads are reading, 1 thread is writing. You will see that whenever the 1 thread is writing anything, the other 4 are starved completely when running on RFS. When running on EXT2, the other 4 threads will be able to read a bit. Edited August 22, 2010 by DistortedLoop Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now