I experienced this first hand but in a different context as it was at university level (somewhere between BSc and MSc). The teacher had written several math books, and each week we had to self study some chapters. Then during classes he would call some people to the board --- quite a stressful time that;). At first it would be to review the week chapters content (explain and redo key demonstrations). Then in a second step it was for doing related exercises.
In this context it was pretty effective. But we were old enough and at a level where everyone was pretty autonomous already. How young you can go I don't know, but I would guess when young enough you would need a more interactive explanation / teaching phase first. So I don't see this used too widely for young kids, but with old and mature enough young people why not?
Still, one has to be careful. Different people need different things. I prefer self study myself and was most of the time bored during lecture (only exception was very interactive classes on topics of interest to me, but that was a minority). So this system would be OK by me. But other people probably need more hand-holding during the learning phase, and these people would suffer unless their parents could fill the gap. Sure you could think that the teacher could then spend more time with them in class to compensate, but then you've just created differentiated teaching depending on level, and I'm not sure how effectively a teacher can handle this.
In the end, if it's optional only autonomous (or well supported by their parents) kids could use it and for them it would likely be all benefit. But I'm not sure it's for everyone.
They're the views of Nokia CEO, board and big shots (but not Greene it seems). I'm pretty sure a lot of employees have different opinions on the matter.
In the end, the opinion from the top do matters of course, but not as much as money. If WP7 continues to flop, and N9 has a (certainly unexpected from many) good acceptance, then we'll see.
Lack of applications may not be such a problem, taking two things into account. First, there is a need for a decent base, but the porting of Qt/linux open source applications could provide a decent base (see the work on getting Caligra, Marble to mobile). The UI need to be redone and some Q&A/polish required. But Qt Declarative goal is to make writing a mobile friendly UI simple (and leverage the core), and Nokia seems to help on Q&A. I'm not following this closely but it seems they're close to many KDE application developers. Second, if the Android runtime announced for the N9 indeed allows running Android applications (at least the ones not using the NDK, but it's the majority), then many Android user could consider it too. I have an Android phone, and wouldn't mind getting a N9 for example if it runs most of the apps I use or provide good alternatives.
Regarding performance, on principle an integrated solution can do better by offering tighter integration and more efficient exchanges between CPU and GPU than going through a lower speed / higher latency external bus as for a discrete GPU.
This isnt quite right. On principle, a discrete solution doesnt have to compromise with the low-latency random access memory performance demands of the CPU, while an integrated solution does. For raw compute performance, the discrete solutions are starting out in a much better position.
Let's keep in mind that I'm talking about a possible high-end integrated solution that doesn't exist yet. This device would be NUMA-like, and have a high-speed memory on a wide bus optimized for the GPU, in addition to a classical memory optimized for the CPU. Still, CPU and GPU can access each other memories with higher performance than in a current discrete GPU solutions. Think about a multi-core Opteron memory organization, but instead of being symmetric (all memory ports identical) the ports are optimized for either CPU or GPU.
In this context, there's no need to compromise on the GPU accesses to the GPU memory bank. So no loss compared to a discrete solution. But accesses to the CPU memory for CPU/GPU exchanges would still be better than with a current discrete solution.
I agree it's all hypothetical as all current integrated solutions are low/middle end and with a single unified shared memory, but I just wanted to say that on principle an integrated solution can be a no compromise solution too, with such a dual bank / NUMA implementation, and still come on top for CPU/GPU exchanges.
The latency savings only manifests as a win for small workloads, but small workloads ultimately dont matter (blink of an eye vs half-a-blink of an eye)
There can be a self fulfilling element here: because the current discrete solutions are poor whenever there are significant exchanges required between CPU and GPU, people only use them for workload mostly running on the GPU (big workloads). Indeed, with small workloads the exchange overhead would be too high. I agree that such workloads would not benefit from a high-end integrated GPCPU.
But a high-end / NUMA-like integrated implementation, by reducing the CPU/GPU overhead could make GPU acceleration more practical to smaller workloads than today. How common that is I can't say, but it would be an advantage for AMD to push in this direction as they are stronger than Intel on the GPU side and weaker on the CPU side (for now, waiting to see what bulldozer will be like;). In other words, the high-end integrated GPCPU would not necessarily be much better for current workloads, but could make more workloads suited for GPCPU acceleration.
Unified memory is an implementation option, but not the only one. It definitely make sense when price matters more than performance. But for a higher end part you could have separate memories. Look at AMD multi-core CPUs, it's already NUMA (light) from the start: each core as a direct attached bank with minimum latency, and can access the other cores memory banks with a (small) additional latency. Extended here, the GPU could have a dedicated higher performance GDDR5 memory directly attached, but accessible from the CPU side (and similarly the GPU could access all the system memory). It's a NUMA extension for a hybrid architecture if you wish. It needs support from the OS/drivers to handle this in a transparent way, but NUMA is not new so existing know-how could be reused.
Regarding performance, on principle an integrated solution can do better by offering tighter integration and more efficient exchanges between CPU and GPU than going through a lower speed / higher latency external bus as for a discrete GPU. We shouldn't judge the principle by today implementations, as they target the low (bobcat based) and middle (llano) ends only, not yet the high end.
The con of integration is that you loose the flexibility of choosing CPU and GPU separately, and upgrading separately, but as others have pointed out most people do not care nor use this in practice.
As for fragmentation, it's the usual situation. You can hide the differences using things like OpenCL, but you'll sacrifice some performance initially compared to a targeted implementation. Most should target this when the tools become sufficiently mature. But if you want to extract all the juice you will have to be target dependent, and face this fragmentation indeed. Still, over time we can expect some convergence (the good ideas will become clearer, and be adopted). So with time the generic approach (OpenCL or like) will become better and better, and less and less people will develop for a target as the decreasing performance advantage won't justify the cost. This process will not necessarily be fast;) and we're just starting.
Agreed, but I really don't like the fact that getting the phone state and getting your identity are grouped together. I don't mind that an app get to the phone state to play nice if needed (although there should be other mean). But I don't want an app to get to the identity information (SIM id, or IMSI, and phone id or IMEI), as it allows tracking users too. We make a fuss about tracking on the web, and make it too easy to Android app to do such tracking themselves. Why are both grouped together? This seems arbitrary and sloppy.
The most important difference between USB 3.0 and Thunderbolt / LightPeak is that USB is an open standard and LP is Intel specific. Sure from a performance point of view LP is better than USB 3.0, just as Firewire was also better then USB 2.0 (even if contrary to LP its peak rate was lower. You could say that LP is even better than FW was). But being Intel only means higher cost in the end, and we could see the effect of higher cost in USB 2.0 vs. Firewire. Particularly when for most purposes USB 3.0, just as 2.0 before, will be good enough.
Please note that I said "most" not "all". There will be for sure use cases where the better performance of LP will justify the small added cost. It's just that most won't care and prefer price, creating a positive trend for USB cost compared to LP.
Talking about "the chip" as if there were a separate dedicated chip for this is very likely a misleading oversimplification. This simplification comes from the article itself:
A special chip is required to allow a phone to receive the messages, and soon all new phones will have the technology. Some smartphones already have the chip, and software updates will be available when the network goes online later this year, Genachowski said.
Such alerts are typically handled by your cell phone baseband chip. For example since the beginning in LTE there is the ETWS (Earthquake and Tsunami Warning System) that is made to send such alerts. You can see from the name why it was designed, but it could support any kind of alert really. It's just a specified protocol to send urgent alerts to terminals. In release 9, this idea has been extended into CMAS (Commercial Mobile Alert Services, 3GPP spec TS 22.228, publicly available at 3gpp.org). Really the same idea, but more flexible and easier to monetize for the operators... I'm talking about LTE here but I guess equivalent systems exist for 3G and other mobile communication standards.
A national alert system would simply be built on top of these tools. In this case it's just an upgrade to cell phones base-band chips software to support these protocols, and the the cell phone application CPU software to make use of it and handle the final display to the end user. As the article mention support is mostly a software upgrade for a lot of devices, it's safe to assume this is what will be done. No dedicated chip.
Yes indeed, for most people interference is the main issue. If you're in a dense area you'll have plenty of others WiFi networks around, with everybody stepping on each other foots^H^H^H^H^Hantennas. Where I work you can't get a good connection close to the windows due to too many interferers from outside. Yeah it would be possible to put your own APs all around close to the windows and win, but it's too much of a pain. People use their smartphones and cell connection. Chalk one up for proper network planning and managed spectrum.
Now this may be less of a problem in some parts of the US where there is plenty of space and businesses have less to fear from neighbor networks interference. Then the issue mentioned in the article (scaling to many devices) can be the problem: WiFi doesn't behave well when there are too many clients using it at the same time. It's CSMA/CD so it's to be expected. A system with centralized scheduling (as in cellular networks) would fare much better here. Hyperlan, once a competitor of WiFi, used this. But it was as a result more complex, longer to specify and would have been more expensive (at first. The added complexity is peanuts nowadays, see the femto BSs for cellular). WiFi arrived first with good enough and cheap devices, and won the market.
In any case, the guy writing the article as no clue about wireless. Saying that the main issue is not having a central management covering wired and wireless... Wow!
A microwave typically uses a frequency of 2.45 GHz, which is in the WiFi band. If her oven leaks RF power outside, it will indeed kill all the WiFi channels. A WiFi AP transmits 200 mW, a microwave can use 750 to 900 W. Of course this energy is supposed to stay inside the oven, but if the oven has a defect or is not well shielded and even a small part of this leaks it will blind all WiFi receivers around for sure.
I hope she's not one of those people freaking out because of cell phone radiations by the way. Because a GSM cell phone tops at 2W (or 33 dBm) worst case while 3G and 4G are much lower (23 dBm for both WiMAX and LTE). It's likely that the oven dumps much more in the environment when used. Time to offer your lady a tin-foil hat, or a new microwave;)
Absolutely. Plus the fact that for Android smartphones SE is the underdog and need something to catch up. Typically the underdog is the one having the most incentive to open the platform to differentiate themselves. See Sprint, pushing more openness compared to Verizon/AT&T (no cap, Google Voice...). It's just the same thing here for handsets. And it's important that these underdogs have some amount of success, as in the end this is how a platform move toward more and more openness. The leaders typically would prefer locking everything tight to extract the more money out of everything. Only the underdogs will accept sacrificing this because they have nothing to loose. So I understand many people have upset with Sony, but this kind of attitude should be encouraged even if it's not taken for idealistic reasons at all...
Not exactly. Intel has announced 22 nm, but is producing 32 nm now.
Meanwhile, ARM licensees (ARM itself do not make chips) are currently at 40 nm. And 28 nm has been announced with products expected middle of this year.
So it's more 22 nm for Intel vs. 28 nm for TSMC and GlobalFoundies. In other words, instead of a 2 generations lead it's a half-node lead on paper. Which is already interesting of course.
Now an open question: Intel is focusing on high performance for their chips (called "G" for generic, or "HP" for high-perf depending on fab and kind). While ARM SoCs are focusing on low-power (LP) implementation. Typically the LP variant comes later. LP has a lot less leakage, but cannot go to as high frequencies than G/HP. For example there are already 28G chips at TSMC, while not yet 28LP ones (but soon). Where is Intel in the LP variants? How much of their high performance lead will they be able to carry over to the LP variant, which is the one of interest for handsets?
Would that work on any iPhone? Not necessarily. In Europe you can buy either subsidized or unsubsidized phones, at your choice. If it's subsidized, the phone is typically locked and will only accept a SIM card from the operator subsidizing the phone, which makes sense. This locking is time limited, after a while (can't remember how long...) you're entitled to ask the operator to unlock your phone. An unlocked phone is like all unsubsidized phone and will accept any SIM card you stick into it. So here using a pre-paid SIM would work on an unlocked phone, but not in a locked on.
Maybe there are variations depending on the European countries, but I guess this description is valid in most European countries (at least it's in mine;)
I fear there's significant self-selection at work here. Would you join a political party full of people with a very different culture that you do not respect so much (and who pay lip service to yours)? Like you're an engineer, and political parties are made of lawyers and accountants as you said? Or to put it in a more colorful way, would you jump into a basket of crabs if you're not one yourself?
I agree with you, there is a very dire need to get more various technical and scientific expertize into politics and parliaments. But with so much energy to spend on getting elected (not fun if tech/science is what interests you) and the crowd you'd be joining, there is a very high barrier to entry in practice. And the worst is that with all the paranoia about many science based issues (nuclear, OGM,...) I'm not sure that the public would be very supportive of engineers or scientist willing to move into politics.
So I guess the technical input will still be through professional lobbies for a while, and sometimes (as here) after the fact. It's by far not an ideal situation as in such case expertize is strongly biased by financial interests, but without more interest and support for science in the general public in the first place I don't see how we could get much better in practice.
"Never attribute to malice that which is adequately explained by stupidity". Politics in France are particularly clueless about technology. Worse, they think they know it all because they had some cute web site with streaming video being designed for them. And someone who think he's good without having a clue is dangerous indeed. The current France government is full swing in security posturing, without much concern for the practical consequences that are not so clear to them anyway. All this is enough to explain this new law.
As for being a trick to favor French firms, this is incorrect as local companies are also affected and suffer from this. From the article, one of the companies attacking this law is DailyMotion, and they're French. I don't see any tech company being happy about this.
Lastly, there have been several laws cancelled in France recently due to either being incompatible with Europeans laws or being against France own constitution. That gives you an idea of how much the projects were well prepared and thought out... So this is not done and over.
You are correct, the filters are band specific and are the primary limitation here.
To build on your comment and provide a bit more context: the processing chain is base-band chip, RF chip and front-end (FE). The front end is made of LNA, filters, switches, duplexers, antennas, etc.
The base-band chip is band agnostic, and can easily support all bands. The current RF chips can be limited to a few selected bands, but the trend is to multi-bands chips. For LTE where there are bands all over the place, there's a big push toward multi-band RF chips. But in the FE part, the filters are required and are limited to a specific band (the point being to reject signals from other bands to avoid saturating the A/D converter on the receive side, and to avoid polluting other bands on the transmit side). You could imagine a bank of filters with switches to select the proper band, but there's a limit to how much you can fit on a phone and it's not as simple as I make it sound.
Disclaimer: I'm not a RF and FE expert by any mean. I just want to point out that supporting a lot of bands concurrently is challenging and has cost/footprint implications.
That's how it works already. The protocol stack runs on a separate chip with its own dedicated CPU (or CPUs) and its own firmware image. So you only need to secure this firmware to secure the telecom network. The only reason to also lock the application CPU is to provide to the operator or device maker more control on the separate application environment, for their benefit.
The ideal system would have a locked down access chip (to protect usage of the operator spectrum, you don't want unchecked hacking here) and an open application CPU (or CPUs). This is what OpenMocko did, and the application CPU(s) would be as open as the PC today. But that's not the trend today. Maybe a reason not to dismiss the N950 (or however it will be called).
If you look at Blaze blog entry, you'll find this gem:
On average, Android 2.3 was a 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone’s median load time of 3.254 seconds.
If it were relevant (which is not the case as it's supposed to compare web browsers), then the iPhone would be 52% slower than Android. Which is equivalent to say that Android would be ~34% faster then the iPhone, not 52% faster (for this, Android would need to complete in less than half the time of the iPhone). I guess that it's not politically correct to use the negative version (iPhone is slower), but then it's hard to resist using the higher number right?;)
Interestingly, this has been reused by all news sites without anyone spotting the error. If Paulos makes a refresh of his "Innumeracy" book, I suggest this as an new example of how people lack fluency with basic computations.
I have neither iPhone nor Android phone (although I offered an iPhone to my wife, and would be more likely to buy an Android phone for me), and I don't care much about such differences. So I would consider myself quite neutral to this discussion. But it feels like the Blaze announcement was sensationalistic and a bit sloppy from the start. Anyway, it certainly worked in getting publicity, and that's probably all they cared for.
Yes, LTE advance (release 10 of LTE actually, as it's an incremental improvement) has a top Category 8 device that peaks at close to 3 Gbps. Go to www.3gpp.org and fetch TS 36.306, the categories are in section 4.1. Base LTE goes from Cat1 to 5, and LTE-A added Cat 6 to 8.
Now you need to know only one thing: the last category is mostly never implemented. These standards are hugely complex, and competition is fierce. So people get carried away and promise the moon. Then engineers in standardization start the serious work, and see what's possible, and it's not the same. So to be polite, the last category is dimensioned to match the silly promises, and nobody implements it as it is too impractical (unacceptable power consumption to start with, reliance on huge spectrum not available and on too many antennas that wouldn't fit in a handset, just as a few examples).. And the lower are made to be practical.
In basic LTE, the last category 5 was 300 Mbps downlink. What's implemented in practice today is Cat3 at 100 Mbps DL. Maybe some will push to Cat4 (150 Mbps) for bragging rights, but it'll make little difference in the field (we're talking peak rates here, which is only possible on a small part of a cell).
In LTE-A (R10), the last category 8 is ~3 Gbps DL. And the previous practical categories 6 and 7? Well, they're 300 Mbps. Yes you read it well, that's a factor of 10 difference. That should tell you all you need to know about Gps speed.
Today, power is already a challenge with WiMAX, which is 2 Rx chains and 10 MHz. LTE is 2 Rx chains and 20 MHz. LTE-A to meet 1 Gbps would need 70 MHz and 4 Rx chains (for 4x4 MIMO in DL) for example. Nobody has this contiguous spectrum, so that means carrier aggregation, at least 2 bands in practice. So you need 8 Rx chains, which draw power. That's a factor of 4 increase on the RF side. And the baseband is more complex too. All that while the first base (R8) LTE handsets are power challenged.
So please people, get real and use common sense. All this talk of Gpbs speed (even in static) is getting embarrassing. Sure, it's easy to do and perfectly possible on a demo set-up where power and footprint (for all the antennas) are no issue. If you talk real life, it's a different thing.
Besides this, LTE is still a very good standard a significant improvement on what we have. And LTE-A will also be a significant improvement too. But instead of focusing on silly peak rates, go to the 3GPP web site and look at the performance assessment for LTE-A for cell average. You'll find that LTE advanced is expected to be 40 to 60% more efficient in average than LTE. And this is a big gain.
Last point, because we're on Slashdot and we can talk real tech, you need to understand that peak rate doesn't matter much now. Seriously, WWAN faster then WiFi (which is also BS with talk of 600 Mbps, but that's a different story. On portable device it's 20 to 30 Mbps typically)? What matters now is handling the data explosion, and this means improving the network capacity. People always push peak rates as it's more sexy for the average Joe, but that's capacity that matters. Even for you. But it's certainly less sexy and harder to explain.
Still, whenever you hear about higher peak rates, understand that the features underlying the improvement will in practice not be used for higher peak rates, but for increased capacity. Example: MIMO. LTE-A goes up to 8x8 MIMO in Cat8, but that won't be used in mainstream product (and maybe never, as doing a complex chip for a niche market looks very expensive). But you can still have the 8 antennas at the BS, and only 2 at the terminal, and do multi-users MIMO with 4 concurrent users, each using 2 SM MIMO layers. That's really what the standard is made for, and it will increase the network capacity for our benefit.
Thanks for reading so far. I needed the venting on that topic;)
Re:It's a bit more complex than this article...
on
Pocket Wars and Cores
·
· Score: 1
Just a comment on "If you want to embed processing functionality, or you want low-power (particularly low standby power), then you need ARM."
Stand-by power is really process related, and not so much related to the IA. It's true that ARM SoCs are using the LP (low power, and low leakage) variant of silicon processes while Intel/AMD processors use the high performance variants (faster, but higher power and leakage). But nothing prevents Intel optimizing for lower power, and the Atom goes in this direction while still targeting higher performance than current ARMs (that could change with A15, Denver...). Moreover, with recent processes (40 nm and below) the leakage is so high even in LP that for good stand-by performance one has to implement power gating. Intel can do that too. And I would guess the 50x improvement on recent Atoms come from this. Once you do power gating most design would consume negligible power in deep stand-by. ARM SoCs would still have an advantage as they are better integrated, but Intel has indicated they will go to more integration over time for Atoms. So it's really implementation choices, and different goals, that hard intrinsic advantage here IMHO.
ARM cores are available at three level: as a hard macro (ready to use for a specific process, you can't change anything), as RTL (you do the routing, and there some amount of configuration for caches, TCM, FP, etc.) or as an instruction licensee (you do the implementation yourself). In theory nothing would prevent an instruction licensee to do a super high performance implementation for example. It's just that in practice ARM licensee target for now low power devices, and as you explain target a different performance/power trade-off than even current Atom/Bobcat chips.
Regarding point 3, isn't WP7 accepting only managed.Net code at this point? Which would make sense, considering that the underlying OS is still in the WinCE / Windows Mobile line, so will be replaced by a "NT line" kernel in the future. So it makes sense for MS to hide the internals and force all developers to stick to their VM until this transition is done (WP8?).
In this case, it looks like WP7 is even worse than Android for you. And QT is coming to Android, although it's still young.
Hey, you missed part of the action it seems... A few months ago, before Elop arrived, Nokia sold its baseband division. It's now called Renesas and is an independent business. Just like every baseband vendor, they're also moving in the application processor space to provide in addition to baseband chips integrated AP+BB solutions (as Qualcomm, as ST-Ericcson, etc.).
I certainly hope with him that the most open systems will win in the end. But this is all bla-bla, in the end it's just business. For a given price point every player try to get the maximum share. You do this by commoditizing the others:
- Intel loves linux based x86 systems as it creates more competition at OS level. Less money for the OS, bigger share for their CPU for a given price;
- I'm sure Microsoft will love ARM. Sure, it's a port and they will have to make the porting super easy for all MS based software developers, but they benefit from a very competitive CPU ecosystem where CPU cost will be lower than with just Intel/AMD. And a bigger pie possible for them in the end.
So you can see why Intel and MS are not chum anymore. The time where PC price were so high everybody could be happy is over, now all fight for dollars.
Now where does this put Nokia? They may want to play in services, but viewing their dismal performance so far I don't think they'll get very far. My guess is that they negotiated a part of the WP license for them, based on some (real of phony) participation. Now consider the options:
1) join Android, and having to fight on an even field with ruthless competitors like Samsung, HTC & co;
2) join WP, and fighting them with a price advantage due to a share of the OS license for them.
Surprised at what they preferred? Well to be honest I was;) But with more thinking it's hardly surprising. Just follow the money.
Plus, as someone says, they target not WP7 but the next step when you're phone docked will be your computer. MS will offer Office and Outlook, and all the lazy persons will follow. Unless MS executes super poorly that's a real advantage.
We could have had a clean start with these new super phones, shedding most of the cruft accumulated over the years of PC evolution. I'm fairly comfortable we'll have a clean start with ARM (and its zillions licensees) on the CPU side. On the OS side, I guess MS will be here to stay... I just hope there will still be good linux based offering for those super phones --- and I don't count Android or ChromeOS as good enough, I want a local connected system and not do it all in the cloud thank you.
Slashdot Mirror
I experienced this first hand but in a different context as it was at university level (somewhere between BSc and MSc). The teacher had written several math books, and each week we had to self study some chapters. Then during classes he would call some people to the board --- quite a stressful time that ;). At first it would be to review the week chapters content (explain and redo key demonstrations). Then in a second step it was for doing related exercises.
In this context it was pretty effective. But we were old enough and at a level where everyone was pretty autonomous already. How young you can go I don't know, but I would guess when young enough you would need a more interactive explanation / teaching phase first. So I don't see this used too widely for young kids, but with old and mature enough young people why not?
Still, one has to be careful. Different people need different things. I prefer self study myself and was most of the time bored during lecture (only exception was very interactive classes on topics of interest to me, but that was a minority). So this system would be OK by me. But other people probably need more hand-holding during the learning phase, and these people would suffer unless their parents could fill the gap. Sure you could think that the teacher could then spend more time with them in class to compensate, but then you've just created differentiated teaching depending on level, and I'm not sure how effectively a teacher can handle this.
In the end, if it's optional only autonomous (or well supported by their parents) kids could use it and for them it would likely be all benefit. But I'm not sure it's for everyone.
They're the views of Nokia CEO, board and big shots (but not Greene it seems). I'm pretty sure a lot of employees have different opinions on the matter.
In the end, the opinion from the top do matters of course, but not as much as money. If WP7 continues to flop, and N9 has a (certainly unexpected from many) good acceptance, then we'll see.
Lack of applications may not be such a problem, taking two things into account. First, there is a need for a decent base, but the porting of Qt/linux open source applications could provide a decent base (see the work on getting Caligra, Marble to mobile). The UI need to be redone and some Q&A/polish required. But Qt Declarative goal is to make writing a mobile friendly UI simple (and leverage the core), and Nokia seems to help on Q&A. I'm not following this closely but it seems they're close to many KDE application developers. Second, if the Android runtime announced for the N9 indeed allows running Android applications (at least the ones not using the NDK, but it's the majority), then many Android user could consider it too. I have an Android phone, and wouldn't mind getting a N9 for example if it runs most of the apps I use or provide good alternatives.
Regarding performance, on principle an integrated solution can do better by offering tighter integration and more efficient exchanges between CPU and GPU than going through a lower speed / higher latency external bus as for a discrete GPU.
This isnt quite right. On principle, a discrete solution doesnt have to compromise with the low-latency random access memory performance demands of the CPU, while an integrated solution does. For raw compute performance, the discrete solutions are starting out in a much better position.
Let's keep in mind that I'm talking about a possible high-end integrated solution that doesn't exist yet. This device would be NUMA-like, and have a high-speed memory on a wide bus optimized for the GPU, in addition to a classical memory optimized for the CPU. Still, CPU and GPU can access each other memories with higher performance than in a current discrete GPU solutions. Think about a multi-core Opteron memory organization, but instead of being symmetric (all memory ports identical) the ports are optimized for either CPU or GPU.
In this context, there's no need to compromise on the GPU accesses to the GPU memory bank. So no loss compared to a discrete solution. But accesses to the CPU memory for CPU/GPU exchanges would still be better than with a current discrete solution.
I agree it's all hypothetical as all current integrated solutions are low/middle end and with a single unified shared memory, but I just wanted to say that on principle an integrated solution can be a no compromise solution too, with such a dual bank / NUMA implementation, and still come on top for CPU/GPU exchanges.
The latency savings only manifests as a win for small workloads, but small workloads ultimately dont matter (blink of an eye vs half-a-blink of an eye)
There can be a self fulfilling element here: because the current discrete solutions are poor whenever there are significant exchanges required between CPU and GPU, people only use them for workload mostly running on the GPU (big workloads). Indeed, with small workloads the exchange overhead would be too high. I agree that such workloads would not benefit from a high-end integrated GPCPU.
;). In other words, the high-end integrated GPCPU would not necessarily be much better for current workloads, but could make more workloads suited for GPCPU acceleration.
But a high-end / NUMA-like integrated implementation, by reducing the CPU/GPU overhead could make GPU acceleration more practical to smaller workloads than today. How common that is I can't say, but it would be an advantage for AMD to push in this direction as they are stronger than Intel on the GPU side and weaker on the CPU side (for now, waiting to see what bulldozer will be like
Unified memory is an implementation option, but not the only one. It definitely make sense when price matters more than performance. But for a higher end part you could have separate memories. Look at AMD multi-core CPUs, it's already NUMA (light) from the start: each core as a direct attached bank with minimum latency, and can access the other cores memory banks with a (small) additional latency. Extended here, the GPU could have a dedicated higher performance GDDR5 memory directly attached, but accessible from the CPU side (and similarly the GPU could access all the system memory). It's a NUMA extension for a hybrid architecture if you wish. It needs support from the OS/drivers to handle this in a transparent way, but NUMA is not new so existing know-how could be reused.
;) and we're just starting.
Regarding performance, on principle an integrated solution can do better by offering tighter integration and more efficient exchanges between CPU and GPU than going through a lower speed / higher latency external bus as for a discrete GPU. We shouldn't judge the principle by today implementations, as they target the low (bobcat based) and middle (llano) ends only, not yet the high end.
The con of integration is that you loose the flexibility of choosing CPU and GPU separately, and upgrading separately, but as others have pointed out most people do not care nor use this in practice.
As for fragmentation, it's the usual situation. You can hide the differences using things like OpenCL, but you'll sacrifice some performance initially compared to a targeted implementation. Most should target this when the tools become sufficiently mature. But if you want to extract all the juice you will have to be target dependent, and face this fragmentation indeed. Still, over time we can expect some convergence (the good ideas will become clearer, and be adopted). So with time the generic approach (OpenCL or like) will become better and better, and less and less people will develop for a target as the decreasing performance advantage won't justify the cost. This process will not necessarily be fast
Agreed, but I really don't like the fact that getting the phone state and getting your identity are grouped together. I don't mind that an app get to the phone state to play nice if needed (although there should be other mean). But I don't want an app to get to the identity information (SIM id, or IMSI, and phone id or IMEI), as it allows tracking users too. We make a fuss about tracking on the web, and make it too easy to Android app to do such tracking themselves. Why are both grouped together? This seems arbitrary and sloppy.
The most important difference between USB 3.0 and Thunderbolt / LightPeak is that USB is an open standard and LP is Intel specific. Sure from a performance point of view LP is better than USB 3.0, just as Firewire was also better then USB 2.0 (even if contrary to LP its peak rate was lower. You could say that LP is even better than FW was). But being Intel only means higher cost in the end, and we could see the effect of higher cost in USB 2.0 vs. Firewire. Particularly when for most purposes USB 3.0, just as 2.0 before, will be good enough.
Please note that I said "most" not "all". There will be for sure use cases where the better performance of LP will justify the small added cost. It's just that most won't care and prefer price, creating a positive trend for USB cost compared to LP.
Really, it's FireWire vs. USB redux.
A special chip is required to allow a phone to receive the messages, and soon all new phones will have the technology. Some smartphones already have the chip, and software updates will be available when the network goes online later this year, Genachowski said.
Such alerts are typically handled by your cell phone baseband chip. For example since the beginning in LTE there is the ETWS (Earthquake and Tsunami Warning System) that is made to send such alerts. You can see from the name why it was designed, but it could support any kind of alert really. It's just a specified protocol to send urgent alerts to terminals. In release 9, this idea has been extended into CMAS (Commercial Mobile Alert Services, 3GPP spec TS 22.228, publicly available at 3gpp.org). Really the same idea, but more flexible and easier to monetize for the operators... I'm talking about LTE here but I guess equivalent systems exist for 3G and other mobile communication standards.
A national alert system would simply be built on top of these tools. In this case it's just an upgrade to cell phones base-band chips software to support these protocols, and the the cell phone application CPU software to make use of it and handle the final display to the end user. As the article mention support is mostly a software upgrade for a lot of devices, it's safe to assume this is what will be done. No dedicated chip.
Part of the charm of Slashdot is the unique quality of the users (at least those with UIDs lower than about 2000000).
Cheers ;)
Yes indeed, for most people interference is the main issue. If you're in a dense area you'll have plenty of others WiFi networks around, with everybody stepping on each other foots^H^H^H^H^Hantennas. Where I work you can't get a good connection close to the windows due to too many interferers from outside. Yeah it would be possible to put your own APs all around close to the windows and win, but it's too much of a pain. People use their smartphones and cell connection. Chalk one up for proper network planning and managed spectrum.
Now this may be less of a problem in some parts of the US where there is plenty of space and businesses have less to fear from neighbor networks interference. Then the issue mentioned in the article (scaling to many devices) can be the problem: WiFi doesn't behave well when there are too many clients using it at the same time. It's CSMA/CD so it's to be expected. A system with centralized scheduling (as in cellular networks) would fare much better here. Hyperlan, once a competitor of WiFi, used this. But it was as a result more complex, longer to specify and would have been more expensive (at first. The added complexity is peanuts nowadays, see the femto BSs for cellular). WiFi arrived first with good enough and cheap devices, and won the market.
In any case, the guy writing the article as no clue about wireless. Saying that the main issue is not having a central management covering wired and wireless... Wow!
A microwave typically uses a frequency of 2.45 GHz, which is in the WiFi band. If her oven leaks RF power outside, it will indeed kill all the WiFi channels. A WiFi AP transmits 200 mW, a microwave can use 750 to 900 W. Of course this energy is supposed to stay inside the oven, but if the oven has a defect or is not well shielded and even a small part of this leaks it will blind all WiFi receivers around for sure.
;)
I hope she's not one of those people freaking out because of cell phone radiations by the way. Because a GSM cell phone tops at 2W (or 33 dBm) worst case while 3G and 4G are much lower (23 dBm for both WiMAX and LTE). It's likely that the oven dumps much more in the environment when used. Time to offer your lady a tin-foil hat, or a new microwave
Absolutely. Plus the fact that for Android smartphones SE is the underdog and need something to catch up. Typically the underdog is the one having the most incentive to open the platform to differentiate themselves. See Sprint, pushing more openness compared to Verizon/AT&T (no cap, Google Voice...). It's just the same thing here for handsets. And it's important that these underdogs have some amount of success, as in the end this is how a platform move toward more and more openness. The leaders typically would prefer locking everything tight to extract the more money out of everything. Only the underdogs will accept sacrificing this because they have nothing to loose. So I understand many people have upset with Sony, but this kind of attitude should be encouraged even if it's not taken for idealistic reasons at all...
Not exactly. Intel has announced 22 nm, but is producing 32 nm now.
Meanwhile, ARM licensees (ARM itself do not make chips) are currently at 40 nm. And 28 nm has been announced with products expected middle of this year.
So it's more 22 nm for Intel vs. 28 nm for TSMC and GlobalFoundies. In other words, instead of a 2 generations lead it's a half-node lead on paper. Which is already interesting of course.
Now an open question: Intel is focusing on high performance for their chips (called "G" for generic, or "HP" for high-perf depending on fab and kind). While ARM SoCs are focusing on low-power (LP) implementation. Typically the LP variant comes later. LP has a lot less leakage, but cannot go to as high frequencies than G/HP. For example there are already 28G chips at TSMC, while not yet 28LP ones (but soon). Where is Intel in the LP variants? How much of their high performance lead will they be able to carry over to the LP variant, which is the one of interest for handsets?
Yes, pre-paid card = pre-paid SIM card.
;)
Would that work on any iPhone? Not necessarily. In Europe you can buy either subsidized or unsubsidized phones, at your choice. If it's subsidized, the phone is typically locked and will only accept a SIM card from the operator subsidizing the phone, which makes sense. This locking is time limited, after a while (can't remember how long...) you're entitled to ask the operator to unlock your phone. An unlocked phone is like all unsubsidized phone and will accept any SIM card you stick into it. So here using a pre-paid SIM would work on an unlocked phone, but not in a locked on.
Maybe there are variations depending on the European countries, but I guess this description is valid in most European countries (at least it's in mine
I fear there's significant self-selection at work here. Would you join a political party full of people with a very different culture that you do not respect so much (and who pay lip service to yours)? Like you're an engineer, and political parties are made of lawyers and accountants as you said? Or to put it in a more colorful way, would you jump into a basket of crabs if you're not one yourself?
...) I'm not sure that the public would be very supportive of engineers or scientist willing to move into politics.
I agree with you, there is a very dire need to get more various technical and scientific expertize into politics and parliaments. But with so much energy to spend on getting elected (not fun if tech/science is what interests you) and the crowd you'd be joining, there is a very high barrier to entry in practice. And the worst is that with all the paranoia about many science based issues (nuclear, OGM,
So I guess the technical input will still be through professional lobbies for a while, and sometimes (as here) after the fact. It's by far not an ideal situation as in such case expertize is strongly biased by financial interests, but without more interest and support for science in the general public in the first place I don't see how we could get much better in practice.
"Never attribute to malice that which is adequately explained by stupidity". Politics in France are particularly clueless about technology. Worse, they think they know it all because they had some cute web site with streaming video being designed for them. And someone who think he's good without having a clue is dangerous indeed. The current France government is full swing in security posturing, without much concern for the practical consequences that are not so clear to them anyway. All this is enough to explain this new law.
As for being a trick to favor French firms, this is incorrect as local companies are also affected and suffer from this. From the article, one of the companies attacking this law is DailyMotion, and they're French. I don't see any tech company being happy about this.
Lastly, there have been several laws cancelled in France recently due to either being incompatible with Europeans laws or being against France own constitution. That gives you an idea of how much the projects were well prepared and thought out... So this is not done and over.
You are correct, the filters are band specific and are the primary limitation here.
To build on your comment and provide a bit more context: the processing chain is base-band chip, RF chip and front-end (FE). The front end is made of LNA, filters, switches, duplexers, antennas, etc.
The base-band chip is band agnostic, and can easily support all bands. The current RF chips can be limited to a few selected bands, but the trend is to multi-bands chips. For LTE where there are bands all over the place, there's a big push toward multi-band RF chips. But in the FE part, the filters are required and are limited to a specific band (the point being to reject signals from other bands to avoid saturating the A/D converter on the receive side, and to avoid polluting other bands on the transmit side). You could imagine a bank of filters with switches to select the proper band, but there's a limit to how much you can fit on a phone and it's not as simple as I make it sound.
Disclaimer: I'm not a RF and FE expert by any mean. I just want to point out that supporting a lot of bands concurrently is challenging and has cost/footprint implications.
That's how it works already. The protocol stack runs on a separate chip with its own dedicated CPU (or CPUs) and its own firmware image. So you only need to secure this firmware to secure the telecom network. The only reason to also lock the application CPU is to provide to the operator or device maker more control on the separate application environment, for their benefit.
The ideal system would have a locked down access chip (to protect usage of the operator spectrum, you don't want unchecked hacking here) and an open application CPU (or CPUs). This is what OpenMocko did, and the application CPU(s) would be as open as the PC today. But that's not the trend today. Maybe a reason not to dismiss the N950 (or however it will be called).
On average, Android 2.3 was a 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone’s median load time of 3.254 seconds.
If it were relevant (which is not the case as it's supposed to compare web browsers), then the iPhone would be 52% slower than Android. Which is equivalent to say that Android would be ~34% faster then the iPhone, not 52% faster (for this, Android would need to complete in less than half the time of the iPhone). I guess that it's not politically correct to use the negative version (iPhone is slower), but then it's hard to resist using the higher number right? ;)
Interestingly, this has been reused by all news sites without anyone spotting the error. If Paulos makes a refresh of his "Innumeracy" book, I suggest this as an new example of how people lack fluency with basic computations.
I have neither iPhone nor Android phone (although I offered an iPhone to my wife, and would be more likely to buy an Android phone for me), and I don't care much about such differences. So I would consider myself quite neutral to this discussion. But it feels like the Blaze announcement was sensationalistic and a bit sloppy from the start. Anyway, it certainly worked in getting publicity, and that's probably all they cared for.
It's also BS actually.
;)
Yes, LTE advance (release 10 of LTE actually, as it's an incremental improvement) has a top Category 8 device that peaks at close to 3 Gbps. Go to www.3gpp.org and fetch TS 36.306, the categories are in section 4.1. Base LTE goes from Cat1 to 5, and LTE-A added Cat 6 to 8.
Now you need to know only one thing: the last category is mostly never implemented. These standards are hugely complex, and competition is fierce. So people get carried away and promise the moon. Then engineers in standardization start the serious work, and see what's possible, and it's not the same. So to be polite, the last category is dimensioned to match the silly promises, and nobody implements it as it is too impractical (unacceptable power consumption to start with, reliance on huge spectrum not available and on too many antennas that wouldn't fit in a handset, just as a few examples).. And the lower are made to be practical.
In basic LTE, the last category 5 was 300 Mbps downlink. What's implemented in practice today is Cat3 at 100 Mbps DL. Maybe some will push to Cat4 (150 Mbps) for bragging rights, but it'll make little difference in the field (we're talking peak rates here, which is only possible on a small part of a cell).
In LTE-A (R10), the last category 8 is ~3 Gbps DL. And the previous practical categories 6 and 7? Well, they're 300 Mbps. Yes you read it well, that's a factor of 10 difference. That should tell you all you need to know about Gps speed.
Today, power is already a challenge with WiMAX, which is 2 Rx chains and 10 MHz. LTE is 2 Rx chains and 20 MHz. LTE-A to meet 1 Gbps would need 70 MHz and 4 Rx chains (for 4x4 MIMO in DL) for example. Nobody has this contiguous spectrum, so that means carrier aggregation, at least 2 bands in practice. So you need 8 Rx chains, which draw power. That's a factor of 4 increase on the RF side. And the baseband is more complex too. All that while the first base (R8) LTE handsets are power challenged.
So please people, get real and use common sense. All this talk of Gpbs speed (even in static) is getting embarrassing. Sure, it's easy to do and perfectly possible on a demo set-up where power and footprint (for all the antennas) are no issue. If you talk real life, it's a different thing.
Besides this, LTE is still a very good standard a significant improvement on what we have. And LTE-A will also be a significant improvement too. But instead of focusing on silly peak rates, go to the 3GPP web site and look at the performance assessment for LTE-A for cell average. You'll find that LTE advanced is expected to be 40 to 60% more efficient in average than LTE. And this is a big gain.
Last point, because we're on Slashdot and we can talk real tech, you need to understand that peak rate doesn't matter much now. Seriously, WWAN faster then WiFi (which is also BS with talk of 600 Mbps, but that's a different story. On portable device it's 20 to 30 Mbps typically)? What matters now is handling the data explosion, and this means improving the network capacity. People always push peak rates as it's more sexy for the average Joe, but that's capacity that matters. Even for you. But it's certainly less sexy and harder to explain.
Still, whenever you hear about higher peak rates, understand that the features underlying the improvement will in practice not be used for higher peak rates, but for increased capacity. Example: MIMO. LTE-A goes up to 8x8 MIMO in Cat8, but that won't be used in mainstream product (and maybe never, as doing a complex chip for a niche market looks very expensive). But you can still have the 8 antennas at the BS, and only 2 at the terminal, and do multi-users MIMO with 4 concurrent users, each using 2 SM MIMO layers. That's really what the standard is made for, and it will increase the network capacity for our benefit.
Thanks for reading so far. I needed the venting on that topic
Just a comment on "If you want to embed processing functionality, or you want low-power (particularly low standby power), then you need ARM."
Stand-by power is really process related, and not so much related to the IA. It's true that ARM SoCs are using the LP (low power, and low leakage) variant of silicon processes while Intel/AMD processors use the high performance variants (faster, but higher power and leakage). But nothing prevents Intel optimizing for lower power, and the Atom goes in this direction while still targeting higher performance than current ARMs (that could change with A15, Denver...). Moreover, with recent processes (40 nm and below) the leakage is so high even in LP that for good stand-by performance one has to implement power gating. Intel can do that too. And I would guess the 50x improvement on recent Atoms come from this. Once you do power gating most design would consume negligible power in deep stand-by. ARM SoCs would still have an advantage as they are better integrated, but Intel has indicated they will go to more integration over time for Atoms. So it's really implementation choices, and different goals, that hard intrinsic advantage here IMHO.
ARM cores are available at three level: as a hard macro (ready to use for a specific process, you can't change anything), as RTL (you do the routing, and there some amount of configuration for caches, TCM, FP, etc.) or as an instruction licensee (you do the implementation yourself). In theory nothing would prevent an instruction licensee to do a super high performance implementation for example. It's just that in practice ARM licensee target for now low power devices, and as you explain target a different performance/power trade-off than even current Atom/Bobcat chips.
Regarding point 3, isn't WP7 accepting only managed .Net code at this point? Which would make sense, considering that the underlying OS is still in the WinCE / Windows Mobile line, so will be replaced by a "NT line" kernel in the future. So it makes sense for MS to hide the internals and force all developers to stick to their VM until this transition is done (WP8?).
In this case, it looks like WP7 is even worse than Android for you. And QT is coming to Android, although it's still young.
Hey, you missed part of the action it seems... A few months ago, before Elop arrived, Nokia sold its baseband division. It's now called Renesas and is an independent business. Just like every baseband vendor, they're also moving in the application processor space to provide in addition to baseband chips integrated AP+BB solutions (as Qualcomm, as ST-Ericcson, etc.).
I certainly hope with him that the most open systems will win in the end. But this is all bla-bla, in the end it's just business. For a given price point every player try to get the maximum share. You do this by commoditizing the others:
;) But with more thinking it's hardly surprising. Just follow the money.
- Intel loves linux based x86 systems as it creates more competition at OS level. Less money for the OS, bigger share for their CPU for a given price;
- I'm sure Microsoft will love ARM. Sure, it's a port and they will have to make the porting super easy for all MS based software developers, but they benefit from a very competitive CPU ecosystem where CPU cost will be lower than with just Intel/AMD. And a bigger pie possible for them in the end.
So you can see why Intel and MS are not chum anymore. The time where PC price were so high everybody could be happy is over, now all fight for dollars.
Now where does this put Nokia? They may want to play in services, but viewing their dismal performance so far I don't think they'll get very far. My guess is that they negotiated a part of the WP license for them, based on some (real of phony) participation. Now consider the options:
1) join Android, and having to fight on an even field with ruthless competitors like Samsung, HTC & co;
2) join WP, and fighting them with a price advantage due to a share of the OS license for them.
Surprised at what they preferred? Well to be honest I was
Plus, as someone says, they target not WP7 but the next step when you're phone docked will be your computer. MS will offer Office and Outlook, and all the lazy persons will follow. Unless MS executes super poorly that's a real advantage.
We could have had a clean start with these new super phones, shedding most of the cruft accumulated over the years of PC evolution. I'm fairly comfortable we'll have a clean start with ARM (and its zillions licensees) on the CPU side. On the OS side, I guess MS will be here to stay... I just hope there will still be good linux based offering for those super phones --- and I don't count Android or ChromeOS as good enough, I want a local connected system and not do it all in the cloud thank you.