An almost naked Pyra

[Djhg2000]

Since the Pyra isn't even running as a fully assembled prototype yet, let alone with finalized drivers, I interpreted the 2.5 hours as an early guesstimation. It may not be wrong, but it may just as well not be right.

I think criticizing the battery performance should be left for when we have some actual numbers from typical usage and not just the worst case bench figures.

 

[Exophase]

Since the Pyra isn't even running as a fully assembled prototype yet, let alone with finalized drivers, I interpreted the 2.5 hours as an early guesstimation. It may not be wrong, but it may just as well not be right.

I think criticizing the battery performance should be left for when we have some actual numbers from typical usage and not just the worst case bench figures.

If ED doesn't want us to treat the 2.5-3 hour and 120C figure he gave for the Pyra as worth much he shouldn't be saying it. This is less of a criticism of his post and more of a suggestion for the future. On the other hand, if he is pretty confident in those numbers it's probably best that people know sooner than later. There were some comments earlier that users wouldn't be able to use both cores at 1.7GHz indefinitely, but it sounds like things could be even worse than that.

I don't know if anything could realistically be changed now to improve the cooling design but if that's anywhere close to the table it shouldn't be held off as the last possible consideration.

 

[TrashyMG]

Not sure where 1.7Ghz got thrown around, The OMAP5432 clock speed is 1.5Ghz. It may be overclockable, but I've never attempted it. Heat is concerning, but I know it doesn't take much to dissipate it, I'd say dumping the heat into the Ground plane of the PCB may be good enough. I did an experiment long ago on current draw with the Pandora and the OMAP5 devboard. I tried both when the CPU(s) where 100% loaded and the OMAP5 was only marginally worse than the Pandora, however the Devboard is devoid of the LCD and Wireless, etc. I also can't say my cheap Ammeter would give that great of a view as it may not show quick spikes and such.

 

[EvilDragon]

What does stressing both CPUs to the maximum mean? 1.7GHz with a power-virus like program running on both cores?

I clocked the CPU to a fixed 1,5GHz speed on both cores and ran the program "stress" from the Debian repository on both cores.

A 6Ah battery should deliver over 22Wh of power, so 2.5-3 hours would mean about 7.5 to 9W power consumption. The total CPU cluster contribution would probably be north of 6W in this scenario, possibly significantly more. For comparison, see Exynos 5430, a big.LITTLE 4xCortex-A15 + 4xCortex-A7 SoC used in a few Samsung phones:

That assumption was with everything else included, so LCD, etc.
I think the OMAP5 itself uses a maximum of 4 - 5W for both cores, which is still a lot, but with 22Wh, it's 4 - 5 hours when running with full CPU usage.

If you can send me a compiled version of Drastic with the highres rendering included, I can test it on the EVM, if you like.

 

[Exophase]

Not sure where 1.7Ghz got thrown around, The OMAP5432 clock speed is 1.5Ghz. It may be overclockable, but I've never attempted it. Heat is concerning, but I know it doesn't take much to dissipate it, I'd say dumping the heat into the Ground plane of the PCB may be good enough. I did an experiment long ago on current draw with the Pandora and the OMAP5 devboard. I tried both when the CPU(s) where 100% loaded and the OMAP5 was only marginally worse than the Pandora, however the Devboard is devoid of the LCD and Wireless, etc. I also can't say my cheap Ammeter would give that great of a view as it may not show quick spikes and such.

1.7GHz is the advertised speed on the Pyra's spec page:

https://www.pyra-handheld.com/specs.php

1.7GHz is the maximum frequency the OMAP5432 was originally advertised as. It has since been quietly changed to 1.5GHz. Which only raises more concern. If 2x1.5GHz is what's off the table that's more troubling.

120C could be exaggerated since that's the temperature it reached w/o a heatsink. That is, if this is not an analogous situation to the Pyra, which has more thermal transfer than that, right?

I clocked the CPU to a fixed 1,5GHz speed on both cores and ran the program "stress" from the Debian repository on both cores.

Was it stress -c 2?

That would be spinning on sqrt. On the one hand, that should stress double-precision floating point multiply + add which is a heavy operation. On the other hand, it doesn't involve vectorization (as FP64 stuff it can't unless the library is doing some real magic), cache misses, prefetching, etc so I don't know if it's a real worst case scenario. DraStic's hires renderer could very well be heavier since it's heavily exercising vectorized code and moving a lot of data between L1 and L2 cache.

