This is a bogus article. CDMA 2000 3G phones that are referred to as 2.5G operate at the same (if not higher) speeds that this phone does (~144 kbps). There are plenty of 3G-1XRTT capable phones available from SprintPCS and Verizon and those companies have networks that support 3G-1XRTT - that's right 3G-1XRTT at full 3G-1XRTT speeds! So to say that this piece of junk Nokia is the first 3G capable phone is a fallacy.
I like the approach mentioned earlier in the thread about initiating remote loopback (assuming you have a DSU/CSU and can do it). You should be able to write some simple perl that opens and writes a file of known size "across" the loopback connection to a program listening on a socket on the other side and calclating the bandwidth based on the file size / duration. That would really only measure the transport layer payload capacity, but I'm sure it would be pretty close to accurate. I've done this sort of thing before (with wireless PPP connections) with excellent results.
Re:Forgive the trolling, but this has to be said
on
How to Test Your T1?
·
· Score: 1
This isn't so clear cut, AntiTuX.... The router like an anonymous coward said, cannot calculate the available badwidth, but merely the observed throughput. In this case therouter might as well be a paperweight because even if you executed a massive throughput glut, you wouldn't necessarily be able to calculate bandwidth based on the router stats without precise timing and reliable ways of determining whether or not CPU/process utilization skewed the results. Nope, there are better ways than using the router.
Slashdot Mirror
This is a bogus article. CDMA 2000 3G phones that are referred to as 2.5G operate at the same (if not higher) speeds that this phone does (~144 kbps). There are plenty of 3G-1XRTT capable phones available from SprintPCS and Verizon and those companies have networks that support 3G-1XRTT - that's right 3G-1XRTT at full 3G-1XRTT speeds! So to say that this piece of junk Nokia is the first 3G capable phone is a fallacy.
I like the approach mentioned earlier in the thread about initiating remote loopback (assuming you have a DSU/CSU and can do it). You should be able to write some simple perl that opens and writes a file of known size "across" the loopback connection to a program listening on a socket on the other side and calclating the bandwidth based on the file size / duration. That would really only measure the transport layer payload capacity, but I'm sure it would be pretty close to accurate. I've done this sort of thing before (with wireless PPP connections) with excellent results.
This isn't so clear cut, AntiTuX.... The router like an anonymous coward said, cannot calculate the available badwidth, but merely the observed throughput. In this case therouter might as well be a paperweight because even if you executed a massive throughput glut, you wouldn't necessarily be able to calculate bandwidth based on the router stats without precise timing and reliable ways of determining whether or not CPU/process utilization skewed the results. Nope, there are better ways than using the router.