yashsingh1/xdaforums huggingface dataset:
[Pixel C Android Development] cheep5k8:
OK, so these are the results with CPU governor set to performance on v1-release, with no other tweaks:

integer multicore: 4989 (ars reference: 5760)

fp multicore: 3942 (ars reference: 4393)

mem multicore: 1292 (ars reference: 2098)

antutu: 92453

It hints towards the problem being memory throughput, and since I made some recent changes there, I'm gonna take a look at the relevant code again.

(Primary concern for me was stability and I had zero reboots or other issues with v1-release so far, not even the very rare reboots that occur on the stock kernel.)

EDIT: No huge improvement, especially in mem department, when partially reverting some of the memory-related changes. I'll examine the kernel build config next.
[Pixel C Android Development] DaConcho:
Flashed the RC4 last night and while I was sitting there with tablet next to me I kept hearing the dreaded beep that meant my tablet had just rebooted. Went and flashed V1 and ended up still getting the same amount of reboots.

http://i.imgur.com/BjP15s4.png

I was previously on the 1-29 v2 kernel and had no issues. Anyways, just an fyi. Not really concerned about it but just to let you know.
[Pixel C Android Development] Boal:
Unrelated question, but how do you enable this dark mode in your screenshot?
[Pixel C Android Development] DaConcho:
Layers manager.

Its the Inversion UI Layer.
[Pixel C Android Development] cheep5k8:
Thought I let you guys know that the V2 kernel fixes all software-side issues with the WiFi. The fix is still trickling up to Google, but it will take who knows how long until they fix it officially. All remaining issues should be, if any, hardware related (i.e. metal casing, etc.)

Cheers
[Pixel C Android Development] cheep5k8:
The Pixel C is really a bit prone to spontaneous reboots :eek:

With the V2 kernel (which I just released) I personally had zero reboots.

You can do one thing that would be immensely helpful, should it reboot again:

When it "just" reboots, let it boot up again. Then quickly use some kind of root-enabled file explorer, copy all files from /sys/fs/pstore/ and post them somewhere. Those files contain logs from the previous boot (and run) of the tablet. They're about the only thing that can realistically help me find out what the problem was.

This goes for everyone else still having reboots as well :p These logs are worth their file size in gold to me for debugging issues.
[Pixel C Android Development] HMkX2:
What does this mean? Does this improve the range problem or speed in general?

Does this mean it was a software problem and not the keyboard?
[Pixel C Android Development] cheep5k8:
There were multiple issues, and perhaps still hardware issues remain. One of the problems was out of order IP packets which required a lot of retransmits of data and generally caused havoc in the TCP/IP protocol. I was able to fix that.

Answering every question in detail would take a lot of time, but as it is, I can max out my Internet connection at 100Mbit/s even at the far end of the apartment, whereas previously I would get around 6Mbit/s download speeds.

EDIT: I understand there are many questions now, but like I've said, addressing those will take substantial time and just right now is not the right moment. I will make an upcoming post with explanations.
[Pixel C Android Development] xennos:
Take you time Cheep :)

Thanks you for your hard work.

RMA normally today I ask because it's too much expectation and my pixel is in its box ..

But hope now.

( sorry for my English )
[Pixel C Android Development] TJR48:
I ran quite a few iPerf tests on the download and upload bit rates. I also obtained a USB-C network adaptor in order to test the wired bit rate. The upload speed averaged 926 Mb/s but the download speed was only about 350 Mb/s--quite a difference! Are your fixes likely to correct this too?
[Pixel C Android Development] Boal:
I'm glad to hear that. It does look much better when using the Speedtest.net app. Unfortunately, the bandwidth monitor in apps like System Monitor is broken. Can you confirm?

If so, could it be that some flag in the kernel compile options necessary for this has simply been disabled? I ask because I remember having to compile my own kernel when I wanted to debug an IO issue on my phone and the default kernel doesn't come with support for iotop. Maybe the same happens now?
[Pixel C Android Development] cheep5k8:
OK so since I don't see this stopping without giving a statement, here's what happened. I'll explain the best and spare you the rest :p

(This will probably only make sense to people who know kernel development, but I really don't feel like writing a full Explain-Like-I'm-5 description right now)

Initially I merged a few patches to net and bcmdhd, as well as mmc since we suspected that the SDIO interface might be at fault. Nothing really drastically improved; I was able to improve reception but the out of order packets stayed.

