3 ms·

Their testing methods were very imprecise. To really confirm this they would need to monitor the network driver(s) on the phone and record the exact data amoun

by dangero 15y ago

Their testing methods were very imprecise. To really confirm this they would need to monitor the network driver(s) on the phone and record the exact data amounts that are passed and then compare that to what AT&T reported. Another option would be to emulate a cell tower, connect the device to it, and monitor traffic that way. The thing I did find interesting was that they said some carriers round up transfer sizes. That could account for some big differences when you consider that this rounding could happen per transfer or session. To me that sounds like highway robbery akin to shaving pennies off interest.

nupark2 15y ago
> Their testing methods were very imprecise. I agree. The article states that a custom web server was used, but the web server has no means of tracking protocol overhead.
- jsnell 15y ago
  A sufficiently custom web server does have the means to estimate protocol level overhead (TCP and IP headers, retransmissions). The only reason it couldn't track would some kind of a system that splits TCP connections (e.g. a proxy) located somewhere between the billing system and the web server. But most forced proxies only run on port 80, and could easily be circumvented. The measurement would not be totally accurate as the sender couldn't know at which point packet loss happened. A packet lost somewhere after the billing system and retransmitted should count, a packet lost before the billing system should not. But it would at least give an upper bound. If the bottleneck in the system is the RAN rather than the internet links that upper bound could actually be quite close to the real figure. Of course some technical competence would have been required for this experiment, probably more than these clowns have. And it would likely have shown about 5-10% protocol overhead, which would not have done their case any good.
_-af-_ 15y ago
You can't easily 'emulate a cell tower'. To verify that the device isn't indeed transferring any data as part of any background Apple process they should put it on WiFi and monitor traffic through the router. It should be zero. I'm logically assuming that any background process that would transfer data over 3G would also do it when on WiFi network. They could also get a data modem from AT&T and test it by connecting to the tower but not transferring any data. If AT&T is overestimating data transfers or has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans.
- sukuriant 15y ago
  "If AT&T ... has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans." Why? Their modems might be programmed to operate or need to update differently.
- joshu 15y ago
  Actually, it is doable. I met a guy that had a whole SDR plus GSM stack. I was able to pair my blackberry with it. He runs a cell network at Burning Man, apparently.
  - bostonvaulter2 15y ago
    Was going to mention the system at Burning Man, then I realized that you already mentioned. So here's the link: http://www.networkworld.com/news/2010/083010-open-source-voip-cell-phones-at-burning-man.html http://www.networkworld.com/news/2010/083010-open-source-voi...

by dangero 15y ago

nupark2 15y ago

> Their testing methods were very imprecise. I agree. The article states that a custom web server was used, but the web server has no means of tracking protocol overhead.

jsnell 15y ago
A sufficiently custom web server does have the means to estimate protocol level overhead (TCP and IP headers, retransmissions). The only reason it couldn't track would some kind of a system that splits TCP connections (e.g. a proxy) located somewhere between the billing system and the web server. But most forced proxies only run on port 80, and could easily be circumvented. The measurement would not be totally accurate as the sender couldn't know at which point packet loss happened. A packet lost somewhere after the billing system and retransmitted should count, a packet lost before the billing system should not. But it would at least give an upper bound. If the bottleneck in the system is the RAN rather than the internet links that upper bound could actually be quite close to the real figure. Of course some technical competence would have been required for this experiment, probably more than these clowns have. And it would likely have shown about 5-10% protocol overhead, which would not have done their case any good.

_-af-_ 15y ago

You can't easily 'emulate a cell tower'. To verify that the device isn't indeed transferring any data as part of any background Apple process they should put it on WiFi and monitor traffic through the router. It should be zero. I'm logically assuming that any background process that would transfer data over 3G would also do it when on WiFi network. They could also get a data modem from AT&T and test it by connecting to the tower but not transferring any data. If AT&T is overestimating data transfers or has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans.

sukuriant 15y ago
"If AT&T ... has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans." Why? Their modems might be programmed to operate or need to update differently.
joshu 15y ago
Actually, it is doable. I met a guy that had a whole SDR plus GSM stack. I was able to pair my blackberry with it. He runs a cell network at Burning Man, apparently.
- bostonvaulter2 15y ago
  Was going to mention the system at Burning Man, then I realized that you already mentioned. So here's the link: http://www.networkworld.com/news/2010/083010-open-source-voip-cell-phones-at-burning-man.html http://www.networkworld.com/news/2010/083010-open-source-voi...