That assumption was with everything else included, so LCD, etc.
I think the OMAP5 itself uses a maximum of 4 - 5W for both cores, which is still a lot, but with 22Wh, it's 4 - 5 hours when running with full CPU usage.

Yeah, I took the 7.5-9W or so the 2.5-3 hour estimate gives and considered 1.5-3W at most for the non-SoC parts. I don't know what the real number is and maybe it'd be best to include the RAM (how well are the SoC and RAM thermally connected?) This is assuming the user isn't also running stuff like wifi, draining USB power, pegging the eMMC or SDs, etc, so the bulk of the remainder should be to the LCD. I'm hoping the LCD isn't 3+W.

If you can send me a compiled version of Drastic with the highres rendering included, I can test it on the EVM, if you like.

I'll talk to notaz and see if he can help with this.

You probably remember that the last we were at with this was trying to build a version for demoing, but that the screen blits were adding too much overhead. That'll probably still be the case unless there's hardware acceleration via SDL2. It should be able to use OpenGL ES2 for that, but if GPU drivers aren't in the OS it can't be helped. That said, this shouldn't really matter - if he can make sure that the rendering at least looks correct we can run it in benchmark mode over a long period of time and have the screen update part disabled. This should be enough to run two cores hard. We can also get some benchmark numbers this way to get a best case scenario (for the current codebase anyway...) for actually playing the games hires.

If I can work this with him he should be able to send a test build and run instructions.

 

[fusion_power]

CPU/GPU Throtteling is pretty common in the mobile area, even high priced (Gaming) Laptops with advanced cooling solutions tend to do that. I've read alot of reviews on Notebookcheck recently (need a new PC) and it seems indeed hard to pull out the heat from such devices. Now, when I imagine that the Pyra doesn't even have a real passive heatspreader or a metal case or anything, I guess we will expect alot of CPU throtteling, especialy when there are no other powersaving tricks available at the beginning. I remember, that the Pandora also had a very bad battery time in it's erly days. It will not be much different for the Pyra I guess.

But at the end it lays in the hand of the coders to use the OMAP5 as good as possible, may it firmware or apps. I'm sure it can be pretty fast and pretty battery saving if done right. I don't see a general problem there. It just takes time for sure.

 

[elvissteinjr]

I'm sure it can be pretty fast and pretty battery saving if done right. I don't see a general problem there. It just takes time for sure.

The thing is, no power saving feature or optimization will ever help when it's about the power consumption and heat development on a fully stressed CPU.
I'm sure Exophase knows well about what he's talking about. So my only hope here is that the estimates we have so far are a bit off in the positive direction.
The Pyra wouldn't be unusable, but it'd be a hard hit if it's gonna be necessary to trade performance for stability in this regard.

 

[Swordfish II]

Since the Pyra isn't even running as a fully assembled prototype yet, let alone with finalized drivers, I interpreted the 2.5 hours as an early guesstimation. It may not be wrong, but it may just as well not be right.

I really, really hope the Pyra can do about the same real life usage as the Pandora. That is one of my favorite things about it.

Side note: my two cents are to leave the buttons flat. Curving will throw off the backlight and delay production, and having used the OQO1, and Viliv N5, there is no way it will be as bad as those.

 

[TrashyMG]

Curving will throw off the backlight and delay production,

Not sure why it would throw off the backlight as we're only talking about the plastic transparent caps that are glued onto the rubber keymat. This prototype phase is specifically to find these deficiencies in the design and solution a fix.

 

[Swordfish II]

Not sure why it would throw off the backlight as we're only talking about the plastic transparent caps that are glued onto the rubber keymat.

Ah that should be easier then.

This prototype phase is specifically to find these deficiencies in the design and solution a fix.

I an aware of that, but at some point you simply have to go to market with what you have. There will always be more and more improvements that could be made, and in the grand scheme the keyboard is incredibly minor.

 

[Grench]

If someone wants to be pendantic about it, it would be theoretically possible to actually measure the amount of heat generated by a given device board.