A few days ago I then had another idea.

Nvidia has published a Tegra X1 reference kernel source on their developers website. Just out of f***, I thought to myself, what if I tried to port the bcmdhd driver from that source?

I transplanted it into the dragon kernel, fixed it up so it compiled and worked properly, and the out of order packets were gone.

I'm not claiming I really fixed anything specifically. I only ported the driver. What exactly is at fault remains to be determined now that the bcmdhd driver from the chromeos-3.18 kernel seems to be the culprit, and hopefully (maybe?) this serves as a starting point to the Google engineers, unless they are already well underway with an actual specific fix, but so far no information about this is known to anyone, not even to my Google-contact-across-N-degrees-of-separation.

I hope this is a satisfactory statement for now because now I need to take care of something rather important (my girlfriend's dad died unexpectedly this morning in the hospital; I hope you all will understand if I have to attend to other matters for the moment)
[Pixel C Android Development] Boal:
Jeez, man. My condolences. I'm sure everyone here understands if you have other things to do right now.
[Pixel C Android Development] xennos:
Condolences :(

Take you time.

Cheers buddy n
[Pixel C Android Development] HMkX2:
Take all the time you need. We are grateful for your work. Family comes first.

It doesn't say much over the internet but we are people too and grieve for your loss.
[Pixel C Android Development] bill3508:
Sorry for your loss and thanks for all your hard work.
[Pixel C Android Development] r_nation:
Sending my condolences bro, very sorry to hear.
[Pixel C Android Development] JimTDI:
My sincere condolences - take care of your family - very sorry for your loss.

Thank you for your work on the C, we're fortunate to have your contributions to the community!
[Pixel C Android Development] beardymcgee:
Really sorry to hear about your loss, you really are doing great work and our tiny community owes you alot.
[Pixel C Android Development] Sergio3.14:
Has anyone tried the new kernel? It would be great to know if the problems are solved
[Pixel C Android Development] brando56894:
A lot of us have, what problems are you referring to?
[Pixel C Android Development] Sergio3.14:
The wifi problems that cheep5k8 claimed to have solved (or at least improved) in the last version
[Pixel C Android Development] cheep5k8:
Just a quick note from me in between: I would also be very interested in getting some feedback on that.

And thanks everyone for the kind words, it's very appreciated.
[Pixel C Android Development] Boal:
I didn't do any proper scientific tests, but it seems to have improved substantially, both speed and reliability. Now it's at least as good as the WiFi performance of my 2011 Macbook Pro. Well, at least in my office where I only have very bad WiFi reception, i.e. adverse conditions. At home I now max out my 50 Mbps connection, but my apartment isn't big enough to really have connection problems anyway.

Good job.
[Pixel C Android Development] spybyscript:
The Pixel C on your latest build is matching up with my iPad on speed tests and wifi in general seems much more stable.

However (and this is the case on almost all the builds that aren't stock with no encrypt-root) I get a random reboot every 30-60m of use. In particular this happens if I'm using chrome or have a video playing (youtube/netflix/plex all typically reboot before a full length show/movie finishes).

This reboot doesn't occur at all if I'm on stock or the basic no-encrypt boot images.
[Pixel C Android Development] cheep5k8:
I tried to nail down the reboots, so far my Pixel C is stable at 60+ hours uptime (also with Chrome, etc.)

If this happens again it would be most valuable if you could save the files from /sys/fs/pstore/ and somehow upload them or send them to me. They contain the kernel log messages up to and including the crash. (This must be done just when the Pixel has booted up again after a crash as the logs are saved in a special region of the RAM and thus volatile).

Since my Pixel is stable I basically need these logs in order to find issues still present.
[Pixel C Android Development] Avencore:
On the latest build V2 WIFI seems a bit more stable for me but still performs far worse than my Galaxy S6 edge+ and it is close to unsuable.

How can I provide you with some valueable information?

I also noticed, that the download speed degrades quickly after a reconnect. It is usable for approx 1 minute after a reconnect and goes back to a speed under 50kbps on a 30mbit connection.

Gesendet von meinem Pixel C mit Tapatalk
[Pixel C Android Development] cheep5k8:
Does your router have an admin console? Can you check there how exactly the Pixel is connected (link rate, and whether it connects with 802.11g/n or 802.11ac)?

You can also find out the link rate with Google's device assistant app:. https://play.google.com/store/apps/details?id=com.google.android.apps.cavalry

EDIT: Also interesting would be to know your version of the bootloader
[Pixel C Android Development] Avencore:
It is not my router so I am not able to connect to the admin console. In the app it states that my Pixel is connected via 144Mbps. And it is a 2.4ghz signal. Also the signal strengh is about the same as on my phone.

Bootloader version: 7132.260.0

HW Version: 5

Not sure if that is of any help.

Gesendet von meinem Pixel C mit Tapatalk
[Pixel C Android Development] nbpf:
I do not have a Pixel C at the moment, I have sent mine back at the beginning of the week. During the time I had the device, I have ran a number of tests all confirming poor wireless performance in comparison with a three years old iPad mini.

The last experiments I did before sending back the device, seemed to indicate that the signal strength of the Pixel C was significantly deteriorating at wake up. Here is a copy of the observations I posted on the Nexus Help Forum. The Pixel C was connected to a FritzBox 7490 on the 5GHz band in ac. The iPad was connected to the same FritzBox also on the 5GHz band but in n+a mode.

... when sleeping side by side, the signal strengths of the Pixel C and of the old iPad mini (router readings) are pretty much the same

Pixel C: -72 dBm

iPad: -74 dBm

Waking up the devices and starting iperf3 -s on both very much worsens the signal strenght of the Pixel C. In contrast, the signal strenght of the old iPad significantly improves:

Pixel C: -80 dBm

iPad: -65 dBm

Putting a smart cover on both devices and waiting a few minutes makes both the Pixel C and the iPad mini go back to their original (and pretty much comparable) sleeping readings:

Pixel C: -72 dBm

iPad: -74 dBm

I have reapeated the above cycle a few times and each time observed the same behavior (with, say, +/- 2 dBm variability): waking up the devices yields better readings for the iPad and worse readings for the Pixel C, starting iperf on both devices and running some tests makes the iPad readings further improve and further worsens the Pixel C readings, ..., etc.

The bottom line is that there appear to be system processes (I had no applications running in the background on the Pixel C, just system tasks or system tasks + iperf3) that have a significant (negative) impact on the wireless performance.

Also, all jitter measurements showed values for the Pixel C which were 5 to 20 times higher than the corresponding values for the old iPad. I have measured iperf3 download transfer rates between 20 Mbits/sec and 230 Mbits/sec depending on the distance from the router. In all measurements except for those where both the Pixel C and the iPad were very near to the router, the bandwidth figures for the Pixel C were consistently lower than the bandwidth values of the iPad.
[Pixel C Android Development] DaConcho:
I was still getting a ton of reboots on the V2 release as well. I tried to pull the files that cheep was looking for but everytime the folder was empty. I did dirty flash the monthly security update though and had xposed installed so I decided to clean flash the feb factory image and reroot everything. So far not a single reboot, and everything is working flawlessly.

May want to consider that?
[Pixel C Android Development] beardymcgee:
ive never had any reboots since i mistakenly flashed the forced encryption boot img by mistake and ended up clearing and starting fresh stock T also did bootloader so that could be more evidence to support this
[Pixel C Android Development] acrickie:
I can't really compare WiFi performance on the updated kernels until the weekend as I did most of my testing at home and I work away during the week.

I know I did have a problem especially with 2.4G radio, 5G connected and worked better, which I know it should not really do as 2.4G theoretically has better range. I can check this at the w/e and see if it is better.

One thing I did notice with v2 kernel, I was getting video/audio breakup using MX Player to play locally stored MP4 video files.

This only happened after updating to the v2 kernel, I reverted back to v1 kernel and it stopped happening.

I realise this is not exactly a deeply scientific test and it does not necessarily mean the kernel is causing the issue - but it is something to consider. For me video playback is one of the most important things, today I will install the V3 kernel to see if that has the same video issue.
[Pixel C Android Development] Avencore:
With Version 3 RC3 WIFI for me seems to be much better than with V2. Where I could get only 20kbits before I now get 230kbits on average. I noticed that while conducting a speedtest my Pixel can achieve speeds up to 7-8 mbits constantly but only for the first 3-5 seconds of the test. After that it falls back to approx. 200kbits as if some buffer was full or something needed a cleanup. When starting another test after a break of 1 minute I can observe the same behaviour. Conducting the same test with my phone I get around 10mbit but constantly during the whole test.

UPDATE: It seems like, disabling ipv6 support on the Pixel, fixed the above mentioned issue. I am now able to get constantly 8-10mbit through my pixel even beating my phone sometimes. Lets see if it stays like this.

In the meantime, thanks for your amazing work for our device.

Gesendet von meinem Pixel C mit Tapatalk
[Pixel C Android Development] bill3508:
I'm not having any reboots still running decrypted with these kernels. In think I may have had just one since you released your first one.
[Pixel C Android Development] #Baptiste:
I have a problem with RC2: my tablet frequently loses connection to WiFi...
[Pixel C Android Development] acrickie:
OK - I updated to the v3-RC3 kernel yesterday, ran fine all day without any issues but when I watched MP4 files on MX Player again last night I still got some video and audio breakup at random points - as far as I can remember there is nothing else I have changed - to recap:

Mon - kernel v1-release - no video breakup - approx 2 hours of video.

Tue - kernel v2-release - random video and audio breakup - approx 1 hour of video.

Wed - kernel v1-release - no video breakup - approx 2 hours of video.

Thu - kernel v3-RC3 - random video and audio breakup - approx 2 hours of video.
[Pixel C Android Development] cheep5k8:
Hey,

Could you explain what you mean by "breakup"? I really have no clue what that is supposed to mean. Not sure what I'm looking into.
[Pixel C Android Development] Avencore:
I also observed the reboots during youtube video playback. They occur almost every 10 minutes of video playback. I sent you the logs via pm.
[Pixel C Android Development] cheep5k8:
The logs got somehow corrupted, they're almost impossible to read. Did you process the files in any way before uploading?
[Pixel C Android Development] Avencore:
No I just copied them via Root explorer to another folder and uploaded them to Drive via the Drive app.

Which one of the two files is the important one for you?

These are the lines before the crash:

[ 2473.817827] tegra-mc 70019000.memory-controller: display0c: read [MENTION=3314829]0x00000000[/MENTION]16100000: unknown (SMMU translation error [--S])

[ 2473.817945] tegra-mc 70019000.memory-controller: display0c: read [MENTION=3314829]0x00000000[/MENTION]16100000: (SMMU translation error [--S])

[ 2473.818040] tegra-mc 70019000.memory-controller: display0c: read [MENTION=3314829]0x00000000[/MENTION]16100000: (SMMU translation error [--S])

UPDATE: had another crash during youtube and uploaded the logs to the same drive folder/new. Hopefully these are readable.
[Pixel C Android Development] acrickie:
At random intervals during playback the screen goes black and the sound starts crackling, the picture then starts to come back but takes a few seconds before all artefacts disappear.

It is almost like you are watching digital TV and get a brief signal interruption.

I obviously understand this may be a little difficult to nail down - but as I said, it doesn't happen on the V1-release kernel.

I will try "youtube" later to see if I get reboots, can't really check that while I am at work........

If there is any other testing I can do, let me know.

Thanks
[Pixel C Android Development] r_nation:
I've only had one reboot with ALL kernels which was new V2 release while using MX player but didn't get to files in time to report..will test V3 this weekend, as seems to be a video playback issue(at least with me)

---------- Post added at 09:31 AM ---------- Previous post was at 09:28 AM ----------

Ooops, misread..will test V2 on video playback more extensively this weekend.
[Pixel C Android Development] ZiggSVO:
nevermind brain fart :p
[Pixel C Android Development] acrickie:
OK an update from me on WiFi and "video breakup" from testing at home.

Firstly video breakup - now on V3-RC4.

I have been using the "Advanced interactive governer tweaks" from this post http://xdaforums.com/pixel-c/general/reuse-advanced-interactive-governor-t3297783

I noticed that although I set the min CPU speed to 51MHz, this does not stick after a reboot, (using EX Kernel Manager), it only gets applied after you open the App and go into the CPU page. This means on my Pixel at least, it is a bit random whether this is set - depending on whether I remember to go into that page after rebooting.

Having done some further, albeit very short tests, I think it may be related to setting the minimum CPU speed.

I have not tested with all other kernel versions I only tested with V3-RC4 but with CPU minimum set to 51MHz, I could reproduce video breakup when watching MP4 files with MX Player. After setting back to 204MHz (the default I believe), I did not seem to get them. I should caution that this is not conclusive, as I only watched about 10 minutes or so of video but I will keep an eye on it and see what happens.

For WiFi, I have to admit, that in MY normal use, I have not seen any issues, I have used my Pixel without any obvious problems, at home, in 2 different hotels and at 2 different offices. Admittedly I do not stream video and am not trying to suggest there is no problem, but for my usage pattern, I have not seen any issues.

The only real testing I have done is at home using the Ookla Speedtest App.

My WiFi router is an Asus RT-AC68U running the latest Merlin WRT firmware and has both 2.4G and 5G radios. My house is a very old terrace with thick walls, the router is installed on the ground floor in a small wooden cupboard. There are no other visible WiFi networks on the same frequency in the 2.4G or 5G bands.

I use the 5G band as far as possible and am able to pretty much max out my 40/20M broadband connection from the 2nd floor.

The 2.4G is a different story. Previous test with this gave download speeds of less the 1M and upload speeds of around 5M. I also found I was unable to browse to web pages - effectively making 2.4G unusable from the 2nd floor at least.

With the latest kernel, the speedtest gave me 2.63 download and 6.40 upload, I can now browse web pages. I also tried live TV streaming at HD speed from my Raspberry Pi, which has a USB digital TV adapter, that seemed to work fine although there were a couple of breakups, suggesting I was hitting some bandwidth problems. I also tried watching 1080p YouTube videos, which seemed to work OK.

So there seems to be some improvement in the 2.4G, however theoretically 2.4G should have better coverage than 5G and as I still get much better performance from the 5G radio and other devices can max out my broadband connection from the same location - to me it appears there are still some issues.
[Pixel C Android Development] cheep5k8:
Video issue:

I think I know how this can be fixed. I presume that the memory clock is being set too low when the CPU freq goes to 51 MHz. This is not a problem on stock since the default minimum is 204 MHz.

I'll change this and post a test kernel image download link. Would be great if someone could test this additionally aside from just me.

EDIT: for reference: https://github.com/md5555/android_k...vidia/drivers/cpufreq/tegra210-cpufreq.c#L173
[Pixel C Android Development] cheep5k8:
After some inspection, I don't think that the SoC is allowed to go down to 51 MHz.

While it may technically be able to be clocked down to 51, the frequency of 204Mhz is referenced all over the kernel sourcecode as the minimal baseline.

I'm going to remove 51 Mhz as a choice when selecting the minimal frequency because it seems that it shouldn't be used, and so far I see no other reports from users about video tearing up except in this one your case where you underclocked the SoC.
[Pixel C Android Development] DaConcho:
Started getting quite a few reboots on v2. Flashed V3 RC 4 and all reboots have stopped. Great work!
[Pixel C Android Development] followmsi:
Back from travelling for one week on rooted T stock kernel.

I did not use the pixel c very much this week but I had no single reboot for the whole week.

Today I flashed v2 and had already 2 reboots this afternoon.

Will test v3 rc4 now ..

Cheers
[Pixel C Android Development] bill3508:
I use 102 as a minimum as it will stabilize there. It will go to 51 occasionally but its not stable and causes it to jump to higher frequencies resulting in higher CPU usage.
[Pixel C Android Development] followmsi:
After 2 hours on v3 rc4 I had just the first unexpected reboot.

Again while browsing with chrome.

What's wrong with my pixel c ? ?
[Pixel C Android Development] beardymcgee:
Howdy so I haven't had the issue with video using kernel tweaks nor any issues being at 51mhz, so can I have some time to tweak things before we remove that step from kernel?

edit: just got that issue when watching 1080p stuff so i have adjusted the timing in my other thread to maybe correct the issue as its no longer happening with mine any more, please report any issues with these new timings in the tweaks thread.
[Pixel C Android Development] cheep5k8:
I haven't removed it yet in RC5. Just everyone be careful, I don't think it's supposed to be set as the default min frequency.
[Pixel C Android Development] cheep5k8:
Everyone please excuse the shoddy v3-RELEASE git commit log with "Temp" commits; it was a bit difficult porting the nvidia bcmdhd driver and involved many steps, I promise to use more meaningful commit messages next time :)