Samsung Epic 4G Review: The Fastest Android Phone
by Anand Lal Shimpi on September 6, 2010 5:28 PM EST- Posted in
- Smartphones
- Samsung
- Epic 4G
- Gadgets
- Mobile
Cellular & WiFi Performance
The Epic 4G is the second smartphone we’ve reviewed that has a WiMAX radio for use on Sprint’s 4G network. This is actually why I’m reviewing the phone and not Brian, Raleigh, NC happens to be one of the 40 US cities with Sprint WiMAX coverage.
Those of you who read my EVO 4G review will remember that I did’t have the best experience with WiMAX in Raleigh back then. I’m sorry to say that the situation hasn’t really improved much since.
The best download speeds I’ve seen are still in the low 3Mbps range, and upload is usually stuck around 1Mbps while on 4G. On a good day, AT&T’s 3G network is anywhere from 1 - 2Mbps down and 1 - 1.5Mbps up in my area. As with the EVO 4G, Sprint charges a mandatory $10 per month Premium Data fee for 4G support regardless of whether or not you use it.
The other issue is consistency. I usually don’t get those 3/1 numbers, often times I’ll see speeds more like 1/1 or 1/0.5Mbps. I’m always seeing screenshots of users in other WiMAX areas with speeds 2 - 3x my best case in Raleigh, so this may just be a problem with coverage in Raleigh. Either way I’d suggest looking into what to expect in your area before making a decision based on 4G alone.
Speedtest Results for the Epic 4G, all results on 4G except for the topmost result
I will say that I no longer have the problem where 4G performance is worse than Sprint’s 3G in my area. I usually get around 0.5/0.5Mbps on 3G, so there’s a noticeable performance increase when WiMAX is enabled.
And just as was the case with the EVO 4G, 4G isn’t actually more of a battery drain as long as you’re stationary. If you have it enabled while you’re moving around (rather than just turning it on once you’ve gotten to a location) you’ll see a drop in battery life.
Whether or not Sprint itself is a good network for you depends entirely on coverage in your area. In my experience, AT&T is usually either great or absolutely horrible - there’s very little in between. While Sprint (and Verizon) are consistently good. Compared to areas with great AT&T coverage, Sprint can’t compete in performance - but where AT&T’s coverage is weak, Sprint’s average performance is usually better. Awesome occasionally or consistently reliable - those are the two choices it seems.
WiFi performance was better than the Motorola Droid X and the Nexus One, but behind the iPhone 4.
Like all other smartphones we’ve reviewed, the Epic 4G’s cellular signal does attenuate based on how you hold the phone. Given the sheer thickness of the device it’s harder to get the large signal drops by holding the phone that we see on thinner devices.
| Signal Attenuation Comparison in dB - Lower is Better | |||||||
| Cupping Tightly | Holding Naturally | On an Open Palm | |||||
| Samsung Epic 4G | 10.0 | 5.0 | 0.0 | ||||
| Droid X | 15.0 | 5.1 | 4.5 | ||||
| iPhone 4 | 24.6 | 19.8 | 9.2 | ||||
| iPhone 3GS | 14.3 | 1.9 | 0.2 | ||||
| HTC Nexus One | 17.7 | 10.7 | 6.7 | ||||
The biggest drop I noticed was 5 dB when I held the phone normally, and 10 dB when I held it tightly trying to cover as much of the antenna as possible with my hands. This is in line with other Android smartphones (actually a bit better), and obviously better than the iPhone 4.
Facebook
Twitter
RSS
93 Comments
View All Comments
Ethaniel - Monday, September 6, 2010 - link
I have also noticed that all Android phones out there do some kind of "breakdancing". You think it has something to do with Android, but I think it has something to do with Java. Now, Java devs will probably want to eat my brain after this... but Java sucks. Big time. Making Android's UI based on Java was a bad, bad, really bad move. About four three time slower than C++, it demands more memory... completely inadequate for a mobile environment.meatless - Monday, September 6, 2010 - link
It's sad, the prevalence of Java FUD to this day. It's also bad to blame Java (the syntax), as you are unnecessarily conflating the Dalvik VM with desktop VMs such as Sun's.C++ is fast, sure, but there is a lot more to designing a platform than speed, and the Dalvik VM is more than fast enough. iOS's Obj-C implementation is also not C++ fast, but who complains?
taltamir - Tuesday, September 7, 2010 - link
1. both Javas are shit2. There is more to a platform then speed... but when you are designing a platform starved for processing power and that needs to sip electricity then it makes a huge difference.
Penti - Tuesday, September 7, 2010 - link
Most of the platform are actually C/C++ libraries and programs, where you glue your app in isn't that relevant. You need a framework for any mobile phone platform, but the resources that framework glues into thats where a lot of performance comes from and it's in C/C++. It's better to have an accelerated framework running on a virtual machine then an unaccelerated C++ one. Rendering of menus and such would be slower on the last one. Besides on Symbian it's QT-framework that rules now, not some ultra customized embedded framework. Memory requirements have gone up there too, but capacity have grown even more. Besides nobody wanted to write mobile apps to some badly designed and awkward C++ framework and API. Java syntax was a good choice therefor.taltamir - Monday, September 13, 2010 - link
the fact that there are more considerations than just programming language when it comes to power and speed are obvious, as is that you could make a java app thats faster than a C++ app.Neither make java a good choice.
BTW, I didn't personally comment about the issue of jerkiness, I was going on a tangent as a reply to what meatless said (specifically the socalled "java FUD")
zizagoo - Monday, September 6, 2010 - link
It's an Android problem. The cause of the "jerkiness" is that unlike iOS/WebOS/WP7, Android doesn't have a gpu accelerated ui. They supposedly did this because the G1 wouldn't support it at the time.http://code.google.com/p/android/issues/detail?id=...
Gingerbread, which is supposedly showcased next month, should fix this.
deputc26 - Monday, September 6, 2010 - link
Thankyou! this is exactly it, give the man a medal. I don't know why Anandtech never mentions this. It should be ubiquitous knowledge in the android community.meatless - Monday, September 6, 2010 - link
Also, the 3-4X speed difference on non-mobile platforms is greatly exaggerated. I always find http://shootout.alioth.debian.org/ a fun and FUD-free site.Iksy - Tuesday, September 7, 2010 - link
Greatly exagerated? That site shows a 2.3x speed difference and it's comparring against Sun's fastest most optimizing version against g++. The unoptimized version is over 20x slower, you'll find it near the bottom of the list for compares. I do find it interesting that while they're satisfied with using an open source C (gnu) compiler, they do not include the open source java interpreter. They also do not include the Intel C compiler, even though they easily could and include the Intel Fortran compiler.In other words, is still in the ball park so say Java is 3-4x slower than the equivalent c++ code.
dvinnen - Tuesday, September 7, 2010 - link
Wait, so the Java syntax is what is slowing down Android? Because it doesn't run Java, it runs Dalvik.I would also like to see evidence that C++ is 4 times faster. Not saying Java is faster but it is fast enough. I say that as a Java developer who doesn't like the language and would rather use slower languages like Python