Use a calorimeter (a highly insulated container) - a styrofoam cooler might work. Build the test rig in that. Pour in a measured quantity of an electrically non conductive liquid that won't dissolve the insulated container. Measure the liquid's temperature at rest. Supply power to the equipment for a given amount of time. Let the system come to a steady state after power is removed - measure the peak temperature of the liquid after that time. This method combined with some basic information around the liquid used can then be shoved through a few chemical engineering equations to establish the actual heat load generated.

Alternatively you could just measure the electrical load at the power inputs and assume it's all getting turned into heat energy - which is a pretty fair assumption.

*******************

I am under the impression/assumption that the SoC in the Pyra is capable of more 'work' per cycle than the SoC in the Pandora. I wish we had something to use as a valid benchmark - even an approximate one would be nice. Hypothetically if a 1Ghz Pandora SoC were overclocked to 1.5Ghz, how much more 'work' would the Pyra SoC do at the same clock rate on one of it's cores? Clock rates between the SoCs can never be equal - but hypothetically - if they were - how would performance stack out?

********************

Modern mobile SoC platforms are quoted at heat dissipation requirement rates that assume that the SoC is only going to be working at 'full load' a relatively small amount of the time. My understanding of what ED and co have done is to supply additional heat dispersal techniques in the board design. That should help spread heat spike loads from short bursts of heavy CPU usage. A concern of mine is that when that heat gets spread throughout the interior of the case, it will have to overcome the heat transfer resistance of the polycarbonate case. Engineers call this thermal conductivity.

There is a trade off in that. If the case material is too conductive to heat and had a lot of heat to get rid of, it could become unpleasant to hold on to, but become less 'hot spotty'. If the case is not conductive enough to heat and had a lot of heat to get rid of, it could become necessary to clock down or shut itself off to prevent damaging itself. Alternatively, a higher thermal conductivity could, in theory, use the person playing the Pyra as a liquid cooler (blood) for it's heat sink (case) - without getting 'too hot to handle'. Objects with high thermal conductivity will feel cool to the touch at normal room temperatures.

For perspective:
http://www.engineeringtoolbox.com/thermal-conductivity-d_429.html
http://www.coolpolymers.com/heattrans.html

