One of the popular mods on XDA is Data Throttle Removal (AKA DTR), as described in this thread:
[MOD] Uncapped Data For Your ROMS (Skyraider, Virtuous, OMGB, ETC). In fact, some people consider it so vital that I have seen them delay upgrading their rom (even if the upgrade contains bugfixes) because they are waiting for a new DTR to be created.
The premise of this mod is simple:
1. Throttle code was discovered in our services.jar file.
2. It has been hypothesized that Verizon uses this code to throttle our 3G data speeds.
3. It is further hypothesized that flashing this mod disables the throttle, thereby returning your 3G speeds to their full potential.
In reading the forums, I see a lot of different values being thrown around. Quoting that original thread, for example, it is claimed that "Verizon starts to throttle data speeds after 5gb of data. That doesn't mean you get charged more, Verizon just slows you down. This mod will prevent that, and only that."
Looking at the code itself, however, pokes some holes in the original premise:
And here's what it looks like in stock Froyo:
As for the 5gb claims, I cannot find any source on where that figure comes from. While Verizon has publicly stated that they reserve the right to throttle data (even on unlimited plans), they only state that it may be done to "the top 5% of Verizon Wireless data users."
Source:
http://support.vzw.com/terms/products/broadbandaccess_nationalaccess.html
http://support.vzw.com/terms/products/vz_email.html
While a VZW network specialist may be misinformed (or lie), here's what one had to say when this topic was broached by AdhvanIt:
The argument that VZW would not throttle in this method also has merit. As mentioned by ihtfp69, the throttle is Google code, not VZW code. Furthermore, by placing the burden of throttling on the device alone, VZW leaves itself easily exposed to exactly the kind of hack that people are trying to achieve. Maybe they are indeed that lazy, but I have a difficult time believing that. They have complete control over your services: why would they leave this one task up to the phone?
Actually, given that this mod came over to us from the EVO, it would mean that both Sprint and Verizon were relying on this throttle. Why would two phone giants who have different networks, policies, and plans, rely on the same throttle that was coded as part of Android itself?
But perhaps those arguments are a bit too hypothetical to address in a meaningful way. Besides, as ihtfp69 further states:
In my own testing, I have not been able to find any difference between a stock services.jar file and one that has been modified with DTR. I make this statement based on 70 recorded speed tests, split evenly between stock and DTR. Forty recordings were taken throughout a single morning at my office, where my signal hovers around -84 dBm (the building itself interferes with reception). The thirty remaining recordings were taken throughout a single evening at my house, where my signal hovers around -74 dBm. I flashed back and forth between stock and DTR every few tests to ensure that neither testing condition was clumped into a single time window or boot cycle.
Office:
Home:
If I hadn't run so many trials, I could have easily seen a difference that was purely chance, but falsely attributed to DTR. This is true even across multiple readings. For example, my first few readings at the office:
Stock:
Test #1: 1,155 kbps
Test #2: 1,090 kbps
Test #3: 1,008 kbps
DTR:
Test #1: 557 kbps
Test #2: 1,406 kbps
Test #3: 1,404 kbps
Someone might look at these figures and think that DTR had delivered a 40% increase in max achievable speed. Looking back at the full chart, however, over the course of many trials, it is clear that the differences were natural fluctuations.
Of course, you could reasonably retort that I am seeing no difference because I am not being targeted by Verizon's throttling.
The question then becomes, why do you believe that you are being throttled? Is it solely a dissatisfaction with "stock" 3G speeds, or do you have reason to believe something more?
I would love to find out that DTR is truly effective, but I have yet to see convincing evidence.
[MOD] Uncapped Data For Your ROMS (Skyraider, Virtuous, OMGB, ETC). In fact, some people consider it so vital that I have seen them delay upgrading their rom (even if the upgrade contains bugfixes) because they are waiting for a new DTR to be created.
The premise of this mod is simple:
1. Throttle code was discovered in our services.jar file.
2. It has been hypothesized that Verizon uses this code to throttle our 3G data speeds.
3. It is further hypothesized that flashing this mod disables the throttle, thereby returning your 3G speeds to their full potential.
In reading the forums, I see a lot of different values being thrown around. Quoting that original thread, for example, it is claimed that "Verizon starts to throttle data speeds after 5gb of data. That doesn't mean you get charged more, Verizon just slows you down. This mod will prevent that, and only that."
Looking at the code itself, however, pokes some holes in the original premise:
Looking at your framework-res.apk should show you the icon that is being mentioned. In the stock Froyo framework, for example, it can be found at /res/drawable-hdpi/stat_sys_throttled.pngExamining the code, if this throttling service was engaged, it would put an icon in the notification bar. You would know it was on. This is code built in by Google. It is not an add on from Verizon. Personally, I would leave it alone.
And here's what it looks like in stock Froyo:
As for the 5gb claims, I cannot find any source on where that figure comes from. While Verizon has publicly stated that they reserve the right to throttle data (even on unlimited plans), they only state that it may be done to "the top 5% of Verizon Wireless data users."
Source:
http://support.vzw.com/terms/products/broadbandaccess_nationalaccess.html
http://support.vzw.com/terms/products/vz_email.html
While a VZW network specialist may be misinformed (or lie), here's what one had to say when this topic was broached by AdhvanIt:
The VZW network specialist's statement echoes the VZW official release on their website, and AdhvanIt's data usage shows that the 5gb figure is not necessarily a hard threshold.Just FYI. According to the VZW network specialist that I talked to the other day, consumers are notified if their data is to be throttled due to high data usage. Mine has not been throttled and I've used 5.2GB of data, with my cycle not ending until the 22nd. He said my usage wasn't nearly high enough to have my data throttled. Its the top 5% of users that get throttled.
Edit: when i asked, he also told me that data was throttled from the line itself, not from the device. Not saying the DTR is all placebo effect, but confirming why its never done anything for me.
![]()
The argument that VZW would not throttle in this method also has merit. As mentioned by ihtfp69, the throttle is Google code, not VZW code. Furthermore, by placing the burden of throttling on the device alone, VZW leaves itself easily exposed to exactly the kind of hack that people are trying to achieve. Maybe they are indeed that lazy, but I have a difficult time believing that. They have complete control over your services: why would they leave this one task up to the phone?
Actually, given that this mod came over to us from the EVO, it would mean that both Sprint and Verizon were relying on this throttle. Why would two phone giants who have different networks, policies, and plans, rely on the same throttle that was coded as part of Android itself?
But perhaps those arguments are a bit too hypothetical to address in a meaningful way. Besides, as ihtfp69 further states:
And there's the rub. I see a lot of anecdotes but very few hard numbers. When I do see numbers here and there, they are generally extremely small samples: 1 or 2 speed tests done before and after the mod. Such a small sample is statistically insignificant, especially since we know that 3G speeds fluctuate based on location, time of day, population, etc.If ppl are think they are getting better throughput with this mod, then go for it.
In my own testing, I have not been able to find any difference between a stock services.jar file and one that has been modified with DTR. I make this statement based on 70 recorded speed tests, split evenly between stock and DTR. Forty recordings were taken throughout a single morning at my office, where my signal hovers around -84 dBm (the building itself interferes with reception). The thirty remaining recordings were taken throughout a single evening at my house, where my signal hovers around -74 dBm. I flashed back and forth between stock and DTR every few tests to ensure that neither testing condition was clumped into a single time window or boot cycle.
Office:
Home:
If I hadn't run so many trials, I could have easily seen a difference that was purely chance, but falsely attributed to DTR. This is true even across multiple readings. For example, my first few readings at the office:
Stock:
Test #1: 1,155 kbps
Test #2: 1,090 kbps
Test #3: 1,008 kbps
DTR:
Test #1: 557 kbps
Test #2: 1,406 kbps
Test #3: 1,404 kbps
Someone might look at these figures and think that DTR had delivered a 40% increase in max achievable speed. Looking back at the full chart, however, over the course of many trials, it is clear that the differences were natural fluctuations.
Of course, you could reasonably retort that I am seeing no difference because I am not being targeted by Verizon's throttling.
The question then becomes, why do you believe that you are being throttled? Is it solely a dissatisfaction with "stock" 3G speeds, or do you have reason to believe something more?
- When you are not using DTR, do you see the throttle icon present in your notification bar? If the services.jar file really is the culprit, you should.
- Have you ever been notified by VZW that you are being throttled?
- How much data do you use in an average billing cycle?
- Do you have more substantiation than a small handful of readings?
I would love to find out that DTR is truly effective, but I have yet to see convincing evidence.