Air's thermal conductivity rate is 0.02. Pretty much any non gas interface will move heat better. The exception being Aerogel.
Styrofoam has a VERY low thermal conductivity rate of 0.03 W/mK (Watts per meter Kelvin). It makes great coffee cups.
Normal polycarbonate has a relatively low thermal conductivity rate of 0.2 W/mK. It doesn't work well as a cook pot.
Special polycarbonate blends can be in the ~4 W/mK range. (http://www.coolpolymers.com/Files/DS/Datasheet_e4501.pdf)
There are some plastics that can get into the ~ 20 W/mK range, but may lack the other favorable qualities of polycarbonate.
Commercial aluminum (Aluminium) has a high thermal conductivity rate of ~125 W/mK. Pure is ~200 W/mK.
Pure copper is even higher at 400 W/mK. A nice thick layer of this is in the Pyra board to distribute heat inside the case.
Diamond, at 1500 W/mK is pretty amazing. Obviously they need to form the Pyra's case out of pure diamond.

ED has it right. At this stage of the process, build one or more and see how it works out. They have already given considerations and made some concessions to heat load. Next step is right where they're at - figure out if it was adequate to the task through testing. It may be that the current heat solution is adequate to the task. It may be that the device could use a more conductive case plastic (which would LOWER the temperature of 'hot spots'). Alternatives exist - moving heat isn't new science. First figure out if they're even needed.

 

[notaz]

When using stuff like DreamCast or N64 emulation, which needs more CPU power than the Pandora can offer, the power usage will increase. To what amount cannot be said yet, but I doubt they will use both CPU cores fully (as N64 already runs pretty well on the Pandora).

3D Stuff doesn't use the A15 but mostly the GPU, so the power issue is not really a thing here.

That's not necessarily true. Some drivers tend to busy-wait for the GPU, which is basically asking the GPU "are you done yet?" crazy amount of times, and that will eat lots of CPU time and hence power.

Last time we had 3D working, N64 on the devboard was working slower than on pandora, probably because the driver didn't like something the emulator is doing. I don't think the imgtec driver version changed since then, only TI kept doing some changes to their integration part, which may or may not help. So if things have not improved, you'll have slower that pandora's performance at MUCH higher power usage. The good thing is that this anomaly was only seen on mupen64plus though.

Now, when I imagine that the Pyra doesn't even have a real passive heatspreader or a metal case or anything, I guess we will expect alot of CPU throtteling

From what I know throttling is not implemented, only thermal shutdown was recently added. So if nobody steps up to implement it, we'll have abruptly shutting down Pyras, but I guess that's better than damaging the hardware.

 

[Grench]

Not sure why it would throw off the backlight as we're only talking about the plastic transparent caps that are glued onto the rubber keymat. This prototype phase is specifically to find these deficiencies in the design and solution a fix.

I know that the aesthetics and design people are going to say that flat key tops look better. But, frankly, on a thumb keyboard device the size of the Pandora/Pyra, having rounded key tops makes better sense ergonomically and mechanically. The Pandora's round gel key tops may have been off-putting in appearance to some, but it had good key-finding usability. The mechanical key throw depth was a bit high, but otherwise it wasn't bad. No, the Pyra doesn't need the dome height of the Pandora's keys, but rounded tops increases the perceived distance between keys AND gives people like me with fat fingers a bit more space in 3 dimensions to select one key at a time.

 

[comradekingu]

Is it something to do with allocating cache or conflicting I/O when two CPUs are available?

Or maybe the voltage needs to be stepped up when more overall CPU is being used, even just briefly.

 

[EvilDragon]

CPU/GPU Throtteling is pretty common in the mobile area, even high priced (Gaming) Laptops with advanced cooling solutions tend to do that. I've read alot of reviews on Notebookcheck recently (need a new PC) and it seems indeed hard to pull out the heat from such devices. Now, when I imagine that the Pyra doesn't even have a real passive heatspreader or a metal case or anything, I guess we will expect alot of CPU throtteling, especialy when there are no other powersaving tricks available at the beginning. I remember, that the Pandora also had a very bad battery time in it's erly days. It will not be much different for the Pyra I guess.

Well, the Pyra will use the same cooling functions as smartphones: some synthetic carbon to spread the heat, and we'll also use the ground layers of the PCB to spread it even further.

However, as it is with most smartphones, using them for an extended period of time with stressed CPUs will eventually lead to a lot of heat.
That's nothing we can change, as we can't do any miracles

I an aware of that, but at some point you simply have to go to market with what you have. There will always be more and more improvements that could be made, and in the grand scheme the keyboard is incredibly minor.

True, but some things need to be good, and the keymat needs a change anyways since I'm not content with the ABXY buttons yet.

I am under the impression/assumption that the SoC in the Pyra is capable of more 'work' per cycle than the SoC in the Pandora. I wish we had something to use as a valid benchmark - even an approximate one would be nice. Hypothetically if a 1Ghz Pandora SoC were overclocked to 1.5Ghz, how much more 'work' would the Pyra SoC do at the same clock rate on one of it's cores? Clock rates between the SoCs can never be equal - but hypothetically - if they were - how would performance stack out?

From what I remember, one core running at about 400MHz should equal a Pandora running at 1,3GHz in normal use case, but use less power than a Pandora running at 1.3GHz.

That's not necessarily true. Some drivers tend to busy-wait for the GPU, which is basically asking the GPU "are you done yet?" crazy amount of times, and that will eat lots of CPU time and hence power.
Last time we had 3D working, N64 on the devboard was working slower than on pandora, probably because the driver didn't like something the emulator is doing. I don't think the imgtec driver version changed since then, only TI kept doing some changes to their integration part, which may or may not help. So if things have not improved, you'll have slower that pandora's performance at MUCH higher power usage. The good thing is that this anomaly was only seen on mupen64plus though.

Well, from what I heard we'll get the driver for the Sitara series compiled for the OMAP5, so it might be a more recent version.
And yes, seeing how fast DreamCast ran, I can imagine there was something else going on with mupen64plus... who knows what the bottleneck was, not much debugging happened at the GamesCom

From what I know throttling is not implemented, only thermal shutdown was recently added. So if nobody steps up to implement it, we'll have abruptly shutting down Pyras, but I guess that's better that damaging the hardware.

Well, LXDE can already show the CPU temperatures and you can use cpufreq to limit the CPU speed.
A quick solution that monitors the temperature and limiting the CPU speed shouldn't be that hard to do and would be okay for a start.
[doublepost=1455668961,1455668872][/doublepost]

Is it something to do with allocating cache or conflicting I/O when two CPUs are available?

No, we know it has something to do with the power usage.
The CPU board where the Power Management chip (the PALMAS) is not available works fine

 

[Hồng Thất Công]

I ain't no worry about Pyra overheated. I always carry a can of liquid nitrogen with me.

 

[comradekingu]

If the system is initialized with just one core, it could for example be that when adding another it doesn't have the same prefetch info loaded in cache from DMA.

http://www.ti.com/tool/palmassw-linux has a lot of things to potentially go wrong.

 

[Grench]

Well, the Pyra will use the same cooling functions as smartphones: some synthetic carbon to spread the heat, and we'll also use the ground layers of the PCB to spread it even further.

However, as it is with most smartphones, using them for an extended period of time with stressed CPUs will eventually lead to a lot of heat.
That's nothing we can change, as we can't do any miracles

For longer sustained 'peak loads', the conversation eventually would need to shift from dispersing heat inside the device (copper heat spreader in the board) to releasing heat from the device to it's surroundings. I am talking about conductive heat, not radiated heat for simplicity. At these temperatures, thermal conductivity is far more important than radiation.

Note that there are different kinds of PC (polycarbonate) with different thermal conductivity properties. Going from 0.2 W/mK to 4 W/mK would give the case the ability to disperse heat throughout itself 20 times quicker. I.e. the case plastics can become a more efficient heat sink. Of course this could also mean that the case plastics could get hotter than you'll want to hold onto. BUT, they will also on net be more effective at shedding the heat from the system. The net end of it is that the heat generated inside the unit has to transfer to one of three places; the table it is sitting on, the hands holding it or the air around it. Heat transfer to air is very inefficient and is overcome either by surface area (fins) and/or air exchange (fans). Assuming gravity and nobody is suspending the unit on a string, it will have a solid-solid interface with the table OR a solid-liquid interface with a person. Both are pretty efficient (compared to air). This means that having a FLAT bottom surface (no feet) on the device would be favorable for heat management when sat on a table (increased solid-solid surface area). Having higher thermal conductivity from the plastic would help both.

Alternatively, if thermal insulating case plastics are favored, an aluminum heat path to a passive radiator might be an option. However the smaller the dissipation surface area, the hotter that spot is going to get.

Some of the thermally conductive plastics can seem like miracle materials. They can be expensive, though. No point in going there unless it's needed. However, if it is needed, it may be a viable option to increase the thermal conductivity of the case plastics so that the entire case is a more efficient radiator. Changing plastic formulas, though, could change shrinkage rates and mold considerations. Maybe not all that simple.

 

[levi]

If its initialized with just one core, it could for example be that when adding another it doesn't have the same prefetch info loaded in cache from DMA.

I'm glad Niklaus doesn't spend all of his time reading here and trying to figure out what everyone means when they're trying to help.

 

[EvilDragon]

It's just sad that Pyra is stuck using OMAP5, an SoC that was made for phones but basically failed to make it into any mobile product - until now.

l

Well, hopefully, it isn't stuck.
I certainly plan to get new SoCs in the future, and with a fully working system, it might be easier.
Visiting other SoC companies with the Pandora and the case quality wouldn't have been a good idea, but with the Pyra, it should be a lot better.

And we can kind of see why. There may not be a lot of programs that want to use both cores at 1.7GHz with a full load, but DraStic with high resolution rendering is not that far away from needing that, so I'm saying this extends beyond compiling things. Now I think it's not going to be a realistic option for Pyra and that's really unfortunate.

I just tried a few games on my Droid 4 with an OMAP4 Dualcore clocked to 1,2 GHz.
With HiRes rendering and frameskip disabled, I got about 60%.
With automatic frameskip, the games ran fine and the hires rendering really looks awesome.

This was with full Android running in the background, and the SoC didn't get warm at all, so not sure it was running at full speed all the time.

The OMAP5 will certainly perform better, but the question is: How much?
Looking for OMAP5 benchmarks, you mostly find an article where TI shows a benchmark that a dualcore OMAP5 clocked at 800MHz is a lot faster than a QuadCore CortexA9 at 1,2 GHz.
But that's a lot of marketing, so I doubt it.

From what I know, the A15 should be around 40 - 50% faster than an A9 (realistically, so not the marketing talk), but as the OMAP4 was clocked to 1,2GHz and we can go higher, that should be enough for Drastic.